The Danger of Good Enough

Warning! Rambling ahead.

The other day I learned that people are still remote-editing PHP files on their production servers. In 2017. It is, in fact, good enough for them. And I think software development being a craft, not an art, this is the root of many problems that software projects have: The acceptance of bad techniques for the sake of seemingly fast delivery. But first things first.

Tools Are There to Help

Computers and highly-technological products have a reputation of being unreliable, at least in the eyes of normal customers. There are still plenty of people preferring cars without complicated electronic extras. They want to feel in control and they don’t want to be plagued by bugs and annoyances they are used from operating their computer.

For tech people this seems absurd, but in fact they are working quite similarly: Developers for example want to feel in control. Some use non-memory safe languages, because they say they are doing things that computers wouldn’t be able to optimize and perform efficiently. Some don’t run unit-tests, because in their opinion they are cleverer than other’s software. They are tools out there that need a little bit of commitment, but could catch errors more quickly and save time.

Of course it costs some time to set up a sensible testing environment. Sure you need some resources for setting up a continuous integration workflow. Naturally some work is necessary for building a deployment pipeline. But all of this is supposed to save you time in the long run. And speaking from experience it really can.

“Move fast and break things”

Some people skip standards or techniques of software development, because they want to be able to deliver fast. Cutting corners or just patching something without testing is fine if you are building a small proof of concept or a demo for a hackathon. Outsiders or stakeholders are impressed about how fast people are able to deliver during such events, believing they could apply such methodology to everyday development, which brings us to technical debt: The infamous term that plagues developers and leaves stakeholders in disbelief.

Technical Debt

For building a first version or a proof of concept applying some quick-and-dirty hacking might be the best solution. Using existing parts, putting them loosely together, without any place for over-engineering. Such “hacks” can have a tremendous effect: They can often be really impressive. They might not survive any serious QA session, but still, good enough for showing a possible path.

My suggestion for hackathons/demos/proofs-of-concept: Do not keep the results. Throw them away. You probably learned a few usable things, general obstacles that come up during designing a system that you haven’t thought about before. Focus on the learnings, not on the technological result.

After that you can enter stage two: Doing things cleanly. While the first stage of hacking is more like a sketch on a napkin, the second is applying the learnings and building a maintainable base. With tests and documentation.

If you try to maintain the result of first hacking, congratulations, you have taken debt. Developers will try to hot-fix bugs and means for extendibility will be limited. In the long run patching the new and shiny thing from the hackathon will be a fight with a stinking codebase.

Extinguishing The Fire

“We need to be faster again.” You might hear from stakeholders. And this is right. Without speed and target a development team will just turn in circles, inventing brilliant solutions for problems that no-one has. Experienced developers might suggest a rewrite, which almost always will be dismissed. The reason for dismissal might be either, because they want to ship it as soon as possible or that the investment has been already too high.

Sometimes instead, more people will be temporarily assigned, which sounds totally absurd if you think about it:

1. Doubling number of developers ≠ doubling speed: New developers need introduction. The codebase probably doesn’t have any documentation, because speed. You would have the resources to rewrite large parts, but instead you are now explaining the brokenness to others.
2. Patching broken things: Developers start to apply already broken techniques, because “that’s the way the code works”. Junior developers might even learn for life from that.
3. Broken things get valuable: The thing that is barely held together by gaffer tape becomes a business asset.
4. Small changes can have dramatic impact: In non-memory safe or modern object-oriented programming languages, which account for most of today’s software development, little changes can have an unintuitive, but dramatic impact, because logic and structure might be wrapped deeply.

Reaching a Dead End

All of this leads into an eventual unavoidable disaster. Pick one:

1. Data loss: A “hot-fix patch” drops the database, deletes some essential things or changes state into a unrecognizable state. There is no backup or it is old, because “this is a waste of time”.
2. Breach: Someone starts snooping in your system, finds a security hole, copies your data. You earn a scandal, or pay a hundred thousand Euro fine.
3. Truck factor: Car accident, sudden medical emergency or just someone leaving the company for a better offer. All of the sudden your “business asset” is a liability that no-one understands or can maintain.
4. Your story here.

(Possible) Conclusions

1. Software developers are not special snowflakes to which rules do not apply.
2. Hack/build proof of concepts. Learn from them. Discard them afterwards.
3. Be slower to be able to be fast in the future.
4. Embrace methodologies. Write unit tests. Do backups. Change your underwear regularly.
5. If you think that you will need a week, you will need at least two.