Over the last few posts, I’ve been sharing some thoughts on why good development takes time. Of course, these are only limited to my own set of experiences, but I do think many of these are shared among developers.

In the first post, I said that we all fall into the category of a producer or a consumer, at some point, and we often want what we want sooner rather than later.

In the second post, I shared two reasons why I think good development takes time:

  1. The Are Moving Parts
  2. Problems Within Problems

And in this post, I wanted to share the last three reasons for why that I think good development takes time.

More On Why Good Development Takes Time

As I mentioned in the last post, part of why good development takes time is because we’re creating something from nothing more than a a set of abstractions.

That’s a really cool concept, but it comes with its own set of challenges especially if you’re working to create something of high quality. So in addition to the various moving parts, and the unforeseen problems, there are still three other things that I believe contribute to the timeline of development projects.

3. How Much is Too Much?

One of the most common terms that developers hear is scope creep. In short, most people have this grand idea for what it is they want – there are a lot of must-have features, and there are a lot of nice-to-have features.

The challenge comes when we’re trying to differentiate between the core set of features – the must-haves – and luxury items which are the nice-to-haves.

The thing is, developers will usually identify nice-to-haves in one way whereas the client will identify the nice-to-haves in other way. As it relates to identifying what features are necessary and which are not, his post isn’t to say the developer is always right – because we definitely aren’t – nor is the customer always right – because they aren’t, either.

But it’s about collaboration between the two parties to identify what is and what isn’t going to contribute to the foundation of the application.

Missing a Few Key Features

Missing a Few Key Features

I’m of the mindset that if you get the foundation right, the core problem is solved and you have a solid base off of which to further build out an application. It’s not always easy to achieve, but I think there’s something to be said for not going too far for the first version.

After all, you do want to leave room to iterate.

4. Edge Cases

Perhaps the aspect of good development that takes the longest is evaluating edge cases.

Not only do I think testing the edge cases takes a significant amount of time, but identifying what those edge cases may be takes time in and of itself.

The truth is, whenever I’m contracted to work on a project, I’m more than happy to go through the testing process with the client; however, I often ask for black box testing for a small group of people that will be using the application as well – a beta, of sorts – because I know how the system works, therefore, I know what to avoid to break it.

Perhaps an easier way to say this is that I know the base cases in an out. It’s the edge cases that are more difficult for me – or other developers – to see.

5. Customer Satisfaction

Finally, it’s not – nor should it ever be – enough to simply deliver a project. This is the whole reason that we have the process of requirements, scoping, milestones, reviews, and testing.

Until the customer is satisfied with what you’ve turned over for them, you’re not done.

Unfortunately, I think this disconnect happens far more than it should and both parties end of settling for simply wrapping things up. I think there are a number of factors that contribute to this, the least of which is not fatigue. Simply put, I think customers get tired of waiting and testing, and I think developers get bored.

This isn’t to say that that’s an excuse, but that it’s a legitimate reason as to why good development of a given project can take time (and even more time as you push toward that finish line).

That’s Not All

As I’ve said throughout this series, this isn’t everything that constitutes good development, nor why good development takes time; however, I do believe that the fives things that I’ve shared are part of why good development takes time.

Ultimately, it’s about making sure that you build a strong foundation of all of the moving parts, that you’ve solved all of the unforeseen problems, and that you’ve thoroughly testing edge cases and delivered the product to the point of true customer satisfaction.

However, if there’s more to add – and I know there is – then feel free to link it up in the comments.