5 Tips to ensure dependable estimates

One day, a young boy looked up at a nearby mountain. It’s towering presence amused and inspired him. On this day, he decided that he was going to climb the mountain and see what lies at the top. So he took his biggest bag, filled it with food and water and started the trek.

Two days later, his supplies were over and he had to walk back home hungry and disillusioned.

Apart from being a very poorly crafted storyline, the story above highlights dangers of not estimating and thus not planning.

A good number of software projects started out just like the adventure shared above, with a lot of enthusiasm and little respect to the available resources.

On this entry, we will be discussing the various tips and tricks you can use to ensure that you have reasonable estimates for your project.

Understand the work

As I always say, you can not develop concepts, you can only work on tasks. Before starting on any project, actually any task that will take more than a few hours, first decompose it and then estimate it.

This simple but useful habit will ensure that you have visibility on the work that you must do. It also acts as a buffer against underestimation by bringing to the fore items that would have otherwise disappeared in the collective.

Never give off the cuff estimates

I can’t tell you how many times the client has given a one sentence requirement such as “We want an event management platform” and then followed that up with a request for an estimate. Of course the estimate is needed immediately.

It is tempting to spit out the first value that comes to your mind. As much as possible fight this impulse.

Most people who hear your estimate will take it as a commitment and thus you end up in an awkward situation when it doesn’t pan out. In case you are wondering, it never turns out the way you expected.

Let the developers estimate it

Wouldn’t it be awesome if you could have a dedicated team of estimators who would tell you how long and how much each potential project would cost? Well give up on this dream, it will never happen.

The people best suited to give an estimate for the work are the people doing the work, period.

Have you ever noticed how everyone else work is easy? By letting other people work on the estimate for the developers, you are very likely to end up with gross underestimation.

Even more importantly, discussions on estimates surface issues that would have otherwise remain hidden. Eg if for developing a feature, developer A says it will take 10days and developer B says it will take 1 day. Then this presents an opportune moment to iron out the differences in understanding on what is actually required of the feature.

Estimate the mundane and obvious

While touring a new city, you are likely to see much more than the natives. This arises from the fact that the locals are so used to the environment they stopped seeing it. In the same way when estimating projects, it is at times possible to forget and omit important activities that never the less take time.

Some common activities prone to be forgotten include:

  • Server/Environment setup
  • Meetings and Demos
  • Public holidays
  • Leave days
  • External tasks that the developers must do

Refine and course correct

Your estimates will always be work in progress. Just as the project evolves to better meet client expectations, your estimates must also evolve to reflect your current understanding of the project.

If at any moment you realize that your original estimate was wrong, bring it up as soon as possible and have the plans adjusted. It may be painful and awkward but that will not compare to missing a deadline.

How do you ensure you have dependable estimates? Talk to me in the comment section below or on my twitter @jchex


Yes you should version your database

There is one major process that your team is likely ignoring that holds a large stake in your application, can you guess what it is?

Did I hear someone say Database migration woop woop top of the class!

More often than not, we properly version code but deploy the database as one big sql dump. Practically all teams I have interacted with during deployment present a .sql file with instructions that Mysqldump or a similar tool should be put to employ.

The biggest disadvantage to this method is that the database and the application don’t remain in sync for the various versions available. At first glance this may not seem like that much of an issue since most of the time we are only concerned about the final version of the db. However when you think about it you realize that if the version of db you have is only the latest, then earlier versions of the code are practically unusable since they work with the implicit assumption of how the schema of the database is structured.

Application <-> Database mismatch maybe your biggest problem but other problems quickly become apparent when you deploy and need to scale your app. Since the entire db is just one big dump, you can not easily automate the task of scaling it over the cloud.

Well now that we have talked of the evils of the dump, what can we do?

The easiest option is to store diffs of the database. Here I don’t mean in the sense that git does but rather storing ALTER scripts in an orderly incremental manner in a folder called migrations. Sample contents would be:

  • 001_Users.sql
  • 002_Products.sql

And when say we alter the users table then:

  • 001_Users.sql
  • 002_Products.sql
  • 003_Altered_users.sql


We then commit the files to our code repository of choice.

This ensures that at whatever point you checkout your code, you can also be able to generate the necessary schema.

Other considerations

For those who work with frameworks, your framework probably ships with a schema builder in one form or another. For those cases you may wish to version the schema files rather that the sql file.

For those of us who prefer the db to be framework agnostic, the following tools can be a great help to help you run your diffs

How do you manage database migrations within your own team? Tell us in the comment section below.


Why modifying vendor code is a bad idea


Writing software for production is one of the toughest endeavors a person can take. The fact of the matter is that more than often we are tempted to simply look up an existing solution and modify its source for our own needs.

At the surface of it this seems quite desirable, maybe even a good practice, in reality going down that path is likely to take you into a world of horrors. Here is why.

Writing reusable code is hard

To fully understand this concept we must take into account the rule of three. This rule states that:

  1. It is three times as hard to build reusable components as single use components
  2. Reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library.

Now of cause this are not hard rules but they provide an easy to recall rule of thumb and its lessons are intuitively clear.

A truly general solution solves not only the general problem but also the specific solution of which it was intended to solve, as such tests for it must be written to this specification.

With this knowledge in mind how much are you willing to bet the solution you wish to modify was written as a general reusable solution?

Specific solutions exclude other solutions

With the idea that the solution your are about to modify was probably written to solve a specific solution, we must now think of the impact the design decisions made by its maintainers has on its ability to solve other problems.

As it turns out there isn’t a best design solution for a problem but rather each designer would probably land on their own unique and correct design for solving the problem at hand. This would mean to modify the existing design would need you not only to understand the problem but the philosophy on which the design solution was chosen.

In iterative methodologies (Agile, XP etc) this is especially a problem since simple designs are encouraged and over time they evolve to meet the complex needs of the final solution. The evolution process is probably not documented and maybe hard to know of its existence let alone comprehending it.

Understanding the solution

Given that we now have a specific solution it may be particularly hard to understand it without knowing the specific problem it was intended to solve. To the designers of the solution, the problem is probably painfully obvious, however to you the outsider, this is very rarely the case.

Furthermore you may find that as time went by even the original designers forgot how the solution actually works! If this phenomena sounds strange, try looking at code you wrote a couple of months ago.


Or in our case, lack of it. While the virtues of proper documentation are preached at every corner of the software boulevard, its adherents are scarcely anywhere to be found!

If you know nothing else about the project, you can still gamble on inadequate documentation, this exacerbates all the problem mentioned above.

Even more interesting, you, the modifier of the code are not likely to document your changes either further complicating things down the road.

Later releases

Unless the project you are thinking of modifying is a dead project. The maintainers are probably fixing old bugs and adding new features all the time.

It goes without saying that this changes are likely incompatible with your own version so you may need to redo the work all over again whenever a new release comes out.

So what to do?

Reusing and modifying large components will be a problem in the foreseeable future. However some actions you can take to at least gain some benefit out of existing software include:

  • Reuse only software meant for reuse. An example of this would be packages and libraries
  • Do not modify the code, instead write an adapter to interface the package and your code
  • If you need to change more than 20% of the code, rewriting it is likely to be cheaper
  • Use a dependency manager
  • Always write integration tests and run them every time a vendor does a release
  • Whenever possible, use packages with developers of some repute

Do you have any advice on reusing code? Talk to us on the comment section below