4 ms·
This is an awful article that does not articulate the vast majority of past software development. I'm largely of the same era as the author, becoming a paid sof
by gilbetron 5y ago
This is an awful article that does not articulate the vast majority of past software development. I'm largely of the same era as the author, becoming a paid software developer (as a teenager) in 1986. The vast majority of software development was bloated and slow and largely horrible. The waterfall method ruled the world, and projects struggled to complete even though they weren't anywhere near the complexity of today's projects.
Responding to some of the points from the article:
* Insulating developers from interruptions was management’s Prime Directive.
Not even remotely, that concept didn't exist until the 2000s. The managers job was to micromanage those under them and people had to create ridiculous estimates and then put in crunch time to try to meet them. Management processes were based on managing manual labor. It was, in all ways, a horrible era.
* Projects were planned and designed. We had documents we were expected to read.
Sure, there were all kinds of docs that were incorrect, poorly thought out, and just plain wrong.
* Code is illegible.
The "golden days" were not golden. Code is far more legible now. "it was hard to write, it should be hard to read" was the predominant mantra of the 90s. Code these days is generally reasonably legible and clean.
The only aspects about the article that do ring true are some of the comments about testing - we did do testing and QA is great at least for complex domains.
This article is about 90% old man yells at cloud, and this coming from an old man ;)
- commandlinefan 5y ago> I'm largely of the same era as the author Well, were you also from Microsoft? He seems to be talking about the way Microsoft did things "back in the day" - and it's hard to argue that they weren't very successful at it back then.
- thinkharderdev 5y agoVery successful at producing and selling software for sure. I wouldn't really hold up mid-to-lat 90s MS products as the pinnacle of reliable, well-designed software though.
- postalrat 5y agoYou can't compare crud web apps with a large operating system that was on the cutting edge for the day.
- gilbetron 5y agoI had considered that, but the article isn't "Microsoft then and now", but tries to make a comparison of the entirety of the software industry then and now. Microsoft may have done things better (I've heard differing stories), but industry-wide software development doesn't resemble his description.
- rbanffy 5y ago> This article is about 90% old man yells at cloud, and this coming from an old man ;) Indeed. Same here. I couldn't take the writer seriously. A lot of what he says is the result of the limitations of our computers, networks and software in the 80's and 90's. Of course I wrote Apple II code with manuals - we didn't have online docs back then - even in the mid-90's, I had MSDN installed on my computer for helping me write Windows software. I am not a better developer because I used books - I am an older developer because I started back when I had to use books (and manpages were optional and often not installed and it was nowhere near a given Unix would win the "OS wars"). The thing that turned the article from amusing to embarrassing was the tirade against writing tests and TDD overall. Writing tests makes me a better programmer. By starting to write tests as part of my design, my components get better - better usable and better testable and my software gets more reliable and better documented (because tests are documentation too). I'll not say I'm an old man (53 is not that old) and while I can be bothered by some things I consider excessive framework churn (looking at you, JavaScript), I wouldn't say we are not a whole lot better off than we were then.
- username90 5y ago> Writing tests makes me a better programmer Writing bug free software without writing tests also makes you a better programmer. Practice helps, and practicing creating architectures that are easy to make correct without tests really makes you a better programmer. If you can't both do well with tests everywhere and do well without tests then you aren't a great software engineer. The reason is that first you create an architecture that is easy to make correct, then you add tests on top of that, and now you got something great, using tests as a crutch prevents you from ever reaching that stage.
- mixmastamyk 5y ago> Not even remotely, that concept didn't exist until the 2000s. Peopleware came out in 1987, and was read extensively at Microsoft in the 90s. You may be thinking of when Joel helped popularize it.
- EVa5I7bHFq9mnYK 5y agoAs to "anywhere near close the complexity of todays projects", please keep in mind that all the os kernels, major programming languages and algorithms you use today have been written decades ago. Nothing majorly new has been created since ~2000.