I love these stories. I got my start around 1998 when the web was coming into full force which was only a decade after this and very different. Things were changing quickly in that era.
The closest I've had to this was working at a company that had been around for close to thirty years and had kept many of the original developers (they'd taken the product from a terminal interface to the web, from cobol to c#) and had many stories like the one in the original post.
I started a few years after you, around about 2003. There were certainly pockets of industry that still operated exactly the same as the article described, especially defense and aerospace.
Which makes sense, given working in embedded hardware (especially in classified contexts) back then came with a lot of the same limitations described in the article - software had to be delivered by sneaker-net, installation was burdensome, you couldn't just fire up the application for a quick bug fix at home, etc. Not to mention the inertia of having Always Done It That Way.
I started about 10 years after, and I think that was almost the best of both worlds. Agile was starting to become a thing, but wasn’t perverted to sell expensive courses and credentials yet, and tooling began to be developed that was a serious improvement on what we had.
>To my astonishment I discovered that I loved to write, even more than I enjoyed writing code.
I wish I was this person. I'm one of those (great majority of) people whose documentation you'd hate.
I deeply hate writing like that because I can never properly explain my tangled thoughts. Even my comments on sites like that are at most few liners. Describing things in code is much easier, since you don't have centuries of context written into words.
Your class names, variable names, and method names have plenty of centuries' worth of context in them anyway whether you like it or not, not to mention the comments and documentation.
I think you'd benefit from looking at writing differently. What you describe--"I can never properly explain my tangled thoughts"--is the essence of composition. The goal of the process of writing is to untangle those thoughts and express them!
When I say "process," I don't just mean that you begin typing immediately. Composition is about planning as well. Even if you spend just a few minutes making a list of keywords & important concepts then arrange them on cards in the order you think you should present them in, I bet it would help writing your initial draft of a document.
If that doesn't appeal to you, so be it, but look into a composition course, because I genuinely think you could turn something you hate into something that helps. You might never fall in love with writing, but that doesn't mean it can't be a tool that solves problems for you.
It's weird... I was never big on writing, but when I finally tried my hand at a data format specification (https://github.com/kstenerud/concise-encoding), I found that I really enjoyed the experience.
It's 3000 lines and took me four years and countless revisions, but I feel it was worth it. I actually enjoyed writing the spec even more than writing the reference implementation :)
Wow, I like the data format specification you devised. Especially that you insist on "no optional features or extensions" -- something that makes other standards so difficult to rely on.
Is there anyone using it? It's always great to have extra ammunition to make a strong case that we should use this instead of, say, XML.
It's still in the prerelease stage, but v1 will be released later this year. I'm mostly getting hits from China since they tend to be a lot more worried about security. I expect the rest of the world to catch on to the gaping security holes of JSON and friends in the next few years as the more sophisticated actors start taking advantage of them. For example https://github.com/kstenerud/concise-encoding/blob/master/ce...
- Revamp the compliance tests to be themselves written in Concise Encoding (for example https://github.com/kstenerud/go-concise-encoding/blob/master... but I'll be simplifying the format some more). That way, we can run the same tests on all CE implementations instead of everyone coming up with their own. I'll move the test definitions to their own repo when they're done and then you can just submodule it.
I'm thinking that they should look more like:
c1
{
"type" = {
"identifier" = "ce test"
"version" = 1
}
"tests" = [
{
"name" = "Some kind of test"
"success" = [
// These must successfully convert to each other
{
"cte" = "c1 [1 2 3 4]"
"cbe" = |u8x 81 01 7a 01 02 03 04 7b|
// Events are a kind of text shorthand for what the parsing of cte or cbe should produce
"events" = ["v 1" "l" "n 1" "n 2" "n 3" "n 4" "e"]
}
{
...
}
]
"failure" = [
// These must fail to decode
{
"cte" = "c1 100 ]"
}
{
"cbe" = |u8x 81 01 64 7b|
}
]
}
]
}
> I deeply hate writing like that because I can never properly explain my tangled thoughts.
I brought a friend of mine to give a couple lectures at our company for this exact reason. He's a professor of non-fiction. There's a couple techniques we learned you can use:
I started my first programming job, well trainee programmer in September 1989. Five people applied for the job and I ended up taking my TV and Atari ST to the interview to show them some stuff I had written in STOS Basic.
Got the job and started with dBase II on Concurrent DOS.
I also have some fond memories of writing a 'smart' algorithm in STOS Basic for generating Madelbrot fractals. And is still took hours to fill the screen.
I am surprised I had to scroll this far to find a dBase reference. I am the same vintage as OP, and yeah... back in the day dBase was the key to riches...at least as a contract dev. I remember spending A Lot of Money on the big box of dBase IV when it was released...all the diskettes and manuals. Around that time there was much talk about migrating from dBase databases (those .dbf files) to the magic of "SQL" which at the time meant nothing to me. Needless to say dBase IV cratered, and the industry went elsewhere. Good times!
I attended a lecture by him around 1990. Maybe I was not the Turing Award class of computer scientist, was not sooo impressed what he spoke about. Remember Parnas [1] approx. the same year much better.
Around 1998 Gray had built something called TerraServer, must have been years before Google Maps or OSM. It was a real eye opener at the time to see my little house in the middle of nowhere in Northern Europe on the internet published for free by an American company. At the time PC disk sizes where still measured in Megabytes, so you weren't even able to store that many aerial pictures. At least not pictures of current size. Probably they were smaller then, don't have any data.
Similar to the blank tape story, around 7 years ago at a big networking corp a big customer needed the latest product to be in their possession before some tax related date. The new product software wasn't ready at all at that point, so we shipped them unit with a place holder FW that could do only one thing: FW upgrade!
I have been working in the software industry since 1990. In 1990, I joined a company that made innovative coupling between AutoCad and relational databases (Oracle). However, I wrote my first program in 1978 in Algol 60. I also used Fortran, LISP, (Turbo) Pascal, BASIC, and 6502 Assembly before (in 1990) starting to develop software in C.
I remember that one day at this company, we had just got a MicroVAX system, when I there was someone at the door with a europallet. We wondered what it could be. Turned out it was the VAX/VMS documentation that belonged to the MicroVAX. It took more space than the system itself.
Being the same vintage as Jim, much of this brought back memories.
There really wasn't any such thing as a tech stack - our company would produce software for various Unixen and, especially, Vax, and the language was alway C, with some Pascal on the Vax side (as, I was told, the Vax Pascal compiler produced far more optimal code than the C compiler).
Being a software engineer was like being a furniture-maker. You had to master a small number of tools - the saw, the chisel - and then craftsmanship consisted of discovering an affinity with these tools and a love of getting ever more skilled at using them. This path wasn't for everyone, which was fine - plenty of management and other non-tech roles for those folks - but if you grooved with your tools it was a real joy to be able to move from chair- to table- to cabinet-making and carry and refine your skills as you went.
This idyll could not last, however. Before too long it became uneconomical to make furniture this way, so for your chair making project you instead had to learn how to run a chair-making machine. When you moved onto a tables project, the machines there were infuriatingly dissimilar to the chair-making ones you'd just mastered. Worse still, moving back to chair-making after a year or two, you discover that the old machines you knew are now obsolete and you have to re-learn how to run their replacements. This stops being fun, or interesting, after a while, and yet sadly it's all that most younger software engineers know.
Occasionally, there is the need to make some shim or gizmo that the machines don't cover, so out come the trusty saw and chisel of yore - much to the amazement of the young'uns, who are astonished that an old-timer can still wield these antiques so effectively.
As a youngster who has had to pick up a saw and chisel to repair an old chair, I think you're looking back with rose tinted glasses a bit. I've never been astonished by legacy code, as much as bemused for the lack of object orientation, data normalization, etc. The technology changes of course, but there are advancements made in craftsmanship/techniques.
There's some 'cleverness' lost probably, in the new ways vs the old. I've seen some pretty novel approaches to what should be simple tasks in legacy code. And I do recognize that for what it is. But as impressive as that cleverness can be, I think it's one of the reasons as to why a lot of legacy code persists and nobody wants to touch it. Among many other reasons.
Huge disagree on this. Old code tend to be much more terrible because the tools were terrible. They gave little incentive and absolutely no help to write even passable code. We end up with a mess of poorly documented, sparingly commented spaghetti code that sometimes work, often by accident.
Nowadays, we have linters to point out common classes of mistakes, programming languages with actual type systems to enforce invariants, integrated testing tools, etc...
Note that, yes, we do still have new, terrible codebases. But at least the tooling nowadays raised the bar to have a minimum floor of quality that, while very low, is still oh so much higher than it used to be.
> Huge disagree on this. Old code tend to be much more terrible because the tools were terrible.
I've looked at 1990s code in the Windows NT kernel. It was wonderful.
Oldest source file I went through was from 1993. Perfectly readable and understandable.
One of the best modern code bases I ever worked in didn't even have a linter setup. The principle dev reviewed every single commit and enforced a consistency across the code base that was better than what any tools ever could have done.
> The principle dev reviewed every single commit and enforced a consistency across the code base that was better than what any tools ever could have done.
How was it so much better that it justified that level of busywork on the part of the senior member of the team (and busywork for everyone else, to fix the style nits they enforced in review)? I would have guessed that taking a few hours to install and configure a formatting linter to free up the principal dev's time to focus on other things would have been hugely high leverage.
It ensured not only consistency of style, but also consistency of ideas. Every file was structured similarly, impedance mismatches were minimized, work across the entire code base was organized and unified. Junior engineers got a chance to talk to the principle developer about every commit they made, and accordingly their abilities as software engineers skyrocketed.
Developers quickly set their IDEs to follow the team's coding guidelines, style wasn't really a problem.
We had "coding standards," and if you didn't code it to the right format, you'd get fussed at. I didn't start professionally until the mid 90s, so I'm a little younger than the OP. I've been coding since the mid 80s though as a youngster.
Putting BEGIN..END around a one line block was always a contention since it wasn't required. Less code vs arguably more readable code (Pascal)
> The code quality is determined by the author, just like today.
This is nonsense. The worst authors can still produce bad code with the best tools and the best authors can still produce good code with the worst tools, but most authors are somewhere in the middle, and tooling makes a huge difference to the average.
I think you might be missing parent comment's point. The way I read it they aren't saying that old code is better, just that you used built everything up from scratch generally (or to a much greater extent than nowadays) instead of using whatever framework is in fashion this week
> As a youngster ... as much as bemused for the lack of object orientation.
And as an oldster you be happy again to see the lack of object orientation and not the 5 level misabstracted inheritance hierarchy someone didn't do for purpose but just because university taught the modern way to automatically end up with sane structured code... and sure sure every tool can be used well or misused and never overgeneralize 8-)
I may be wrong but youngsters as oldsters have both their own rose tinted glasses.
When I told him about SQL databases. Relational stuff, normalization. Awesome.
He told me that was all fine and dandy but just too slow, this new fangled SQL database stuff. He used databases where you simply accessed rows by key. If you needed to access something by a different key you just made a different table where the same data was arranged by that key instead. Super performant.
Of course my dad also programmed in languages like 370 assembler.
Funny how the young folks today talk about NoSQL databases indeed.
SQL databases were a dumb misstep, it's always baffled me how they ever caught on. In 10 or 20 years we'll look back on them the same way we look on C++/Java-style OO today.
It's not really such a dumb idea actually. It just depends on what you favour. There are plenty of nice things about SQL databases. I suppose it's the regular back and forth between one extreme and another. Both driven by "we need something new to work on" and changing technology landscape.
Relational databases really weren't all that practical back in the day with the hardware that was available. Putting thought into defining how you are going to query your data was available though. Relational algebra wasn't a thing from the start either.
If someone comes along and tells you that you don't have to know all this up-front and you can come up with a query you want to ask about the data you have, you will be able to, isn't that awesome? Ad-hoc, just like that. No need to carefully transform the data you have, ensure you keep it all up-to-date in multiple places etc. Of course data volumes grow and even the newer hardware you have can soon no longer handle what you got in a timeframe that you like. Indexing will be a thing. Of course even indexes grow way too huge to really perform, but hardware to the rescue, where at least all the indexes you need frequently will fit in RAM. Lots of caching going on too for your regular workloads.
Guess where the story is going? Well of course there's the old analytical vs. transactional load thing, i.e. your "Data Warehouse" is a separate database that is optimized for the pre-defined queries again, actually de-normalizing lots of things, being on different hardware, so as not to disturb warm caches for the transactional load etc. And yes, finally NoSQL again, i.e. back to the roots. Put more thought into how you're going to query this as your globe spanning SaaS load won't fit onto the hardware you have available. Of course this brings problems because we're just so good at predicting what kind of query we want to ask about our data. Databases like MongoDB, Cassandra, AWS DocumentDB etc. grow indexes supporting querying arbitrarily ... There's a hole in my bucket dear Liza, dear Liza ... :)
[I'm sure this nice story line is not globally completely correct/adhering to exact timelines but illustrates the point]
A different index, surely, not a different table? This sounds like an ISAM database to me, where you'd have to do lookups manually one by one, picking the right index for each yourself.
To be honest, I don't really know much about what he told me any more and I can't go back and ask him any longer. It's possible but I can't tell you yes or no for sure. It just evoked the memory of that conversation. Same with the Pick and MUMPS the other reply mentions. Doesn't ring a bell, seems possible though.
Data normalisation was huge in the past because of storage concerns. But it makes less sense now. There's still concerns of inconsistent data and duplication but often it's more performant to not do it to the extreme extent we learned to in the 90s with all the normal forms. It's still a good concept but no longer a strict rule.
The inconsistency can be covered with stored procedures and prepared statements which are also a great way to improve security (SQL injection)
So IMO excessive normalisation is no longer the be all and end all in this day and age. Just the way an RDBMS is always the way to go. Sometimes object storage is better.
But anyway I'm surprised you saw less normalisation in old code. Personally I saw much more then than now.
You also have to understand one thing (source: me, a sw developer since late 80s in Europe) - there was no internet, and most of the people working in the field had no CS degree.
This meant that neat new tricks (and stupid old mistakes) were done and (re)discovered all over the place, ALL THE TIME.
You might have decided that data normalization was a good idea, or you might have maybe got the idea by one of your mentors... but you could not know that precisely the same thing was being done/taught on the other side of the street, or even 2 floors below your office.
> Worse still, moving back to chair-making after a year or two, you discover that the old machines you knew are now obsolete and you have to re-learn how to run their replacements.
Love your analogy, it's all spot-on.
On the above, I'll add that the new chair-making machine is hardly ever better than the one from 2 years ago that you saw, it's simply all completely different for the sake of being disruptive to you its user. Most of the time it's actually worse, with fewer features and more restricted customization.
A puzzle: chair-creation was automated because creating every chair is expensive. Copying and shipping a piece of software costs nearly nothing, and still we're shouldering the absurd complexity of industrial production.
> Even if we did see then (and we mostly didn’t) that small, frequent releases were better in a whole bunch of ways, we couldn’t really do it. It was expensive to ship on physical media, and disruptive to our customers to have to do frequent installs.
It's still disruptive to customers. As a software engineer I love CD/CI. It makes the entire process much smoother and more efficient.
As a customer / end-user, though? Nope. I absolutely hate it. Maybe I'm just getting old but I'm extremely nostalgic for the days where I got to decide if I the upgrade was worth it to me or not. These days things will change and move you on without any notice or opt-in what-so-ever.
Sometimes when I play a retro game, I'm completely in awe of programmers of that vintage.
Games took a year or two to make, on massively constrained hardware, in assembly language, with no engines, all original artwork and music, and no bug fix updates after it was complete.
People like to pretend the future is always better and everything is advancing, but surely they had more talent than we do.
I feel like you're cherry-picking. Games have gotten way bigger content-wise and way more intense in many design aspects. Many retro games had massive teams and utilized earlier frameworks and content to release faster.
There are many old school techniques which are amazing and quite a few talented developers, but I wouldn't make a sweeping statement that "they" had more talent than "we" as a whole.
It's funny, though. Maybe it's just my age and not a comment on the quality of games, but I don't even play newer video games anymore. Every once in a while I'll start a game of Civilization IV (from 2005) if I have a lazy weekend and need a change of pace. I played a lot on the PS3 and then my PS4 was a dust collector. Complete buyers remorse there (and don't get me started on the fact that I needed an Internet connection on first boot to set it up. WTF?!!?!!!)
And I'll still sit and play Tetris for hours and hours and hours on my retro NES. The newer versions, not so much.
I've had this sense over the decades that as video games have grown in scope and graphics they've gotten less fun to the point where I tell people when they ask me "I don't play video games." It's probably been about ten years since I've paid for one.
Many retro games had massive teams and utilized earlier frameworks and content to release faster
I think you and the previous commenter have different ideas of what constitutes "retro."
The people I knew who worked on retro games usually were in "teams" of one or two, even if they worked for a massive company like Atari. If there were three people working on a video game, it was a huge deal. And "frameworks" weren't even a thing. Each game started from the ground up, with the exception of code clips that you printed out and saved in a binder.
You'd still need to name specific examples. All the way from the NES to the current gen, you can name examples of both big teams and small teams / individuals having some form of success.
The coding got easier per content unit and the skill floor is lower, yes. But the ceiling is still high, the demands are far higher and you'd need to be far more skilled in various disciplines to deliver the equivalent of a few decades ago. Those hours you gained no longer coding? You better have spent them figuring out how to do VFX, some decent pixel/line art, or make some stellar sound tracks. If not, maybe be able to do marketing or know how to make your game function in multiplayer online.
>And "frameworks" weren't even a thing.
Using virtually the same frame across a wide variety of processes is the very definition of a framework, even if it isn't a software framework in the modern sense. Many big games on the NES and SNES were built off of one another, you can tell by the similarities between developers and their work. Square being the most notorious.
There's an amazing interview series with Nasir Gebelli, who made some of the first Apple II games, coded the first three Final Fantasy games and a 3d game in assembler, as well as Secret of Mana game for SNES. Highly recommended!
> As a customer / end-user, though? Nope. I absolutely hate it. Maybe I'm just getting old but I'm extremely nostalgic for the days where I got to decide if I the upgrade was worth it to me or not. These days things will change and move you on without any notice or opt-in what-so-ever.
Yeah, even as someone who works as a developer, it seems that in all but a few cases the development organizations have a massively more control about how things are done than they should (which usually manifests as a veto by saying X is too hard/expensive). The overall effect is to make software crappy and annoying in ways that are less technical, and thus less likely to be fixed. Shipping on physical media put a technical constraint that helped keep that social problem in check.
Yup. In most businesses it seems the path to promotion for a Product Owner is to come up with that killer feature that will garner massive new adoption and launch the company into hyper-growth. This leads to existing end users being the sacrificial guinea pigs in a never ending experiment that place hypothetical (and almost never realized) future users over the immediate interests of those currently paying for the product.
This is why I turned off auto updates on my phone. I do update stuff periodically, and sometimes I'm forced (and certainly I do OS updates when there is a security issue), but I don't want my apps randomly changing out from under me overnight. Rarely these days are the "bug fixes and performance improvements" actually an improvement for me as the user. I especially hate it when a developer says something like "we update the app as often as possible to make it better for you!" No, updating it "as often as possible" is not better for me. It might be better for YOU, but it's just annoying to me.
I love it as a customer. There's a lot of excitement when new changes come out, and I want them right now!
Beyond business software, I can think of the way that indie games are delivered as early releases on Steam. Most recently, I would get excited for every little Valheim update. It extended the life of the game, which probably won't be truly done for many more years. If they were limited to a single boxed physical release, the game would be left with a shorter development cycle limited by the production budget. Now, the game's sales more directly dictate the level of attention the game gets. Concepts are validated earlier and customers get to more frequently provide feedback rather than developers spending years building something and hoping that people like it.
That particular developer also did a great job of generally not breaking your world and save game (somewhat unlike similar creative/survival games like Minecraft, where you'd be missing out on a lot of things by not starting fresh for each major update).
Sure, frequent updates can break things...but back in the day, there were still plenty of bugs on formally released products, and then you're stuck with those broken things for months or years waiting for the next version to physically ship to you.
One of the things that makes CD/CI possible in the first place is that testing has become far more automated and sophisticated. No one would tolerate CI/CD if it didn't have that additional level of automated quality.
When I see someone who claims not to like when software gets frequent updates, I ask myself: "Do you even like software? I thought new functionality was supposed to be exciting!" I personally see resistance to change as a generally negative personality trait (obviously, there are limits, not all change is good change), and I think that's why I don't understand the romantic nostalgia for the days when we'd buy a piece of software in a box off of a shelf.
In many cases, no. It's an adequate tool for some task I need to accomplish. And while some updates are genuinely useful and appreciated, others are regressions or just a change that I now have to get used to and which IMO doesn't make the software a better tool for the task at hand.
> When I see someone who claims not to like when software gets frequent updates, I ask myself: "Do you even like software?"
I used to. That's why I've dedicated 30 years of my life to making it.
But to be honest, not so much anymore. It's not just about breaking things, it's about CHANGING things. Things you paid for. Things you agreed to purchase in a certain shape and form. Forget video games, I'm talking about every day tools you use and depend on to do your daily job or life functions. Things like online banking - my bank suddenly rolled out a complete UX overhaul of their online system and omfg is it ever worse than it was before... I now need to take multiple steps and clicks to do something I used to be able to do in one step. They also broke the browser's back button etc.
And why does this happen? Not because brilliant teams of seasoned experts sat around the table, did focus groups and market research with existing customers to figure out how to make the product better. But because a lone Product Owner sees a path to promotion if they can figure out that one single killer feature that will get a massive new adoption of hypothetical new users (hardly ever realized). And so we, the end user, end up perpetual sacrificial guinea pigs in a never ending experiment that throws us under the bus because the business is chasing a hyper growth they are very unlikely to see.
If you're dealing with something like an indie video game, made by an individual or a small team of passionate people who actually care about their existing users and what to make things better for them then you're going to have a different experience. 99% of the tech industry today is not even in the same universe, let alone ballpark, as that.
To me, disliking greedy corporations and bad management isn't very connected to the method of delivery of products. Frequent and often automatic updates just represent that delivery method.
In contrast to your bank, my bank's website has added numerous improvements and modernizations that have made it easier, more useful, and less frustrating. Perhaps it's just time to switch banks?
There are plenty examples of badly managed products in the pre-SaaS era. If you bought Windows Me, it shipped as a terrible product and it never got better. As soon as you opened the shrink wrap you had no recourse but to wait for Windows XP to fix those problems.
Grand Theft Auto: Vice City featured a bug where saving at the ice cream factory was very likely to corrupt your save. The PS2 had no ability to apply patches or updates to games, so you were just stuck with the software that way forever.
So, you "agreed to purchase it in a certain shape and form" – but just like any other product you never truly know what you get until you made the purchase.
I have no problem with greedy corporations. What I don't like is people changing stuff on me when I didn't opt in to that change. Imagine if someone broke into your house and rearranged all your furniture. That's what it feels like. I don't like not owning my software and not being in control of things I pay for. I don't like not getting to decide if/when I upgrade and what I upgrade to. No one had to upgrade to Windows ME. That's my one and only point.
I don't know why you keep trying to shift the conversation back to video games. Video games are a very different type of software from most and I don't play them or have any interest in them. They're completely irrelevant to the conversation as far as I'm concerned.
Respectfully, I'm not straw-manning nor am I shifting any goal posts. Whether or not you agree with my arguments, I believe I am making them as consistently I can and in good faith.
I'm using video games are an easy example because it's simple to point to a specific gameplay bug that every player will encounter in those boxed games. Those kinds of experiences aren't as well documented for older productivity software. I understand you don't like video games but you should be able to understand the concept of my argument, for all purposes of our discussion these games can be considered to be generic software.
My overarching argument revolves around my belief that the bad things about software revolve around its business model, not from its delivery method in isolation.
>But because a lone Product Owner sees a path to promotion if they can figure out that one single killer feature that will get a massive new adoption of hypothetical new users (hardly ever realized).
This++. It's also the young hotshot phenomenon, where they come in and decide they can do everything better than the old timers (the previous hotshots 3-4 years ago), and change everything they can. We've all been there.
I have elderly family members, 85-plus, who can't understand why the UI changes all the time and they have to continually relearn. Explained this way, they get it, but still say, "they need to remember that not everyone wants to relearn everything every couple of years".
Yeah, I get frustrated about this A LOT. "Change for the sake of change", and chasing meaningless KPIs and metrics that involve ZERO value to users and only serve to benefit the vendor (usually at the expense of users, in fact).
> I love it as a customer. There's a lot of excitement when new changes come out, and I want them right now!...
> When I see someone who claims not to like when software gets frequent updates, I ask myself: "Do you even like software? I thought new functionality was supposed to be exciting!" I personally see resistance to change as a generally negative personality trait (obviously, there are limits, not all change is good change), and I think that's why I don't understand the romantic nostalgia for the days when we'd buy a piece of software in a box off of a shelf.
You seem to be thinking about this through the lens of computer games, which is probably not the right one to bring the problem into focus (then you pile on a bunch of personal judgement, which is frankly irritating).
Also, why should anyone "like software" (as a broad category)? That seems like putting the cart before the horse. I use software because it solves a problem I want solved (ideally with minimal effort); I don't find problems just to put software to use because I "like software." You don't seem to realize that "update" does not necessarily mean "improvement". Often an update is actually a regression to the user (most obviously because of bugs, but more perniciously through annoying changes like unnecessary UX redesigns or dropping features). I'm not "excited" when my workflows get broken or having my knowledge invalidated (e.g. changes that force me to waste effort re-learning how to do things I already knew how to do).
The nostalgia about buying software in a box off a shelf is nostalgia for having problems that stay solved. If that software worked, it would almost certainly continue to work until you made the decision to change something. Not anymore.
I think it’s easy to exaggerate how often updates are regressions, because the ones that don’t turn out so well are going to sit in our memory more strongly than all the other ones that worked fine.
It’s like if you go to Starbucks every day, and in 20 visits your coffee was prepared correctly. Then on the 21st visit, something was messed up.
Which experience would be most memorable? The one where they messed up, not the 20 other experiences where everything was fine.
Most updates to most software
are made in good faith. Companies (at least, the ones not in a complete monopoly) don’t try to scam their customers, they want to keep you happy so you keep buying. They’re not trying to mess up your workflow.
And this is why resistance to change is such an unattractive trait to me: if you’re learning every day like you’re supposed to, having to re-learn something shouldn’t be such a big deal, and it’s not like most software updates are going to just completely change how everything works (especially when they’re frequent and incremental). I think boxed software is actually worse in this regard. I always hated having to shell out a bunch of money all at once for the next version and then go through a more jarring migration process, because each update contained years of changes all at once.
Arguably, Microsoft’s ribbon interface in Office would never had happened if Office 365 existed at the time. They needed a big visual change they could show off in screenshots to stimulate discrete sales.
Apple managed to do something as extreme as changing the underlying file system of my computer with a routine update, no clean install or data migration required. If I wasn’t a tech enthusiast, I would have had no idea it even happened! Can you imagine how mind-blowing it would have been if we could have had that experience in 1998? For most people in the 90s, upgrading your OS meant buying an entirely new computer because it was just that difficult.
I’d personally rather not sit around being bitter and cynical about things being different now, maximizing the bad and minimizing the good.
Yeah, we like software. Probably every single person reading this site does. What we don't like is having constant new crap added that doesn't actually benefit us as users (like constantly-shifting user interface, new limitations that didn't exist before, "overhauls" that remove functionality we relied on or expected or were otherwise intimately familiar with). It's a waste of our time and energy, and causes stress.
Yeah, new functionality is neat, but it's an ignorantly-optimistic delusion to believe that frequent updates strictly involve new functionality. It's extremely common that updates involve literally zero benefit to the user, instead introducing some bullshit we didn't want like a "What's New?!" popup that now harasses every time you open the software (Miro, Discord, etc.), or a new notification icon that glows blatantly every time there's a new Awesome Sale available (looking at you, Guild Wars 2).
> When I see someone who claims not to like when software gets frequent updates, I ask myself: "Do you even like software? I thought new functionality was supposed to be exciting!"
Taking away a much loved feature is exciting? Losing more and more control over your own computer, over things you paid for, is exciting? Waiting an hour for your PS4 to install mandatory updates because you haven't turned it on in a few months is exciting?
Good god this is such a naive opinion. I suppose you think all change is good? Even if the people implementing them are greedy assholes in search of ego strokes or power trips?
What if I changed the balance of your checking account to $0? Would that be an exciting change?
For every update that delivers on its exciting new promise, there are four others that have made the life of its developers easier at the cost of their users.
Developers are the ones getting paid beaucorp bucks here, making their life easier should not be a higher priority than supporting things that users want.
Speaking as a developer and lifelong computer nerd of 30+ years.
Interesting example because the PS4 can update games automatically in rest mode while you sleep. It’s so much better than downloading patches manually like we used to do over our dial up connections.
I don’t think all change is good. I just think the anti-updates crowd are minimizing the good and maximizing the bad. Most software updates in our life are so seamless and uneventful that we might as well forget they exist.
You don’t remember the 20 times Starbucks made you a perfect cup of coffee, you remember the one time they messed up.
I think developers and lifelong computer needs like us completely forget that the regular person doesn’t give a shit about any of this. They just want it to work, and they like getting new stuff.
Seamless updating for most things is a relatively recent development. And yes, I notice it all the time, it's annoying as hell. Again, only occasionally do said updates actually improve anything. If we're lucky it will be as good as before. But often we're not, and something is lost.
(And rest mode or no, whenever I turn on my PS4 -- every couple of months -- there's always a stack of updates to deal with. And it always takes forever)
And Starbucks has never made me a perfect cup of coffee. Their beans are perpetually burnt and their process sucks. Back when I was a customer of theirs I had make my order so complicated it's frequently the butt of jokes. In all their haste to serve me and a thousand others every hour, they've stripped coffee down to the barest of essence, robbing it of any character that might have saved it.
Perhaps you've never known what it is like to truly master something, only to have it ripped out of your hands because reasons. I truly hate not having control over my software.
I turned off automatic app updates on my phone. It turns out some apps, especially Google ones, do get whiny at you for not updating. Other than that, changes at least happen when I expect them. Nothing can save me from A/B testing though...
Not so sure about the development/testing split of the waterfall, but two months up front just to design and gather requirements... feel like that might be a net benefit!
It sounds nice, but in reality your requirements end up being a castle in the sky. My team once spent 6 weeks for a small project (I was the team lead) creating a detailed requirements document with screenshots, a prototype app, etc. My users were all at hand and I showed them the prototype. They all agreed that it was what they wanted, and signed the requirements doc.
We spent several months building the application. When we shipped, the software was unusable, because a security feature that we had been explicitly told could wait for the second release turned out to be essential.
We also ran into a big problem with concurrent editing that no one had considered in advance, and blew up our carefully-created design.
The solution to changing requirements isn’t to nail them down, because that’s effectively impossible, but to get better at evolutionary design techniques (introduced by Extreme Programming) so you can adapt to arbitrary requirements changes without disruption.
It’s curmudgeonly, but I can’t help but bristle a bit at the ‘we didn’t have _____ when I was a programmer’ stuff because it very often existed in some substantial form.
Case in point, UI/UX- You could have user interface design as a job back then, perhaps at IBM working on ATMs. UI philosophy was a significant part of what was done at Xerox PARC, and you can read a 1989 article by Alan Kay on the topic:
http://worrydream.com/refs/Kay%20-%20User%20Interface,%20a%2...
In 1988 the first edition of the Handbook of Computer Human Interaction was published, a staggeringly expansive book on the subject, which included stuff like rapid prototyping, user acceptance and design review.
Sure, plenty of companies didn’t bother with this added expense, but that’s still the case today. The idea that it wasn’t there at all is misguided.
Another bit that seems off is mention how Java was ‘a total game changer’ when it came out. Cross-platform development was an exciting idea, but in practice, everything with Java was dog slow for quite a while. The true and eventual potential of the JVM was still opaque for years after the 1996 launch.
Xerox PARC was doing bleeding edge work. To compare anywhere else at the time with their revolutionary innovations, to claim that those companies just "didn't bother with the added expense" is absurd.
"Alls we had was waterfall" rankles too - and maybe it's just me but I've been hearing it a lot the last couple of years - particularly when most people first heard about "waterfall" was when someone made them do SCRUM.
And by 1989 OO was obviously the right thing for graphics and graphical user interfaces were arriving in a big way. MacApp was four years old. The original NeXT workstation had launched the year before. "niche" only in the sense that Turbo C++ was a year away.
https://en.wikipedia.org/wiki/MacApp
Or, it is what any half-competent witty student would do when they couldn’t finish their essay in time - send a corrupted .docx file and blame Moodle :)
The section about waterfall being the only SDLC is interesting because it touches on the economics of shipping and software engineering practices:
Continuous delivery only makes sense if the value of new feedback and delivered software is higher than the total cost of delivery. If you have to mail a floppy disk to each customer, that's a lot more expensive than just updating your production servers.
On my Amiga UX/UI design was a thing, layout, settings pages, forms, GUIs that did scale with different font sizes. At least for some companies, some UIs had horrible UX though. Like when they added shadow to text labels.
On my CPC I wrote a GUI library with auto layouts and muli step flows woth |RX (?) commands with characters like ┤ [1]
for borders - always reading Apple magazines.
Good point about the Amiga. Someone else here commented on Xerox PARC. So yes, there was UX design. However, in so many companies like the one I worked for in the story, it was utterly ignored.
We also tended to have long-term stays at companies. We usually had to maintain the software we wrote, so it encouraged us to at least leave some decent documentation breadcrumbs.
>We also tended to have long-term stays at companies.
I was at a minicomputer company (DG) from the mid-80s until the end of the 90s. Mostly PM for hardware. A lot of engineers had been there for a long time. Even more so, people in support functions of various types. There was one woman who I think may have been the only person who knew our BOM and related systems inside out. I think there are still a few people I worked with who are still there (by way of EMC and Dell).
At least as of a few years ago, one of them was one of the engineers who worked on the computer that was chronicled in Soul of a New Machine.
Graphical vector mini-supers. Unix and vax environments, with SUN ruling the roost and SGI crashing in. Multiple instances of what became things like knime. X11 and multiple vendor-specific gui toolkits. Excellent vectorizing compilers for Fortran and C. 4 and 8 core multiprocessors. Granted, it wasn’t as fast but there was lots there which people probably forget.
Software wise, there were research groups with all of the ml/ai areas in chemistry (Gasteiger, others) so I assume they were active elsewhere. The quants were starting upon Wall Street and they needed visualization systems to know whether their model is going up or down. Stereotactic imaging for medical uses, fluid dynamics and finite element analysis were leading to changes in car and airplane design,
Microprocessors killed off this ecosystem - the pa-risc chip from HP could be a soft pc faster than a 486 could be a pc. But don’t think it wasn’t there. Hell, all of the foundation was laid by (mostly) hackers in the 60’s and 70’s that were building on now. It just used way less memory :-)
And don’t forget the work from the folks at bell labs. And neat stuff like the blit.
> There was no working from home. The minicomputers were available only on the in-office network. I think it was not technically impossible to connect them to the Internet, but at home we all had only dialup access. Not only would speed have been a concern, but the family wouldn’t enjoy having the phone tied up for hours while you worked.
I was lucky in that I got to work remotely from the beginning. Late 80s at the university I set up a modem bank to one of the UNIX boxes and installed a second phone line at home, so I was dialed in pretty much 24x7 (at 2400 baud, of course, but with an all-text terminal session it's fine and usable).
At first job they had dialup into the Sun servers as well, so I often worked from home (by now at 14.4 and later 56K at which point remote X was doable).
>Every last software engineer at ACD was a white man
Interesting, where I was at the time, it was a 60/40 split between men and women. Also I would say 10% were people of color. And one person was completely blind.
Two of the smartest people there were people of color, early on (before 1989) I learned a lot from them.
I think this statement goes too far in that case, I'd walk it back:
> The software industry was a far less diverse place then.
It probably makes sense when talking specifically about the midwest, due to demographics. But out here in SoCal in the 90s, I had a south asian boss and foreign national engineers from a number of countries working side by side. China, Italy, Norway. It was a big facility and we had US minority employees as well, although not a huge number. Software dept was 1/4 women approximately.
Re: being gay it was the "don't ask, don't tell" days. No one I knew cared in the least. An interesting angle is I wasn't perceptive about it as a young person. Looking back in the hindsight of maturity, obviously gay people were everywhere. Just like in Hollywood, everyone just winked and nudged. Right, Uncle Arthur is ~fifty, unmarried, and rather flamboyant, nothing to see here. ;-)
It's interesting, my experience at a FANG (which invests heavily in recruiting women engineers) is that approximately 25% of teams are 60/40 men/women, and 75% of them are 100% men. The women I've worked with have told me that this is not a coincidence, that they very quickly learn which managers they will not work under or which coworkers they will not be on a team with, and that they take the presence of other women on the team as an indicator that none of these characters are present.
I wonder if the same principal operates geographically - certain regions find that they just never encounter women or minorities in the workforce, and it may have as much to do with the region as the people.
My very first programming job was in 1991 or 92 writing an interactive kiosk based upon a touch screen driven by an Amiga, using the multimedia platform Scala (quite similar to the later Macromedia Director, but it still exists).
Then with a colleague we developed an interactive phone application (the sort that asks you to "press 1 for this, press 2 for that, press # to go back to the menu") on a SCO Unix system, in some sort of weird BASIC. While one of us tested the application on the phone, the other one played "X-whack-a-mole" :)
I got my start in the software industry in that building, too. I was an intern at Rose-Hulman Ventures in 2005, building tax administration software for Indiana counties in C# 1.0 WinForms with Visual SourceSafe and Microsoft SQL Server. VSS required you to take a lock on a file to be able to edit it (there’s no merge ability) so I spent a full afternoon one day separating our data access layer class into partial classes so it would be spread across multiple files, and more than one developer could write a stored procedure wrapper at a time! Likewise, our bug database also only had enough licenses for one or two people to be logged in at a time, so we printed out our tickets to work on them. Learned a lot that summer, especially the fundamentals of databases and software architecture. Also learning C# that early gave me a ton of experience and willingness to work with C# again in my next few jobs.
Well, you survived using Visual Source Safe. (I've lost so much hard work with that tool). I worked on stuff one generation before C#. Visual FoxPro was my money maker for awhile.
We had a “robust” backup strategy. (Taking a copy of the source code onto the file share every night.) Definitely lost VSS revision history at least once. I don’t know how VSS ever made it to customers!
You’re right, I misremembered! I made a hideous inheritance chain instead:
abstract class UserDAL { }
abstract class ParcelDAL : UserDAL { }
...
abstract class DAL_n : DAL_n_minus_1 { }
class DataAccessLayer : DAL_n { }
each in their own file, of course. I tried to give them descriptive names and very narrow scopes. But inheritance is pretty dumb here. What does it mean for ParcelDAL to extend UserDAL? A parcel is not a user. When C# 2 came out, I was able to get rid of the inheritance and make them all part of one big partial class, keeping the file names the same.
201 comments
[ 4.8 ms ] story [ 257 ms ] threadThe closest I've had to this was working at a company that had been around for close to thirty years and had kept many of the original developers (they'd taken the product from a terminal interface to the web, from cobol to c#) and had many stories like the one in the original post.
Which makes sense, given working in embedded hardware (especially in classified contexts) back then came with a lot of the same limitations described in the article - software had to be delivered by sneaker-net, installation was burdensome, you couldn't just fire up the application for a quick bug fix at home, etc. Not to mention the inertia of having Always Done It That Way.
I wish I was this person. I'm one of those (great majority of) people whose documentation you'd hate.
I deeply hate writing like that because I can never properly explain my tangled thoughts. Even my comments on sites like that are at most few liners. Describing things in code is much easier, since you don't have centuries of context written into words.
I think you'd benefit from looking at writing differently. What you describe--"I can never properly explain my tangled thoughts"--is the essence of composition. The goal of the process of writing is to untangle those thoughts and express them!
When I say "process," I don't just mean that you begin typing immediately. Composition is about planning as well. Even if you spend just a few minutes making a list of keywords & important concepts then arrange them on cards in the order you think you should present them in, I bet it would help writing your initial draft of a document.
If that doesn't appeal to you, so be it, but look into a composition course, because I genuinely think you could turn something you hate into something that helps. You might never fall in love with writing, but that doesn't mean it can't be a tool that solves problems for you.
Just keep writing, and get feedback on each piece of writing. It gets better.
It's 3000 lines and took me four years and countless revisions, but I feel it was worth it. I actually enjoyed writing the spec even more than writing the reference implementation :)
Is there anyone using it? It's always great to have extra ammunition to make a strong case that we should use this instead of, say, XML.
There are still a few things to do:
- Update enctool (https://github.com/kstenerud/enctool) to integrate https://cuelang.org so that there's at least a command line schema validator for CE.
- Update the grammar file (https://github.com/kstenerud/concise-encoding/tree/master/an...) because it's a bit out of date.
- Revamp the compliance tests to be themselves written in Concise Encoding (for example https://github.com/kstenerud/go-concise-encoding/blob/master... but I'll be simplifying the format some more). That way, we can run the same tests on all CE implementations instead of everyone coming up with their own. I'll move the test definitions to their own repo when they're done and then you can just submodule it.
I'm thinking that they should look more like:
I brought a friend of mine to give a couple lectures at our company for this exact reason. He's a professor of non-fiction. There's a couple techniques we learned you can use:
- "madman architect carpenter judge"
- shitty first draft
- The most dangerous writing app, https://www.squibler.io/dangerous-writing-prompt-app
They're all fundamentally the same concept: write first, edit second.
Got the job and started with dBase II on Concurrent DOS.
I was surprised by the date of the article at first!
Around 1998 Gray had built something called TerraServer, must have been years before Google Maps or OSM. It was a real eye opener at the time to see my little house in the middle of nowhere in Northern Europe on the internet published for free by an American company. At the time PC disk sizes where still measured in Megabytes, so you weren't even able to store that many aerial pictures. At least not pictures of current size. Probably they were smaller then, don't have any data.
Edit: [1] https://en.m.wikipedia.org/wiki/David_Parnas
Edit: The author will probably smile at this post: https://news.ycombinator.com/item?id=30365800
There really wasn't any such thing as a tech stack - our company would produce software for various Unixen and, especially, Vax, and the language was alway C, with some Pascal on the Vax side (as, I was told, the Vax Pascal compiler produced far more optimal code than the C compiler).
Being a software engineer was like being a furniture-maker. You had to master a small number of tools - the saw, the chisel - and then craftsmanship consisted of discovering an affinity with these tools and a love of getting ever more skilled at using them. This path wasn't for everyone, which was fine - plenty of management and other non-tech roles for those folks - but if you grooved with your tools it was a real joy to be able to move from chair- to table- to cabinet-making and carry and refine your skills as you went.
This idyll could not last, however. Before too long it became uneconomical to make furniture this way, so for your chair making project you instead had to learn how to run a chair-making machine. When you moved onto a tables project, the machines there were infuriatingly dissimilar to the chair-making ones you'd just mastered. Worse still, moving back to chair-making after a year or two, you discover that the old machines you knew are now obsolete and you have to re-learn how to run their replacements. This stops being fun, or interesting, after a while, and yet sadly it's all that most younger software engineers know.
Occasionally, there is the need to make some shim or gizmo that the machines don't cover, so out come the trusty saw and chisel of yore - much to the amazement of the young'uns, who are astonished that an old-timer can still wield these antiques so effectively.
There's some 'cleverness' lost probably, in the new ways vs the old. I've seen some pretty novel approaches to what should be simple tasks in legacy code. And I do recognize that for what it is. But as impressive as that cleverness can be, I think it's one of the reasons as to why a lot of legacy code persists and nobody wants to touch it. Among many other reasons.
Nowadays, we have linters to point out common classes of mistakes, programming languages with actual type systems to enforce invariants, integrated testing tools, etc...
Note that, yes, we do still have new, terrible codebases. But at least the tooling nowadays raised the bar to have a minimum floor of quality that, while very low, is still oh so much higher than it used to be.
I've looked at 1990s code in the Windows NT kernel. It was wonderful.
Oldest source file I went through was from 1993. Perfectly readable and understandable.
One of the best modern code bases I ever worked in didn't even have a linter setup. The principle dev reviewed every single commit and enforced a consistency across the code base that was better than what any tools ever could have done.
How was it so much better that it justified that level of busywork on the part of the senior member of the team (and busywork for everyone else, to fix the style nits they enforced in review)? I would have guessed that taking a few hours to install and configure a formatting linter to free up the principal dev's time to focus on other things would have been hugely high leverage.
Developers quickly set their IDEs to follow the team's coding guidelines, style wasn't really a problem.
> Nowadays, we have linter
I was using a C linter in 1986. The tooling is better now but it still comes down to the author.
Putting BEGIN..END around a one line block was always a contention since it wasn't required. Less code vs arguably more readable code (Pascal)
vsThis is nonsense. The worst authors can still produce bad code with the best tools and the best authors can still produce good code with the worst tools, but most authors are somewhere in the middle, and tooling makes a huge difference to the average.
And as an oldster you be happy again to see the lack of object orientation and not the 5 level misabstracted inheritance hierarchy someone didn't do for purpose but just because university taught the modern way to automatically end up with sane structured code... and sure sure every tool can be used well or misused and never overgeneralize 8-)
I may be wrong but youngsters as oldsters have both their own rose tinted glasses.
When I told him about SQL databases. Relational stuff, normalization. Awesome.
He told me that was all fine and dandy but just too slow, this new fangled SQL database stuff. He used databases where you simply accessed rows by key. If you needed to access something by a different key you just made a different table where the same data was arranged by that key instead. Super performant.
Of course my dad also programmed in languages like 370 assembler.
Funny how the young folks today talk about NoSQL databases indeed.
Relational databases really weren't all that practical back in the day with the hardware that was available. Putting thought into defining how you are going to query your data was available though. Relational algebra wasn't a thing from the start either.
If someone comes along and tells you that you don't have to know all this up-front and you can come up with a query you want to ask about the data you have, you will be able to, isn't that awesome? Ad-hoc, just like that. No need to carefully transform the data you have, ensure you keep it all up-to-date in multiple places etc. Of course data volumes grow and even the newer hardware you have can soon no longer handle what you got in a timeframe that you like. Indexing will be a thing. Of course even indexes grow way too huge to really perform, but hardware to the rescue, where at least all the indexes you need frequently will fit in RAM. Lots of caching going on too for your regular workloads.
Guess where the story is going? Well of course there's the old analytical vs. transactional load thing, i.e. your "Data Warehouse" is a separate database that is optimized for the pre-defined queries again, actually de-normalizing lots of things, being on different hardware, so as not to disturb warm caches for the transactional load etc. And yes, finally NoSQL again, i.e. back to the roots. Put more thought into how you're going to query this as your globe spanning SaaS load won't fit onto the hardware you have available. Of course this brings problems because we're just so good at predicting what kind of query we want to ask about our data. Databases like MongoDB, Cassandra, AWS DocumentDB etc. grow indexes supporting querying arbitrarily ... There's a hole in my bucket dear Liza, dear Liza ... :)
[I'm sure this nice story line is not globally completely correct/adhering to exact timelines but illustrates the point]
The inconsistency can be covered with stored procedures and prepared statements which are also a great way to improve security (SQL injection)
So IMO excessive normalisation is no longer the be all and end all in this day and age. Just the way an RDBMS is always the way to go. Sometimes object storage is better.
But anyway I'm surprised you saw less normalisation in old code. Personally I saw much more then than now.
This meant that neat new tricks (and stupid old mistakes) were done and (re)discovered all over the place, ALL THE TIME. You might have decided that data normalization was a good idea, or you might have maybe got the idea by one of your mentors... but you could not know that precisely the same thing was being done/taught on the other side of the street, or even 2 floors below your office.
It amazes me how many interesting private (never published) ideas is in any proprietary codebase that had high-caliber engineers working on it.
Love your analogy, it's all spot-on.
On the above, I'll add that the new chair-making machine is hardly ever better than the one from 2 years ago that you saw, it's simply all completely different for the sake of being disruptive to you its user. Most of the time it's actually worse, with fewer features and more restricted customization.
It's still disruptive to customers. As a software engineer I love CD/CI. It makes the entire process much smoother and more efficient.
As a customer / end-user, though? Nope. I absolutely hate it. Maybe I'm just getting old but I'm extremely nostalgic for the days where I got to decide if I the upgrade was worth it to me or not. These days things will change and move you on without any notice or opt-in what-so-ever.
Games took a year or two to make, on massively constrained hardware, in assembly language, with no engines, all original artwork and music, and no bug fix updates after it was complete.
People like to pretend the future is always better and everything is advancing, but surely they had more talent than we do.
There are many old school techniques which are amazing and quite a few talented developers, but I wouldn't make a sweeping statement that "they" had more talent than "we" as a whole.
And I'll still sit and play Tetris for hours and hours and hours on my retro NES. The newer versions, not so much.
I've had this sense over the decades that as video games have grown in scope and graphics they've gotten less fun to the point where I tell people when they ask me "I don't play video games." It's probably been about ten years since I've paid for one.
Now get off my lawn.
I think you and the previous commenter have different ideas of what constitutes "retro."
The people I knew who worked on retro games usually were in "teams" of one or two, even if they worked for a massive company like Atari. If there were three people working on a video game, it was a huge deal. And "frameworks" weren't even a thing. Each game started from the ground up, with the exception of code clips that you printed out and saved in a binder.
The coding got easier per content unit and the skill floor is lower, yes. But the ceiling is still high, the demands are far higher and you'd need to be far more skilled in various disciplines to deliver the equivalent of a few decades ago. Those hours you gained no longer coding? You better have spent them figuring out how to do VFX, some decent pixel/line art, or make some stellar sound tracks. If not, maybe be able to do marketing or know how to make your game function in multiplayer online.
>And "frameworks" weren't even a thing.
Using virtually the same frame across a wide variety of processes is the very definition of a framework, even if it isn't a software framework in the modern sense. Many big games on the NES and SNES were built off of one another, you can tell by the similarities between developers and their work. Square being the most notorious.
Can't think of any modern game - made in that short a time - that is bigger content wise (unless we're just summing up all the pixels).
https://podcasts.apple.com/gh/podcast/episode-3-nasir-gebell...
Yeah, even as someone who works as a developer, it seems that in all but a few cases the development organizations have a massively more control about how things are done than they should (which usually manifests as a veto by saying X is too hard/expensive). The overall effect is to make software crappy and annoying in ways that are less technical, and thus less likely to be fixed. Shipping on physical media put a technical constraint that helped keep that social problem in check.
Beyond business software, I can think of the way that indie games are delivered as early releases on Steam. Most recently, I would get excited for every little Valheim update. It extended the life of the game, which probably won't be truly done for many more years. If they were limited to a single boxed physical release, the game would be left with a shorter development cycle limited by the production budget. Now, the game's sales more directly dictate the level of attention the game gets. Concepts are validated earlier and customers get to more frequently provide feedback rather than developers spending years building something and hoping that people like it.
That particular developer also did a great job of generally not breaking your world and save game (somewhat unlike similar creative/survival games like Minecraft, where you'd be missing out on a lot of things by not starting fresh for each major update).
Sure, frequent updates can break things...but back in the day, there were still plenty of bugs on formally released products, and then you're stuck with those broken things for months or years waiting for the next version to physically ship to you.
One of the things that makes CD/CI possible in the first place is that testing has become far more automated and sophisticated. No one would tolerate CI/CD if it didn't have that additional level of automated quality.
When I see someone who claims not to like when software gets frequent updates, I ask myself: "Do you even like software? I thought new functionality was supposed to be exciting!" I personally see resistance to change as a generally negative personality trait (obviously, there are limits, not all change is good change), and I think that's why I don't understand the romantic nostalgia for the days when we'd buy a piece of software in a box off of a shelf.
In many cases, no. It's an adequate tool for some task I need to accomplish. And while some updates are genuinely useful and appreciated, others are regressions or just a change that I now have to get used to and which IMO doesn't make the software a better tool for the task at hand.
I used to. That's why I've dedicated 30 years of my life to making it.
But to be honest, not so much anymore. It's not just about breaking things, it's about CHANGING things. Things you paid for. Things you agreed to purchase in a certain shape and form. Forget video games, I'm talking about every day tools you use and depend on to do your daily job or life functions. Things like online banking - my bank suddenly rolled out a complete UX overhaul of their online system and omfg is it ever worse than it was before... I now need to take multiple steps and clicks to do something I used to be able to do in one step. They also broke the browser's back button etc.
And why does this happen? Not because brilliant teams of seasoned experts sat around the table, did focus groups and market research with existing customers to figure out how to make the product better. But because a lone Product Owner sees a path to promotion if they can figure out that one single killer feature that will get a massive new adoption of hypothetical new users (hardly ever realized). And so we, the end user, end up perpetual sacrificial guinea pigs in a never ending experiment that throws us under the bus because the business is chasing a hyper growth they are very unlikely to see.
If you're dealing with something like an indie video game, made by an individual or a small team of passionate people who actually care about their existing users and what to make things better for them then you're going to have a different experience. 99% of the tech industry today is not even in the same universe, let alone ballpark, as that.
In contrast to your bank, my bank's website has added numerous improvements and modernizations that have made it easier, more useful, and less frustrating. Perhaps it's just time to switch banks?
There are plenty examples of badly managed products in the pre-SaaS era. If you bought Windows Me, it shipped as a terrible product and it never got better. As soon as you opened the shrink wrap you had no recourse but to wait for Windows XP to fix those problems.
Grand Theft Auto: Vice City featured a bug where saving at the ice cream factory was very likely to corrupt your save. The PS2 had no ability to apply patches or updates to games, so you were just stuck with the software that way forever.
So, you "agreed to purchase it in a certain shape and form" – but just like any other product you never truly know what you get until you made the purchase.
I have no problem with greedy corporations. What I don't like is people changing stuff on me when I didn't opt in to that change. Imagine if someone broke into your house and rearranged all your furniture. That's what it feels like. I don't like not owning my software and not being in control of things I pay for. I don't like not getting to decide if/when I upgrade and what I upgrade to. No one had to upgrade to Windows ME. That's my one and only point.
I don't know why you keep trying to shift the conversation back to video games. Video games are a very different type of software from most and I don't play them or have any interest in them. They're completely irrelevant to the conversation as far as I'm concerned.
I'm using video games are an easy example because it's simple to point to a specific gameplay bug that every player will encounter in those boxed games. Those kinds of experiences aren't as well documented for older productivity software. I understand you don't like video games but you should be able to understand the concept of my argument, for all purposes of our discussion these games can be considered to be generic software.
My overarching argument revolves around my belief that the bad things about software revolve around its business model, not from its delivery method in isolation.
This++. It's also the young hotshot phenomenon, where they come in and decide they can do everything better than the old timers (the previous hotshots 3-4 years ago), and change everything they can. We've all been there.
I have elderly family members, 85-plus, who can't understand why the UI changes all the time and they have to continually relearn. Explained this way, they get it, but still say, "they need to remember that not everyone wants to relearn everything every couple of years".
> When I see someone who claims not to like when software gets frequent updates, I ask myself: "Do you even like software? I thought new functionality was supposed to be exciting!" I personally see resistance to change as a generally negative personality trait (obviously, there are limits, not all change is good change), and I think that's why I don't understand the romantic nostalgia for the days when we'd buy a piece of software in a box off of a shelf.
You seem to be thinking about this through the lens of computer games, which is probably not the right one to bring the problem into focus (then you pile on a bunch of personal judgement, which is frankly irritating).
Also, why should anyone "like software" (as a broad category)? That seems like putting the cart before the horse. I use software because it solves a problem I want solved (ideally with minimal effort); I don't find problems just to put software to use because I "like software." You don't seem to realize that "update" does not necessarily mean "improvement". Often an update is actually a regression to the user (most obviously because of bugs, but more perniciously through annoying changes like unnecessary UX redesigns or dropping features). I'm not "excited" when my workflows get broken or having my knowledge invalidated (e.g. changes that force me to waste effort re-learning how to do things I already knew how to do).
The nostalgia about buying software in a box off a shelf is nostalgia for having problems that stay solved. If that software worked, it would almost certainly continue to work until you made the decision to change something. Not anymore.
It’s like if you go to Starbucks every day, and in 20 visits your coffee was prepared correctly. Then on the 21st visit, something was messed up.
Which experience would be most memorable? The one where they messed up, not the 20 other experiences where everything was fine.
Most updates to most software are made in good faith. Companies (at least, the ones not in a complete monopoly) don’t try to scam their customers, they want to keep you happy so you keep buying. They’re not trying to mess up your workflow.
And this is why resistance to change is such an unattractive trait to me: if you’re learning every day like you’re supposed to, having to re-learn something shouldn’t be such a big deal, and it’s not like most software updates are going to just completely change how everything works (especially when they’re frequent and incremental). I think boxed software is actually worse in this regard. I always hated having to shell out a bunch of money all at once for the next version and then go through a more jarring migration process, because each update contained years of changes all at once.
Arguably, Microsoft’s ribbon interface in Office would never had happened if Office 365 existed at the time. They needed a big visual change they could show off in screenshots to stimulate discrete sales.
Apple managed to do something as extreme as changing the underlying file system of my computer with a routine update, no clean install or data migration required. If I wasn’t a tech enthusiast, I would have had no idea it even happened! Can you imagine how mind-blowing it would have been if we could have had that experience in 1998? For most people in the 90s, upgrading your OS meant buying an entirely new computer because it was just that difficult.
I’d personally rather not sit around being bitter and cynical about things being different now, maximizing the bad and minimizing the good.
Yeah, new functionality is neat, but it's an ignorantly-optimistic delusion to believe that frequent updates strictly involve new functionality. It's extremely common that updates involve literally zero benefit to the user, instead introducing some bullshit we didn't want like a "What's New?!" popup that now harasses every time you open the software (Miro, Discord, etc.), or a new notification icon that glows blatantly every time there's a new Awesome Sale available (looking at you, Guild Wars 2).
Taking away a much loved feature is exciting? Losing more and more control over your own computer, over things you paid for, is exciting? Waiting an hour for your PS4 to install mandatory updates because you haven't turned it on in a few months is exciting?
Good god this is such a naive opinion. I suppose you think all change is good? Even if the people implementing them are greedy assholes in search of ego strokes or power trips?
What if I changed the balance of your checking account to $0? Would that be an exciting change?
For every update that delivers on its exciting new promise, there are four others that have made the life of its developers easier at the cost of their users.
Developers are the ones getting paid beaucorp bucks here, making their life easier should not be a higher priority than supporting things that users want.
Speaking as a developer and lifelong computer nerd of 30+ years.
I don’t think all change is good. I just think the anti-updates crowd are minimizing the good and maximizing the bad. Most software updates in our life are so seamless and uneventful that we might as well forget they exist.
You don’t remember the 20 times Starbucks made you a perfect cup of coffee, you remember the one time they messed up.
I think developers and lifelong computer needs like us completely forget that the regular person doesn’t give a shit about any of this. They just want it to work, and they like getting new stuff.
(And rest mode or no, whenever I turn on my PS4 -- every couple of months -- there's always a stack of updates to deal with. And it always takes forever)
And Starbucks has never made me a perfect cup of coffee. Their beans are perpetually burnt and their process sucks. Back when I was a customer of theirs I had make my order so complicated it's frequently the butt of jokes. In all their haste to serve me and a thousand others every hour, they've stripped coffee down to the barest of essence, robbing it of any character that might have saved it.
Perhaps you've never known what it is like to truly master something, only to have it ripped out of your hands because reasons. I truly hate not having control over my software.
Waterfall up front, party in the back?
We spent several months building the application. When we shipped, the software was unusable, because a security feature that we had been explicitly told could wait for the second release turned out to be essential.
We also ran into a big problem with concurrent editing that no one had considered in advance, and blew up our carefully-created design.
The solution to changing requirements isn’t to nail them down, because that’s effectively impossible, but to get better at evolutionary design techniques (introduced by Extreme Programming) so you can adapt to arbitrary requirements changes without disruption.
Case in point, UI/UX- You could have user interface design as a job back then, perhaps at IBM working on ATMs. UI philosophy was a significant part of what was done at Xerox PARC, and you can read a 1989 article by Alan Kay on the topic: http://worrydream.com/refs/Kay%20-%20User%20Interface,%20a%2...
In 1988 the first edition of the Handbook of Computer Human Interaction was published, a staggeringly expansive book on the subject, which included stuff like rapid prototyping, user acceptance and design review.
Sure, plenty of companies didn’t bother with this added expense, but that’s still the case today. The idea that it wasn’t there at all is misguided.
Another bit that seems off is mention how Java was ‘a total game changer’ when it came out. Cross-platform development was an exciting idea, but in practice, everything with Java was dog slow for quite a while. The true and eventual potential of the JVM was still opaque for years after the 1996 launch.
And by 1989 OO was obviously the right thing for graphics and graphical user interfaces were arriving in a big way. MacApp was four years old. The original NeXT workstation had launched the year before. "niche" only in the sense that Turbo C++ was a year away. https://en.wikipedia.org/wiki/MacApp
Continuous delivery only makes sense if the value of new feedback and delivered software is higher than the total cost of delivery. If you have to mail a floppy disk to each customer, that's a lot more expensive than just updating your production servers.
On my Amiga UX/UI design was a thing, layout, settings pages, forms, GUIs that did scale with different font sizes. At least for some companies, some UIs had horrible UX though. Like when they added shadow to text labels.
On my CPC I wrote a GUI library with auto layouts and muli step flows woth |RX (?) commands with characters like ┤ [1] for borders - always reading Apple magazines.
[1] https://en.wikipedia.org/wiki/Amstrad_CPC_character_setWe also tended to have long-term stays at companies. We usually had to maintain the software we wrote, so it encouraged us to at least leave some decent documentation breadcrumbs.
I was at a minicomputer company (DG) from the mid-80s until the end of the 90s. Mostly PM for hardware. A lot of engineers had been there for a long time. Even more so, people in support functions of various types. There was one woman who I think may have been the only person who knew our BOM and related systems inside out. I think there are still a few people I worked with who are still there (by way of EMC and Dell).
At least as of a few years ago, one of them was one of the engineers who worked on the computer that was chronicled in Soul of a New Machine.
Software wise, there were research groups with all of the ml/ai areas in chemistry (Gasteiger, others) so I assume they were active elsewhere. The quants were starting upon Wall Street and they needed visualization systems to know whether their model is going up or down. Stereotactic imaging for medical uses, fluid dynamics and finite element analysis were leading to changes in car and airplane design,
Microprocessors killed off this ecosystem - the pa-risc chip from HP could be a soft pc faster than a 486 could be a pc. But don’t think it wasn’t there. Hell, all of the foundation was laid by (mostly) hackers in the 60’s and 70’s that were building on now. It just used way less memory :-)
And don’t forget the work from the folks at bell labs. And neat stuff like the blit.
(the ACID properties database guru)
The about page of the blog does not tell me much about the author (it would have been nice to mention some projects or other milestones).
I was lucky in that I got to work remotely from the beginning. Late 80s at the university I set up a modem bank to one of the UNIX boxes and installed a second phone line at home, so I was dialed in pretty much 24x7 (at 2400 baud, of course, but with an all-text terminal session it's fine and usable).
At first job they had dialup into the Sun servers as well, so I often worked from home (by now at 14.4 and later 56K at which point remote X was doable).
Interesting, where I was at the time, it was a 60/40 split between men and women. Also I would say 10% were people of color. And one person was completely blind.
Two of the smartest people there were people of color, early on (before 1989) I learned a lot from them.
This was in the northeast
> The software industry was a far less diverse place then.
It probably makes sense when talking specifically about the midwest, due to demographics. But out here in SoCal in the 90s, I had a south asian boss and foreign national engineers from a number of countries working side by side. China, Italy, Norway. It was a big facility and we had US minority employees as well, although not a huge number. Software dept was 1/4 women approximately.
Re: being gay it was the "don't ask, don't tell" days. No one I knew cared in the least. An interesting angle is I wasn't perceptive about it as a young person. Looking back in the hindsight of maturity, obviously gay people were everywhere. Just like in Hollywood, everyone just winked and nudged. Right, Uncle Arthur is ~fifty, unmarried, and rather flamboyant, nothing to see here. ;-)
I wonder if the same principal operates geographically - certain regions find that they just never encounter women or minorities in the workforce, and it may have as much to do with the region as the people.
Then with a colleague we developed an interactive phone application (the sort that asks you to "press 1 for this, press 2 for that, press # to go back to the menu") on a SCO Unix system, in some sort of weird BASIC. While one of us tested the application on the phone, the other one played "X-whack-a-mole" :)