These Famous Laws of Software Development Remain True

We love to think that everything we do in tech is groundbreaking and new. But actually, a lot of lessons were learned in the 1970s and you can save yourself a lot of time and effort by realising that these rules are rules for a reason. Enjoy.

The Ninety-ninety rule

The first 90% of the code takes 90% of the time. The remaining 10% takes the other 90% of the time.

Anyone that has been involved in a software project can relate to this. I am convinced that it is fundamentally impossible to accurately predict a software task because a) Getting it 'to work' is only half of the task - all the finessing comes next and b) tasks are often poorly briefed or the client changes their mind partway through. That's why I always suggest 2x or 3xing the estimates you receive and you might get them right.

Hofstadter's Law

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

Similar to 90/90, this one is a 'recursive' law for all the Computer Science nerds out there. The reality is that it always takes longer than you think. To be honest - this is true for anything as much as it is for software projects.

Wirth's law

Software gets slower faster than hardware gets faster.

What is that quad-core 2.3Ghz i7 doing all day? Remember we made it to the moon with a computer a million times less powerful.

We have more computing power than ever but the web is getting slower... not faster... let's think about how to be careful with how we approach the engineering of the web. Do you really need that library? That 3rd party app? Can it be done simpler?

Murphy's Law

If something can go wrong, it will.

I'm sure you all know this one. Again, it applies not just to software but life itself.

In software, we protect against it by backing up, using version control, protecting the downsides of catastrophe, including fallbacks.

Brook's Law

Adding people to a late software project makes it later.

The first reaction to a late running project is to add more people it - but don't do it. It's not worked since 1975 when this law was included in Fred Brooks' 1975 book The Mythical Man-Month. It's better to de-scope late-running projects and replace people if necessary.

Conway’s Law

Any piece of software reflects the organizational structure that produced it.

The harder you think about this one... the truer this one gets. Think about how we divide up front and back end development. Native apps vs websites. Or how many websites structure the site to mirror their own departments.

(Side note but company wikis also have a nasty habit of doing this)

I don't think it's always a bad thing but beware that better structures might exist. And cut down on department silos. At We Make Websites we do this using Pods, cross-functional teams that include everyone needed to make the website a reality: all developers, designers, product owners and scrum masters. Those team members also belong to functional teams, but their day-to-day is spent with the right mixture of folks required to make the client's dream a reality. That's what pays the bills.