Perfectionists need not apply
There seems to be a constant conflict between the time it takes to write well-organised code, and the time available to deliver the product. On top of that, managers often praise quick and dirty solutions over carefully written code.
It gets the job done … until the next flood. Photo: PxHere
According to StackOverflow survey,1 one in four developers listed Lack of support from management as one of the greatest challenges to productivity. Looking at various online comunities it’s relatively common for developers to complain how management doesn’t give them enough time to produce quality solutions, and how their colleagues get praised for quick and dirty solutions, at the cost of unmaintainable code or inefficient products. It seems maintainable codebase and long-term stability mean nothing to managers.
Luckily, the world isn’t so black and white; after years of complaining of these things myself, and as I got more senior roles, it slowly started making sense: it’s all about balance.
Balance: the developer side
As a developer, I always looked at code as something durable, something lasting. My job, I thought, was to take a problem, and find a solution so others won’t have to bother with the same problem ever again (except, maybe, to improve on my solution). I’ve made sure my solution was thoroughly tested, I’ve pushed it to the client, and … it never made it to production. Turns out the client decided they didn’t like that approach and opted for something else.
That didn’t happen too often, but it did happen often enough to receive a memo about delivering products on time, and to have a serious talk with my supervisor. Eventually, I learned to deliver my code faster and to give better time estimates so I could meet deadlines with my development process. In a large corporate environment, that would probably be the peak before my career hits a dead end.
Balance: the supervisor side
Luckily, in a relatively small environment I had the opportunity (or rather, I was expected) to take on more and more responsibilities due to my job tenure. Through communicating directly with clients, providing estimates, and seeking compromise regarding price, something became apparent: not all problems & specifications are created equal.
Often clients just want to try how the flow they imagined would work in practice, so they can decide about using it. Other times they aren’t exactly thrilled with the solution they have, but they still want you to start implementing it in case they don’t come up with something better - that way, at least they’ll have it up & running sooner. And there’s a good chance something they need for this year’s summer promo (and they swear will be used for all their future promos) actually won’t be touched ever again.
A can of beans will outlast your code
Most code written today is meant to be consumed within 2 years - that’s less than the shelf life of canned beans (3 - 5 years). After that time, companies start working on redesigning user-facing software and implementing significant UX changes. While that doesn’t necessarily mean your code will be affected by those changes, user-facing software is where clients get the most involved, where long-term benefits are hard to see, and where you’re the most likely to get yelled at for wasting time.
Trying to find the balance Photo: Pixabay
Coming together
Everyone has their job to do. Managers need to ensure products are delivered on time, within client specifications and budget. Developers have to do their best to prevent bugs and unnecessary expenses. And it’s important both sides are aware of that.
As a manager
Someone who worked with a client, listened to their plans and ideas, and who has seen how they react to different suggestions, will subconsciously pick a lot of details between the lines and from their body language. To you, it may be perfectly clear something is only an idea client wants to try out quickly rather than a lasting solution. Still, a developer will never figure that out from a “high” ticket priority.
Pay attention to such details, and include them in the specification, so developers know when a simple mock-up solution is enough as it’ll be removed next month anyway. They can’t know something if it’s not in specification, and they’ll try to deliver a quality solution unelss they know client is only paying for a temporary fix.
As a developer
Managers can only understand the benefits of clean and reliable source code as long as those benefits are evident, and they get numbers to back that up. A good way to achieve that is by establishing code ownership and clearly marking code owner on each issue. Track how long it takes everyone to fix their own bugs, and hopefully, it will show that your best practices result in spending less time on fixes and bugs.
Managers can’t just know what information you need for efficient work either, so ask them about details. Don’t try to deliver a perfect solution unless you’re sure a perfect solution is what they need. And learn the difference between “This absolutely needs to be perfect” and “I expect perfection every time”.
As it turns out, most of the time, perfectionists need not apply.