There's truth in it, but he omits the context for why these changes happened.

In 1990, real software companies could get away with shipping something major less than annually. Companies paced development to events like the annual Comdex. No company was expected to ship production software weekly, let alone daily. Competitive threats arose more slowly because there was less capital. The US software industry could be reasonably sure a Chinese firm wasn't going to suddenly arrive and become a material strategic concern in a few quarters. Seriously, read books describing 1990s era software dev and see how slowly things are paced before the Internet really hit. Look at the time scales involved. Even the rise of mighty Microsoft, considered the poster child of rapid high-tech growth circa 1992, pales in comparison to the Internet giants.

The world sped up. I hate the meeting culture we have now, but it's important to understand that it is a response to the pace of change rapidly increasing over the last 24 hours.

The other thing that really happened is the consumerization of software. In 1990, a much smaller slice of people used any computer in a given day. Frequently, those people could be expected to have undergone specific training for your product. Today, the number approaches 100% of adults globally. This means a higher level of fit, finish, and robustness are required now versus in 1990. Expectations are far higher.

Third, and I can't believe this needs to be said, but Microsoft was known for especially buggy software during the glory days highlighted in the article. Their OS releases were frequently late. They had to abort/restart the Vista project. Aside from the aesthetic factors of crashy software, it is somewhat obviously bad to have a multi-billion dollar company be unable to predict when (if?) its flagship products will ship, and in what form. Obviously, something had to change.

There's a lot to learn from the old days, but if one doesn't understand why things changed, one is likely to take the wrong lessons from history.

> The other thing that really happened is the consumerization of software.

Yes. Our customers were, for the most part, nerds like us in the 90's. We knew what features they wanted because we wanted them.

My experience at Microsoft in the late 90s and early 00s jives with his descriptions, mostly. But the essay went out of its way to be cynical and reductive.

He's not making things up, but I don't think his takeaways are worth, well, taking any further.

Same period of employment for me too and I agree that it mostly matches my experience. Even though I find the article an exaggerated polemic, there are a few things that really resonate with me:

1. Open offices are stupid. For proof just see how many people love working from home where they have far fewer unwanted distractions. Yes there are other reasons to like remote work too, but I bet lack of distracting surroundings is up there.

2. Not having dedicated QA is mega stupid for something like Windows. You can clearly see that in Windows 10.

Other than that, yes I am a bit more accepting of some of the newer stuff, but I get where he's coming from. y'all need to get off my lawn.

If open offices were kept to the same atmosphere as libraries, I don't think there would be such an issue.

But it's truly bizarre that they're not, and companies think that is OK to put people in an environment that is the completely opposite of the environment it should be.

So culturally which style of working do you prefer yourself? Or if it’s not binary, are there parts of how software was written yesterday that you’d like to bring into organizations today, whether mentioned in the article or not?

There's room for both extreme concentration and extreme communication, and most teams need some of each.

I actually snorted at the essay's idea that communication and concentration can't mix. I'm not sure what he thinks email and detailed specs are if not communication. I think the key is that they're batch-mode communication.

I can see value in several hours a day of concentration unbroken by communication, but insisting on a full week straight of unbroken concentration is impractical and possibly counterproductive.

It's not that there was NO communication. He said that he'd go to QA and fix anything that they found. It's just that it was more informal, and you did it when it was time to do it, but not just meetings every day that are required, even when there's nothing really to say, or what couldn't be done in a 15 second or one minute conversation. And you could do it on your own time, so you didn't have to stop right in the middle of some super productive time when you're on a roll. Because that's how it works - some coding time is more productive than other time. You're just into it and everything is just flowing, as he said.

I much prefer the old days. At the risk of the cliche (and I realize all the negative connotations as well), we were cowboys, but I liked it that way.

Of course, that may be what drew me to coding then. Perhaps the new culture attracts a new type of coder that likes process much more.

It is accurate in my experience.

We had "team (tech) leads" in the old days that took the place of marketing more or less — setting the general course for the software as a whole, the architecture as a whole.

But each engineer was given their own sandbox, their own piece of the framework/app to own. "Go implement an image cache."

Image cache engineer got to style their code however they pleased. They could tear it up and rewrite it when there was excessive technical debt. They knew it inside and out since they wrote it.

Often if it was code they inherited they would end up rewriting it eventually regardless — maybe piecemeal.

I don't remember every having code reviews. Sanity check? Sure, when there was some tricky bit of hacking required.

Yes, QA. Unit tests seem to make management happy these days. "I want to see 85% coverage!" as though that magically means we have less bugs.

I'm a few years younger than the author, based on when he started working, but I can relate to some of the attitudes of "the old days".

I worked at Microsoft and do remember when everyone had an office and the goal of managers was to keep you from having too many meetings. Nowadays, I also have probably 1-2 hours of recurring daily meetings. Absolutely everything needs to be tracked (daily standup, sprints, 1:1 with manager, skip-level meetings, team meetings, all hands, peer feedback), so you end up with meetings just to make sure everyone is on track. It's ridiculous.

I think it's all related to the fact that the pace of software development was just so much slower back then. I remember you could really bullshit a lot more 10-20 years ago. You could hang out with a coworker for an hour or play games with other coworkers and it was acceptable use of time. Nowadays, with daily standup, I feel guilty for wasting too much time because I'd have to give an update on where I am with work. Before, you might sync once a week, at most, so you had some breathing room. The industry was just more "fun" to be in.

Product releases were on yearly, or multi-year, schedules as well. Now everything is updated every week. I remember even ten years ago, we were releasing our software every 2 or so years, then they worked towards once a year, and then 6 month updates, and then monthly, and so on.

Nope. It isn't. I predate the author by a decade+ (first job in 1996), and he's bloviating.

Ask me about the time we had an informal meeting to decide on the premeeting strategy where we'd define the strategy for the actual meeting which would then result in a presentation to management so a decision could be made :)

It's always been a question of the culture you're in, and what they're trying to do. It still is. More collaborators => more meetings. Less ability to tolerate bugs => more formal development processes.

There's only a limited set of things where you can bang away in your dev cave for a few months and emerge with something people actually want. (It's absolutely more fun than the more formal/meeting-heavy approaches, but you're limited in scope and quality)

(With the caveat that open offices are and always have been an extremely stupid idea, and those were indeed less common)

It’s valid for his interpretation of his experiences.

Companies varied tremendously. I don’t share many of his opinions and experiences, and I’ve been coding his entire career.

I LOVE pair programming, for example, on the rare event that I can convince someone to do it. And “waterfall” did happen, but was mostly Fortune 500 and government contracts, and those of us not in that situation laughed at it. And I see benefits of test driven development, even if I write most of my tests after the fact.

The number of meetings, in my experience, was more a function of the size of the company and the team, than the era. I suspect some of the change he blames on millennials is just Microsoft getting more bureaucratic and bloated over the years.

One thing that I haven’t seen anyone commenting on is the huge shift in how software is delivered. If you take a year or two to plan for a physical release of a product, there is a lot more pressure to get things perfect the first time. If you can patch something today and go live, it’s not the same as have to send physical updates to a million customers. QA was definitely important, and, I would say, more important than today. Developers as testers is great, but by no means enough. I think testing has been shifted to users somewhat.

I do think that there was more of an understanding that uninterrupted time was very important. IBM did a lot of studies on what produced productive programmers and uninterrupted time was a huge factor. But software development has changed hugely over the years. I’ve been building a project that is similar to something I built only 15 years ago, and it’s amazing to me how much easier it is. I’m spending way more time gluing components together, with the help of stack overflow, and less time on hard problems. This may have changed what the optimal strategy is. I certainly try hard to be a good programmer in today’s environment, and not waste time complaining that things were better when we carved software into stone tablets.

So, I’m not going to say he’s wrong, but a lot of that was not my experience.

I'm from the same age group and, while I did not work in Microsoft back then, but everything he says matches my experience very closely (maybe just exaggerated a bit).

The author isn't wrong, but there's enough straw men in there that I'd recommend that you refrain from smoking while reading it. What was written was most likely true for the group the author worked in at Microsoft at the time. It most certainly is not a report on the software industry in general at that time. Some of it's true, some of it might have been true at some companies. But do note it's generalizations that don't give much to argue about; it's mostly old man shaking fist at clouds. Or cranky old anti-social asshole rants about kids today, depending on the read.

But this gem stands out:

"I would fix it, he’d verify, and we’d keep no records."

Yeah, you don't get to work on my team if you're going to sweep bugs under the rug.

First paid programming was 1981. It is all true. And easy to understand: http://www.paulgraham.com/makersschedule.html

This is all also described in the book "Peopleware: Productive Projects and Teams". Especially the importance of individual flowtime. I tried to explain this once to an agile coach and suggested he read that book. We then continued to stuff our faces with candy while he started a "flow" game mostly focusing on imaginary situations demonstrating that collaborating as much as possible increased the flow of the team.

Confirmed.