How To Thread The Dev Needle

Finding The Balance Between Potentially Perfect And Good Enough To Ship

Josh Brunner
Helpful Human
Published in
4 min readJun 22, 2017

--

If you develop software, you’ve undoubtedly come across a situation where you are up against a deadline and need to ship some sort of product. As a consulting agency, we are often up against deadlines, NTEs (Not To Exceeds), constant derailing, and unexpected interruptions from designs and changes in a client’s needs.

Amidst these distracting occurrences, we’ll get to the point where we need to make a decision — should we tell the client that their project is not ready to ship? Or, should we tell them that the current iteration is ready to go?

Unsurprisingly, if you wait until the last minute to tell the client that their project is not ready to ship, they will be upset — and rightfully so! It is imperative to involve the client and all project stakeholders in the progress of your project. Doing so helps ensure that no one is blindsided by disruptions and that everyone has the proper expectations for each project interval.

Regardless of the chain of events that may or may not have led a project to become derailed and sidelined, sometimes a project just isn’t ready to ship in time to meet the deadline — or is it?

What is Success?

One of the things I do before I start any new endeavor is get a clear understanding of what success looks like. This means that I know exactly when I am getting close to completion on a given task or client project. Additionally, it helps me to be able to communicate to stakeholders how close we are to being finished.

Ultimately, you get to a point where you have no choice but to make the decision, do we ship a broken product and fix it later? Or, do we delay the launch and ship the product once it is ready?

Personally, I think it’s important to find a solution that meets the needs of both sides. While it may be tempting to say, “We’ll fix it later — in a future version,” your users may end up being scarred by the initial burn of a poor software choice and find a better solution elsewhere. This will lead to a negative reputation and may potentially cost the product’s overall success.

I lean towards the latter solution, in which you take the time to produce a solid solution that will (hopefully) stand the test of time and require minor maintenance work down the road. Of course, you don’t always have all the time you need in order to “complete” a project, and that’s where some decisions need to be made.

Potential Problems That Slow Your Project

Sometimes you can holistically redefine what success looks like in order to ship a product on time. Analyze the initial expectation of the project, and then contrast that with the project’s current state. It may be that you are able to identify the features that will make the biggest impact to the end user, and dedicate your time to these features, as they will have the best ROI.

Too Many Features

If you can redefine what success looks like by removing superfluous or less important features in order to ship the product on time, this is probably your best bet. Make expectations and goals more realistic, and cut the extras. You can always fill those in later.

Incomplete Project Architecture

Other times, a project may be behind schedule because of the ways in which it was architected from the start. It may be time to reevaluate how all of the moving parts of the project have come together and see if any pieces are doing more harm than good.

While you can hire outside contractors to come in and do an evaluation, I’m of the opinion that the developers on the project will already know what is causing the biggest pain points and will, quite possibly, already have a solution to the underlying issue(s). Give the developers some time to identify and resolve the underlying issue(s) and it will likely pay off.

Over-Engineering

It’s worth it to note that the project’s delay might be due to over-engineering of the software. Developers need to always be thinking about edge-cases — accounting for unplanned uses of a product’s initial intent. While accounting for edge-cases is a great skill, it may also be the reason that the project is taking longer than it was scheduled for. Have a discussion about the kinds of edge-cases that are being accounted for and see if there’s a pattern that needs to be dissolved.

Remember, Nothing is Perfect

Software will never be “perfect” — it’s an ever-evolving masterpiece. If someone ever says that they can produce software that will be 100% bug-free, perfect code, you run away from them as fast as possible. You can always expect software to need improvements, and for there to be unexpected circumstances that completely take down your system. The seemingly fragile nature of modern day software is largely due to the significant interdependence that our systems share. Expect your software to evolve, and explore new possibilities within the tech realm.

Making last-minute trade-off decisions is uncomfortable. To help mitigate this from occurring, properly design and strategize the way in which you plan on getting your work done prior to ever touching a line of code. Delays and interruptions are inevitable, but if you pick the right team to lead you through situations when they arise, you’re bound to come out on top.

--

--