We’re constantly asked by our customers how long it will take to build their software. And it’s a good question. When you ask a software developer “How long will it take to build this this?” don’t be surprised if their answer is “We’re not sure we can estimate the effort.” The truth is estimating software engineering projects is tough. Even if we have a defined list of detailed requirements, we often need to dig deeper to provide an accurate estimate.

What makes software development projects so hard to estimate? Requirements alone are not enough. In order to provide a firm estimate, we first need have a deep understanding of the design requirements, so we can create a framework for the project.

Would you build a house without a design?

How is this different from other services? When you think about it, estimating based on design frameworks is not unique to the tech industry. Imagine you approached a builder to construct a new house – the four bedroom, sunny home you’ve always dreamed of. Any builder would need to plan and design your home before they’d even attempt to provide you with an estimate. They’d also probably want to consult with you on materials first too.

The same applies to Software engineering. Before we can provide an estimate, we need to first understand your design requirements and create a framework for your design.

Taking (some) time at the start will get you closer to the outcome you’re looking for

At ClearPoint we’ve adopted a JEDI approach which stands for “Just Enough Design Initially” to creating design frameworks for software projects. Essentially this means we dig beneath the surface to form a high level view of what business outcomes you’re looking for and pinpoint exactly what we’re going to build to deliver the best solutions.

When framing a design we make some decisions upfront, like selecting the architecture, the language and deciding if we want to make use of 3rd party systems like a CRM. We also choose which frontend technology is best to use, which databases we need and work out how we’re going to deliver. Understanding all of this information is vital for providing a good estimate.

Fail to plan…

Not taking the time to develop a strong design framework before you provide an estimate for a software engineering project is a risky strategy. Developers who take a set of design requirements and start writing code without a design framework, would be like your builder starting your house without a plan – you may still end up with a house and the quality finishes you were after – however there’s a high possibility your bathroom will be next to the kitchen, you have carpet in the laundry and your dream house will fall short of your expectations.

Agile software development encourages ”targeted design” – not “no design”

So what role does Agile software development play when it comes to design frameworks? In my experience agile methodologies are often used as an excuse to push forward with a dev project with “no design” or “documentation.” This is interesting given best practice agile approaches like Feature driven development (FDD) place more emphasis on targeted design. In essence it encourages design which is delivered in a fast and effective way so as not to slow a project down i.e. a photograph of a whiteboard brainstorm, or a quick diagram on a collaboration page with some comments, rather than a 100 page document that has been reviewed by 10 people and is out of date before it even makes it to the dev team!

FDD agile methodology encourages us to treat design as a high priority throughout the whole development process. While it encourages us to do it differently, it does not suggest we skip the crucial process of creating a design framework.

The FDD agile methodology emphasizes design as a high priority output throughout the whole development process. While it encourages us to do it efficiently, it does not suggest we skip the crucial process of creating and maintaining the design.

The more detail we have in the design, the more accurate the estimate

It’s simply not possible to estimate off requirements alone with any degree of confidence. To create a good estimate, the team need to review the requirements, understand the business and then work on a design.

The only exception to this approach should be if what is being requested is something that’s been built 100 times before and all that’s needed is exactly the same thing in quantity, different colour, size or shape. However most software engineering projects exist solely because what is needed by the business and hasn’t been built before.

And when you need to create a point of difference for your business by building something new, try our JEDI moves and do just enough design initially. Get a firm estimate, then continue to refine the design as you go. You’re more likely to get the right outcome.

Nick Langstone is a Software Delivery Manager at ClearPoint who’s passionate about solving business problems using the best technology. If you’d like to talk about any of these topics, flick Nick a message via LinkedIn https://www.linkedin.com/in/nicklangstone/ or give us a call on +64 9 373 4626.