Good nuf’ development

I’ve been called a Copy/Paste Coder and a Duct Tape Developer more then a few times over my career. For some those are derogatory terms, for me they are just part of who I am. But know that those are part of me also doesn’t mean I’m not a Software Craftsmen.

Most of work in an agile environment, but we tend not to really live agile. You can view a good overview of them here. One of the principals is to “Apply the 80/20 Rule”, where 80% of what your customer immediate needs will be from 20% of your work.

How many times have you said “Were going to need this in the future” or “lets do this now to set ourselves up”. Only to not need what you did, or have to make drastic changes to it when it came time to actually use it?

We are awful at predicting the future, there is no way around it. When we doing work for an unknown future we have to guess and estimate. More often then not our guesses and estimations are wrong, if not horrible inaccurate.

In every phase and section of development, from architecture to UI design without hard and fast realities we tend to overestimate what’s required and what’s truly needed. I’ve personally stood up extremely complex architectures to handle disconnected operations for Resgrid only to find that multiple people would never interact with the dataset the way I built the architecture to handle. I basically threw away weeks worth of work because I made the problem more complex then it really was and all it took was interacting with a customer to figure that out.

It’s not hard to practice “Good Nuff” development. If your starting to hypothesize about needs, requirements, use cases or imagine scenarios that haven’t been given to you don’t code anything unless you run those by a customer.

It gets fuzzy when your talking about architecture or the foundation of your product or app. But when your designing or implementing the architecture ask yourself, is this to address an immediate or concrete need that’s in support of a vetted customer requirement? Notice I added the word ‘vetted’, when creating your architecture don’t assume or guess, talk to a customer and pitch the emit of your architecture. If it’s an 80% requirement for a customer, put it in, but if it’s in the “nice to have” area, don’t add it.

Complicating an architecture from the onset will slow development, increase mental load to work in it and reduce the ability to onboard new people onto your team. Think of your architecture as a garden maze, the more complicated it is, the harder it will be for people to navigate. Don’t take the hit from the onset unless you absolutely have to.

Finding the right balance is important, but if your guessing or hypothesizing about future needs there needs to be input from your consumer. Keep it as small and simple as you can for as long as you can, simple is good.

You shouldn’t “kick the can down the road”, address your problems and tech debt as soon as you can. But don’t justify building things just because you ‘may’ need it in the future.

If you’re a First Responder or know one check out Resgrid which is a SaaS product utilizing Microsoft Azure, providing logistics, management and communication tools to first responder organizations like volunteer fire departments, career fire departments, EMS, search and rescue, CERT, public safety, disaster relief organizations.