They Write the Right Stuff (1996)

In it you'll find that this level of requirements gathering, blueprint/spec writing and code inspection are actually cheaper in a relatively short time (months, not years).

Writing specifications that are extremely detailed ends up giving you all the logical failures ahead of time, and makes typing code more of a spell checking exercise. By having the logical failures before the code ever runs, you get to debug & fix them before any code runs. This ends up being faster & cheaper in total than waiting for users to find bugs.

However - I understand that for many companies they actually don't care if users find bugs as time to market is more expensive than the future bug finding. But if you have a product already in the market, and you expect to support it for ~year, you probably can do much more detailed design and avoid so much pain.

I remember there were some comments: > Are you prepared to pay 10x for a text editor, say? My answer: Hell yeah, if I am earning thousands using this editor, why not pay couple hundred bucks for a really well-made program with good support, etc.

But as I understand, there exists no demand for this type of thing among general users. People are ready to pay for tons of useless features being added (just to signal that the project is progressing) but not ready to pay for simpler solutions that are really focused on quality, security and consistent performance.

I am not sure where we are now, was OOP the dark middle age or the industrial revolution? Or will that AI be?

Would be really interested in your opinions!

Namely, we're at a point where agile practices have become so common that nothing is ever 'done' and it is acceptable to ship something with errors, assuming it can and will be patched later.

Both Mom & Dad started out as COBOL programmers on punchcards, and I've heard plenty of 'war stories' about how these kinds of situations were far less common because an error meant your program simply didn't run.

Unlike say a web browser which will mostly spit back out whatever weird HTML and CSS you feed into it, errors and all.

In consumer software, it's not, 'we follow orders or people die' but for people working on this, it probably feels that way if your stuff is used by enough people (iOS) or is critically important (medical billing).

If it doesn't do what it says on the tin, people are incredibly unforgiving of even the smallest mistakes.

- Unless you were a larger firm or project, version control was something you never even heard of

- A lot of the internet was still being put together

- Perl was a big deal and a LOT of it was bad e.g. "use strict" was almost never used so you could use variables willy nilly

- The Joel Test was yet to be written (5 years out roughly) and people were scoring low on the test then

- The only exposure to Linux was generally when you were in college unless you were hardcore. Otherwise, everything was windows. E.g. I remember installing Slackware from a CD that came with a giant book and then thinking: "What do I do now?"

- Java was the new hotness and Rutgers (my school) was the first major university to offer it for there 101 (actually RU CS first class was 111 b/c 101 was "business computing").

- There was no Google, Stack Overflow etc. You were lucky if people like Jeremy Zawodny happened to write a blog post about the weird Perl + MySql bug you were running into and/or if your local book store had Databases for Dummies

It really is amazing to me now to see how MASSIVE frameworks for JavaScript come out every year and the whole ecosystem spasms. Perl CGI was the de facto way to write web stuff for almost a decade. In fact LAMP used to mean "Linux Apache Mysql Perl" until php came along and even then giant website were still written in Perl e.g. Amazon, IMDB etc