Why Good Development Takes Time

Earlier this week, I wrote a short stating that good development takes time in which I basically laid out the idea that we all fall into the category of a producer or a consumer – at least at some point – and that none of us are immune to wanting something good, and wanting it sooner rather than later.

For some, the post was a bit cliche – which is fine :) – but I was also asked a  question via Twitter that I thought was deserving of its own set of posts

And so I know that the answer that I’ll give will obviously be relevant to my experience, but I thought I’d share it anyway, and hope that you guys would also chime in with your own experience and ideas as to why good development takes time.

Why Good Development Takes Time

The short answer is that I believe that good development takes time because we’re literally creating something using a set of abstractions to create something for someone that solves a problem that didn’t previously exist.

And when you set out to do that, there are a lot of things that you have to take into account.

1. There Are Moving Parts

There’s a bit of a debate as to if the term “software engineer” is even something that should be applicable to programmers, because engineers who work in the physical world – you know, on bridges, buildings, and general infrastructure – have to account for a variety of factors whenever they’re working on their projects.

This post is not one to debate that; however, I do think that engineering is applicable to software, albeit in a significantly different way.

If you've got moving parts, this isn't doing it right.

If you’ve got moving parts, this isn’t doing it right.

Whenever we build a solution for someone else, there can be a lot of moving parts to the system:

  • You’ve got front end code that’s responsible for rendering data, responding to user input, sending data back to the server, and more.
  • You’ve got an application layer which can consist of a wide variety of components – anything from models that are meant to serve as middleware between the database and the front end – to other components responsible for periodically pining the data store to make sure that whatever the user is seeing on the front end matches the data on the backend.
  • And if you’re working in a multi-threaded applicable, you’ve got to handle synchronization and locking such that no single thread is accessing a significant piece of information at the time of another process, and that it properly relinquishes its ownership of the data when its done processing it.

Of course, this is just to name several things at a high-level.

Now, it is completely possible to get away with building software for others that have significantly fewer moving parts, but this usually consists of software made up of anti-patterns, god-classes, or very rigid sets of functions that don’t necessary work well in harmony with everything.

At times like this, maintenance is often going to be very tough, and the performance may even suffer.

To that end, making sure that all of the moving parts of the software – from the backend, to the middleware, to the front end – are functioning well, are able to handle change easily, and that respond appropriately under a variety of conditions in something that takes more time than not to build correctly.

2. Problems Within Problems

Another challenge that comes with building software is that, from the initial outset, we know the general idea and scope of what it is that we’re going to be doing for the customer; however, this often leads us into other unforeseen problems.

Problems Within Problems

This is arguably one of the most fun – and/or frustrating – parts of building things for other people. While trying to solve the general problem for the client, we end up facing issues perhaps around performance, architecture, storage space, or whatever that demand that we think creatively in order to solve the issues.

Yes, it can be frustrating, but having to think of ways to properly solve these minor problems can often end up in us making notes to spin off our own libraries or tools that will come in handy for other projects both for ourselves and for others.

Even if we opt not to go that route, the sheer reward that comes from solving these problems within problems is enough to keep the gig exciting.

Even still, this doesn’t change the fact that good developers will end up taking time to solve not only the larger problem at hand, but to properly solve and handle the minor problems and issues that arise when trying to build something as part of a larger system.

In doing that, the time of development may take longer than expected, but – ideally – the delivered solution should be better for it.

There’s More…

As I began working on this post, it ended up becoming one of the longer posts that I’ve written, and I try to keep the posts relatively short.

To that end, I’ll wrap up my thoughts on why good development takes time in the next post; however, I’m open to hearing things that aren’t listed here (because I know they exist :).

In the next post, I’ll be talking about:

  • How Much is Too Much
  • Edge Cases
  • Customer Satisfaction

But there’s more that can be added.

So if you’re someone that has something to add to the two things mentioned here (or the three things that are coming in the next post), then please feel free to add ’em in the comments.

After all, I can only share from my own experience and none of us have had the same experience in our day-to-day.


    Leave a Reply