Since working in software, one of the things that I’ve yet to actually get used to is how quickly people want things delivered.
But I’m not saying this as someone who has built things for others, but also as someone who enjoys using things other people have built, and as someone who cares deeply about trying to get better at what I do for a living.
The bottom line is that development takes time, and good development takes even more time, but neither of the statements are completely one-sided.
Development Takes Time
Anyone who has ever tried to take on a new hobby, better themselves in someway, or create a new habit, knows that it takes time. And such as it is with development.
No, this isn’t a novel idea, but I think as far as the development community is concerned, we’re really quick to complain about how quickly clients want things turned around without actually looking at the idea holistically.
- Developers wants their skills to increase, but good development takes time
- Clients want things turned around quickly, but good development takes time
- Everyone wants their favorite hardware and software tools and toys updated quickly, but good development takes time
So what’s the point in actually writing all of this?
The initial motivation came because I’ve seen so many other people in our community complaining about how quickly some (not all, of course!) clients want their solutions delivered; however, as I spent more time thinking about it, I realized that we’re all the same: We just sit at different points of the lifecycle depending on if we’re the producer or the consumer.
As a Producer
As a producer, or a developer, it’s easy to get frustrated when others are placing demands on us to deliver a solution quickly. Building software takes time, and building software well, takes even more time.
We know this, but our clients may not.
Though it may take some time to discuss and educate, it’s far easier to discuss this with our clients than get flustered at their wanting us to have something delivered more quickly than we can deliver, isn’t it?
After all, we spend a significant amount of time learning their domain so that we can provide a solution. It doesn’t hurt to provide them with some knowledge of our domain so they understand what we’re doing, would it?
As a Consumer
We also know what it’s like to sit on the other side of the table – think about how many times you’ve gotten frustrated whenever a piece of software or hardware is delaying whether or not it was a something used more or less as a luxury or as a tool for your day-to-day work.
We want it delivered, we want it solid, and we want it now.
Realistically, we can’t have all three. Personally, I’d rather have the first two and wait out the latter than anything else. And this is what it’s like to sit in the client’s seat whenever we’re developing software for them.
We know that feeling, right? As such, I consider a part of our job to set expectations, realistic milestones, and the responsibilities of both parties before actually moving forward.
Okay, So, What’s The Point?
Ultimately, the point that I’m trying to make is simply that people on both sides of the table – that is, both developers and clients – need to understand that good development takes time.
If clients ask for a rushed solution, then they are going to get something that’s likely poorly developed because time limits quality.
Similarly, if developers want to get better at what they do, then we need to know that improving our skills to become better at what we do is going to take a lot of time. 10,000 hours, perhaps (personally, I think it varies but I digress on this topic for now).
Finally, we all enjoy our gadgets – both software and hardware – whether they be for luxury or for work, but I don’t think anyone wants a rushed product that sacrifices quality when it comes to things for which we’re the consumer.
Why should we act any different in our day-to-day gigs?