In the introduction of Alan M. Davis’ 201 Principles of Software Development, the author wrote:
If we were to examine the set of software engineering principles from 1964 they would look downright silly today (for example, always use short variable names, or do whatever it takes to make your program smaller). Today’s principles will look equally silly in thirty years.
Alan M. Davis, 201 Principles of Software Development, page 5.
That book was published in 1995, so it now has been thirty years. Quite a lot has happened since.
Software has become larger, longer-lived and ubiquitous in a way that it simple was not back then. Consider the emergence and massive growth of the Internet, web and mobile applications, cloud computing, IoT, machine learning, and so forth.
The book predates the publication of the agile manifesto by several years. In the decades since, development teams have experimented with or adopted many new methods and frameworks.
In recent years, artificial intelligence has been becoming increasingly important throughout the software development life cycle itself. We are just at the beginning of that.
Suspecting a review to reveal silliness in past assumptions is a reasonable take for a curious mind, who acknowledges the symptoms of a young and evolving discipline and profession.
In the 2024 IEEE Software article, Software Principles, Christof Ebert and Alan Davis do revisit the topic and present findings of a survey where they asked experts in “the Americas, Europe, and Asia” with a background in “software engineering, spanning teaching, research, practice, and managing companies” about their perceptions of the presented 201 principles.
Per that article, the following list of ten principles emerged as those that received the most votes from respondents as still being applicable.
- Build in small increments. Incremental development helps control risk related to complexity and supports shorter feedback cycles.
- Take responsibility. Taking ownership, taking the development of a software solution for a real-world problem seriously, is an important ingredient to delivering quality work.
- Listen to your customer. To ensure your software solution is a great fit for a customer’s problem, you have to ensure you understand the problem well. For that reason alone, there is tremendous value in reducing distance between developer and customer.
- Inspect code. This includes manual and automated analyses. This is about discovering problems, but also of course learning and knowledge exchange.
- People are the key to success. Software engineering is a team sport, an inherently social activity. Excellent, skilled people who take ownership of a project can probably take it far, even if they have only poor technology support. Great, modern tools won’t likewise compensate for poorly trained people.
- Keep track of every change. Due to the intangibility of software it is so easily changeable, so changes (including problematic ones) can happen quickly and often. Keeping track is an important part of managing the associated complexity.
- Prioritize requirements. Some things matter more than others. Of course there are also things that do not add value at all. The order of things can make a difference.
- Give products to customers early. Related to incremental work and listening to customers, this helps build empathy with the customer and get feedback (and the chance to learn) sooner.
- Design for change. Software that is in active use, is usually also continuing to evolve and subject to change. Its design should accommodate that reality.
- Trust your people. This is a profession and discipline of knowledge work, where teams are often distributed or use hybrid or partially remote setups. Either way, the work requires dealing with and managing complexity. Learning and creativity matter – and productivity is famously difficult to quantify. Trust is important.
There were other principles that were no longer considered relevant and the article also presented new additions.
Of course, all this is based on the views of those people who participated. The results do reflect the fact that the profession and our collective understanding do continue to evolve.
The Lindy Effect serves as a useful model, as you form opinions about the future here. Those principles that have survived three decades or longer in a changing environment, will probably continue to prove trustworthy.
Thirty years later, 201 Principles of Software Development would of course not be written the way it was. You also do not read and understand it the way you would have then. It is still an excellent resource and it does invite (re-)reading and reward reflection.
Software engineering is still young and it continues to evolve.