Five Laws to Break When Building Software Products

On September 19, 2019, the Governor of California signed into law Assembly Bill 5. The new California law sets more strict guidelines on how employers determine whether a worker is an employee or an independent contractor. The law goes into effect on January 1, 2020 and is targeted at marketplace and gig economy companies, specifically giants like Uber, Lyft, and Instacart. The law also impacts software development organizations as companies often use temporary or contract labor for their projects.

But this article is not about AB 5 in California. Nor is it about local, state, or federal laws. Further, this article doesn’t cover GDPR or CCPA (although I will write on those topics in the future). Most importantly, I don’t condone or endorse breaking any actual government laws.

Below, I describe five "laws of human nature" that you should be aware of when building software products... and how to break them!

1. Brooks' law

First on my list is Brooks' Law. A natural human inclination is to assume more people working on a project is better than fewer. And if a project is late, crashing the schedule by adding people is the way to go. However, Brooks' Law states that "adding resources to a late software project makes it later." The law was originally postulated by Fred Brooks in his 1975 book “The Mythical Man-Month” but Brooks' law holds true even in 2019.

Brooks' law accounts for ramping and on boarding new team members. In order to go fast, one must first go slow. If a project starts with three software developers and your company adds one or more, then at least one of those original individuals must help educate and train the new team member(s). If the goal of adding resource is to bring in a late schedule, realize it will likely extend the completion time in the near term making the project even later due to the reduction in working capacity. Further, adding resources may have diminishing returns on productivity as developing in monolithic code bases or shared code repositories increases the incidence of merge conflict, defects, and refactoring. All will contribute to further delay and potential quality issues.

The best way to break Brooks' law is to staff appropriately from the beginning of a project. Waiting until the project is late to add capacity is a recipe for disaster. To staff a project appropriately, there must be rigor around scope definition and capacity planning. Organizations should conduct project kickoff meetings with all stakeholders to identify most needs and to outline the tasks and activities the software project is expected to deliver for its end-users. With sufficient detail around requirements, the software development team can provide a starting estimation. Although, the process is not perfect as estimation can be challenging. That leads to the next law.

2. Hofstadter's law

In writing this article, I expected to be done with it by now. In a nutshell, that’s Hofstadter’s law. Douglas Hofstadter came up with the adage in 1979 to describe the challenge human’s have at predicting completion time of complex tasks.

"It always takes longer than you expect, even when you take into account Hofstadter's Law."

Building software products is a complex task. Multiple systems and modules must interact and in some cases business logic and derivative behavior is unpredictable.

Really smart people fall victim to Hofstadter’s law. In April 2011, Elon Musk famously committed to SpaceX’s Falcon Heavy test launch happening in 2013. The test launch would happen five years later in 2018. In a 2017 press conference, Musk said "It actually ended up being way harder to do Falcon Heavy than we thought. At first it sounds real easy; you just stick two first stages on as strap-on boosters. How hard can that be?"

Musk said "It actually ended up being way harder to do Falcon Heavy than we thought. At first it sounds real easy; you just stick two first stages on as strap-on boosters. How hard can that be?"

If Hofstadter’s law is self-referencing, how can one counter it? Well, Hofstadter’s depends on complexity and the human inability to predict how long a complex task will take. The best way to avoid complexity is to obfuscate it. That’s why agile software development teams are often asked to compare the complexity of two tasks against each other rather than estimate completion time. It is much easier to estimate complexity against a reference than to estimate completion time in isolation. This process is called “pointing” and is also applicable to tasks outside of software development. For example, washing your car’s exterior is likely less complex than painting your home’s exterior. You might make a good estimate of the time it takes to wash your car but will likely underestimate the time it will take to paint your house.

3. Conway's law

Next up is Conway’s law. The law originates from a computer programmer named Melvin Conway in the 1960s. Conway stated "organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." Basically Conway is saying, for better or for worse, an organization will build software that mirrors the organization itself. Is communication across departments poor? The software is likely to be of poor quality.

An organization with complex communication paradigms is prone to create complex product architecture. As product complexity increases, gridlock ensues and progress is halted. This reality is often why software development cycles increase as organization size increases. For this reason, when it comes to building software a small nimble startup can outpace a large fortune 500 company.

Interdependency creates multiple inputs and outputs increasing the chances for errors due to communication breakdown. Also, the speed by which the organization can react to the market conditions is dramatically slowed.

The best way to break Conway’s law is to keep organizations flat and teams small. Often, it is recommended that “two pizza teams” work best when building software. That means that two large (or XL if really hungry!) pizzas should feed the team working on a specific product or functionality group. Also, keep teams focused on whole features vs. individuals components to minimize hand-offs across the architecture. Eliminating or reducing dependencies will simplify the development process and the software solution’s quality will reflect the quality of team communication and alignment.

4. Parkinson's law

The next law is not specific to software and is applicable in your every day life.

Parkinson’s law (not to be confused with the horrible ailment Parkinson’s disease) states that "work expands so as to fill the time available for its completion." Published in 1955 by Cyril Parkinson, the law had roots in Parkinson’s experience in the bureaucracy of the British Civil Service.

Parkinson’s law is applicable in almost any time interval. Whether it be an hour, a day, a week, or a month, work often finds a way to extend to the fill the duration you allocate for it. The law draws on the human tendency to procrastinate. As a deadline looms, anxiety and energy builds from impending urgency of that deadline. Give a project a month when it should take a week and it more than likely finish in the month you allocated for it.

How does one break Parkinson’s law in software? One way is to apply Mark Hortsman corollary which is to assume "work will contract to fit the time we give it."

Practical methods include setting BHAGs (big hairy audacious goals) or pressing for aggressive, impossible deadlines. Over the last decade, I’ve seen plenty of "death marches" where a completion date is fixed without full consideration of scope or capacity. Although uncomfortable and sometimes brutal, if used sparingly and with some level of SWAG (scientific wild-ass guess) to set the date, the method can be successful in getting the project done. Or, at least, done sooner than if no deadline had been set at all.

Also, procrastination is not always the culprit. Sometimes the human need to "get it perfect" gets in the way of getting the work done. In software, "done" is better than "perfect" and "perfect" is the enemy of "progress." That doesn't mean to ship poor quality but rather to have a bias toward execution and completion.

5. Murphy’s law

The final law to break is another that can be applied outside of software development. Many people are familiar with it: Murphy’s law.

The origins of Murphy’s law are disputed but most agree on the definition: "anything that can go wrong will go wrong." However, I prefer the definition introduced by Matthew McConaughey's character Cooper in the film Interstellar to soften the meaning given his daughter in the movie is named Murphy: "It means that whatever can happen will happen."

In software projects, edge cases love Murphy’s law. A catastrophic defect that should be rare will suddenly find its way to the top of your bug reports. End-users will find the button sequences that crashes their user interface. Traffic will spike when you least expect it to. And all the stars will align to bring down your demo when you have the most important meeting of the day, or worse, an auditorium of people watching your presentation.

Even with its negative connotation, Murphy’s law is great motivation for risk management. It forces an organization to think broadly about all possible events and their outcomes. From that potential events list, it is easy to forecast the consequences of those outcomes and how it will impact the organization. A bit more effort is required to analyze probabilities and likelihoods but with Murphy’s law you’ll know probability is never zero so you can't exclude even the most unlikely events from your list. Risk ultimately is just the product of probability and consequence.

The best way to break Murphy’s law is preparation. In the medical field they say, "an ounce of prevention is worth a pound of cure" and in software development taking the time to be thoughtful, intentional, and adequately prepared is critical. A risk management loop should be embedded in your project phases and part of the team’s dialog when planning and discussing work.

Mindera uses the following framework in its agile software development projects which has enabled its teams to deliver resiliency and high-availability in demanding, high traffic software platforms.

Break these laws and your project will have a better chance of success... and nobody goes to jail!

Have you experienced any of these laws in your business? How did you break them?

Thank you for reading. If you enjoyed this article, please like or comment. I want to hear from you!

If we’re not connected, hit the +Follow button below. On LinkedIn, I share thoughts on fintech, identity verification, artificial intelligence, biometrics, blockchain, the future of work, agile software development, high-performance teams, build culture, and more.