5 funny Laws and Quotes that Apply to Software Project Management

On the difficulties of estimating and keeping the project within the proposed time frame, the following “programming pearl” was published in 1985 and belongs to Tom Cargill of Bell Labs: “The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.“ Hopefully, your estimate will not be off by 80%, but this is a quote you should always remember when estimating projects.

On the same page with the first quote, a self-referential one, coming from the book Gödel, Escher, Bach: An Eternal Golden Braid (isn’t that an impressive title for a book?) by Douglas Hofstadter, here it is the Hofstadter’s Law: “It always takes longer than you expect, even when you take into account Hofstadter’s Law.” Why people tend to think that it will take less to complete a project than it actually does? Probably because of the optimism bias – a cognitive bias that causes a person to believe that they are less at risk of experiencing a negative event compared to others.

For projects that are late, it would seem a good idea is to add more people to the project. Well, it’s not. In “The Mythical Man-Month”, Fred Brooks states the Brook’s Law: “Adding manpower to a late software project makes it later.” Derived from his first hand experiences while working at IBM, Brooks became so dissatisfied with people repeating his mistakes over and over again that he said his book is like the “The Bible of Software Engineering” because “everybody quotes it, some people read it, and a few people go by it”. Wait, what, was I just doing that?!

C.N. Parkinson, a British historian but who touched also public administration and management subjects in his books, came up with a few laws, including the one bearing his name, Parkinson’s Law: “Work expands to fill the time available.” So be careful with lax deadlines and estimates, because most times it will not translate into work being ready ahead of the deadline, as you would expect, but it will be actually contra-productive.

The Stock–Sanford corollary to Parkinson’s law states that: “If you wait until the last minute, it only takes a minute to do.” So go ahead and cut those deadlines (at least your personal ones), not to a minute, but maybe in half as recommended in this Lifehack article.

And I will end with the last law for today, Golub’s Second Law of Computerdom, a law that states why carefully planning a project is important: “A carelessly planned project takes three times longer to complete than expected; a carefully planned project takes only twice as long.”

What time is it?

It’s time for a little discussion about time! Well, actually about time and materials because when it comes to project pricing in software development, there are two main approaches: Fixed price and Time and Materials.

If we go over to Wikipedia , we will find out that “a fixed-price contract is a type of contract where the payment amount does not depend on resources used or time expended” and it is similar to many of our dealings in the day to day life when we buy something – it is clear what we want, it is clear what we are buying and the price is also known upfront.

This approach works well for consecutive projects that are very similar to each other, are clearly defined by the customer and the supplier did the same kind of project over and over again. That means fixed prices contracts are suitable for, let’s say, installing a pool in your backyard – the scope of the project and the customer’s expectations are clear, hopefully the supplier did the same kind of work several times before, so the supplier knows how long it will take and how much it will cost to fulfill the order.

That also means that fixed price does not work that well in software development. Why? Because software development can be unpredictable. Most of the times, you know the deliverables (although these can change and sometimes it can be beneficial for the customer to be changed from a business point of view) but the path to those deliverables is not a clear path and software development is more of a exploratory work than a clear–cut one.

In a Time and Materials contract (thanks once again to Wikipedia ) “the employer agrees to pay the contractor based upon the time spent by the contractor’s employees and subcontractors employees to perform the work, and for materials used in the construction (plus the contractor’s mark up), no matter how much work is required to complete construction.”

This does not mean that estimates should not be given and it also does not mean that the development company can just keep on billing endlessly without delivering a product. That is why it is a good idea to combine this approach with Agile practices because after each iteration working software can be delivered to the customer.

The relationship will be a flexible one: if the customer will want to change the scope or add new features, the contractor will be happy to oblige. In a fixed price contract scope creep (the customer adding requirements along the way) is one of the concerns for the development company and can lead to a tensed relationship between customer and developer.

Both approaches have their strengths and weaknesses – the fixed price contracts may look more appealing to the customer, because it seems that the risk and the budget is known upfront, but the customer must not forget that in order to have a fixed price contract work out fine, the customer should invest time even before starting the project in order to exhaustively define requirements and expectations. Also, sometimes correctly estimating a large software project is something nearly impossible and you can have a look at some of the big failed projects here .

The bottom line is this: in software development, the vast majority of projects cannot be clearly defined to the smallest detail upfront and that means a fixed price contract will be nothing more than a coin flip when it takes to taking the risks and the potential losses – both the customer and the developer will hope they get lucky and that just does not sound to me like good business practices.