Good old days
Is software development different today, compared to the good old days?
Today, you often have three main scenarios when starting major programs.
Build on what you have
Buy something new, COTS and/or SaaS
Build something new from scratch
Build on what you usually works well, until there are major changes to your business model, or the technical debt becomes too huge.
For many years, I've seen option two and option three fail miserably. We have our own share of them in Sweden, most recent one being Millienum health care system that was cancelled by two different regions.
But I've also seen a number of programs developing subscription billing systems going down the drain. The question is why, because they were running agile, not waterfall development style.
Back to late 80's when I got the task to implement a material production system at a manufacturing site, replacing paper. No existing IT-systems, no COTS and cloud computing was somebody’s else mainframe.
The first thing I had to do was to collect a hard hat and safety shoes, so I could go out in the factory and see what really happened in real life. As a manger, I both did a budget and motivate the investment, as well as installing the minicomputers running VAX/VMS and plan a local fibre network.
The requirement work we did was very process oriented, starting with identifying how the people worked at every station in the factories. Then designing a SQL-database and UX for terminals to support the workflow. Used consultants to write most of the code, but we wrote interface code for API communication in C and embedded SQL. It even worked in year 2000, avoiding the millennium bug.
Fast forward until today.
A fair share of the software developers I met recent years have no clue about the business and how things are done. They often don't care about budgets or the cost of development and maintenance. They are highly specialized on a few tools and frameworks, and often competent in their area.
But the problems with major programs starts, but not ends, with requirements.
Lack of requirements, or incomplete requirements. If you starting a new digital business from scratch, and doesn't need to be profitable the first ten years, the your can run agile. If you have an existing business, and try to replace you legacy systems, the skateboard to car analogy doesn't work. Period.
Garbage in - garbage out is next. Information models more or less non-existent in today’s agile world. Very few software developers have the skill or the mandate to a proper information model. The consequences are delays, building up technical debt and lack of data quality.
Today's computers are fast, and this also makes non-functional requirements a forgotten topic. Lack of those will result in bad data quality, technical debt and problems with compliance to regulations.
Finally a word about stakeholder commitments. There are often to many layers between the guy or girl who present the budget to the guy who writes code, or the person who will use the system. Neither is anybody accountable for the whole.
Back in the good old days, we could have the whole team around a large table in the lunchroom, sipping coffee and smoking cigarettes, and I was accountable.