How object-oriented design helps create better estimates

You (probably) don’t need to test that »

I have a long-standing client who has a complex piece of software that I developed for them some time ago. From time to time they approach me and ask me to make improvements to the software, which I am almost always happy to perform. And like any good client they want an understanding of the cost before they move forward, largely to ensure that the cost-benefit analysis makes sense. And so, they ask for an estimate.

I’ve written on estimates in the past. I don’t like them, largely because they can tend to box you into a particular position that may or may not be correct.

But for this client, I always give them an estimate. And I always deliver early.

Why?

The answer is simple. It’s not because I’m super-human or an amazingly good estimator. In fact, I’m not that great at estimation at all. It’s because the software that I’m working on is well designed.

I’m not saying that just because I wrote it. In fact, if you asked me with a gun to my head right now exactly where in the stack the database connection is made, or to describe from memory the way that RabbitMQ is set up, I’d end up shot. I just don’t have a memory for these kinds of things anymore.

And this is where great design comes into play. By designing the software well, I can pick it up, and almost instantly know exactly where everything is. The design makes the software easy to maintain.

This is the key to delivering early on my estimates.

More design time means less maintenance time

The more time you spend designing your software, the less time you’ll spend maintaining it. While this seems to make sense, it’s crazy how many developers simply don’t do this.

How do you go about designing software that’s easy to maintain? I use three steps.

First, testing must be paramount in your design. Anything that’s hard to test will be hard to understand later. Period. This doesn’t mean that you can’t devise some complex apps or have complex tests. But if it’s impossible to test it will be impossible to maintain later on. So learn to practice test-driven development or at least plan out your tests in some way.

Second, discrete code is easily understood code. Yes, this can result in more objects in your code, because you focus on readability. Code is for humans to understand. Martin Fowler says as much, writing “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” You have an obligation to the person who comes after you (even if it is you) to make your code readable and easy to understand.

Finally, leave yourself notes. I don’t mean of the comment kind (though you can if you feel it’s necessary). You can do this by how you name things. There’s an old programmers joke about there being three hard things in programming: naming things and off by one errors. But it’s true: naming something is one of the hardest things you’ll ever do in computer science.

Do it anyway. Good names for things will tell you exactly why a method or property exists. MyObject::connectToDatabase() is far more explicit than MyObject::connect() [connect to what?]. Code is readable and your “notes” are easily understood when you have an idea of what the outcome is (but not the way it’s generated) through reading the method name.

It can feel scary to use lots of objects, and we sometimes are afraid of “over-engineering” a system. But good design isn’t over-engineering. And using plenty of objects is okay – as long as they each have a purpose.

Once you have mastered the art of designing your code well, estimates become a breeze. Adding a new function, feature or method is simple, because you can easily understand what the code is doing, identify where you need to make changes, and have tests to verify the modifications. It’s how I work each and every day.

Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP