Laws of Software Development
In speaking with people about the complexity of software development, one comparison I’ve often used to describe it is to relate software development to physical engineering. Engineering can rely on physical constants that can be expressed as formulas or constant numbers. For example, the tensile strength of AISI 1018 mild/low carbon steel is 53,700 psi. Standard gravity is defined as 9.80665 m/s2. Engineers can rely on numbers such as these to design and build objects.
In software development, complexity arises because there are very few (arguably zero) constants that we can rely on. At any given point, something can fail or not preform to specification. Life would be far easier for software developers if we could rely on a network connection always operating at a certain speed, or a CPU operating at a certain capacity, or a database never failing, or a file system never becoming full…the list goes on of the failures that could occur. But we cannot rely on these failures not occurring and we must build in the ability to handle these failures, and this drives up complexity. Not having a defined set of laws to operate by makes it all the more challenging.
Interestingly, we find that the reverse is often true with the softer side of software development. Over the last few decades, numerous rules, laws, and heuristics have emerged from software project management that describe the nature of software development. I thought it would be fun to highlight a few of them – let me know your experiences in the comments!
Eagleson’s Law
Any code of your own that you haven't looked at for six or more months might as well have been written by someone else.
Brook’s law
Adding people to a late software project makes it later.
Galorath’s 7th law
Projects that get behind, stay behind.
Conway’s Law
"organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."
Hofstadter's Law
"It always takes longer than you expect, even when you take into account Hofstadter's Law."
Senior Software Engineering Lead at ICF
6 年Eagleson’s Law Any code of your own that you haven't looked at for six or more months might as well have been written by someone else. I learned this lesson while working at Time-Life where I took on another project for several months and on my return wondered (to put it mildly) who had mangled my code. A look at the code history revealed that nobody did, it was all me. Lesson learned. Flash forward to my return to AAP and looking at a project that I hadn't touched in eight months (and hadn't thought I'd see again). The code was organized better, commented, clean and even had a confluence page of notes for API calls and architecture. Lesson validated.
Sviluppatore frontend freelance.
6 年It's really interesting!
Streamlining business workflows with a drive for excellence.
6 年Isn't it great how a process that is supposed to be deterministic is actually driven by coincidence since most of the time there aren't even investments into at least having knowledge over potential failure points?
Senior Consultant, Avaap
6 年“The bug that can’t possibly exist because you didn’t change anything exists because you just can’t REMEMBER changing something. You totally did.”