Right and Wrong Ways to do development

What’s the best way for developers to support the business?

Building the best possible systems that adhere to the latest and greatest best practices, following the architecture guidelines, unit tested and built right with no technical debt.

That’s the standard we set ourselves, as developers, and yet we end up cobbling together solutions in a rush because the team lead or the head of technology or even the CEO demand we accomplish things in very limited time scales and we have to support the needs of the business.

So we have 2 standards… the one that gets the best tech and keeps the developers happy. One that gives the business what it needs when it needs it.

It seems like we’re always doing the “wrong” thing to give the business what it needs simply because the business want's it now.

Let's examine that, though.

Why is it the wrong thing if it gives the business what it needs when it needs it? Answer: It isn’t wrong at all.

The problem is the view that accepting technical debt is wrong. If the business is choosing to accept that then it’s right, at least in the short term.

We need to move away from the idea of the right and wrong way - because this is a business, not a university lab where we're looking for a first-class honours degree.

What we have are tactical and strategic workflows. Tactical workflows are all about the short term and meeting the immediate business need, often derailing strategic changes.

Tactical work should always be followed up with it’s strategic counterpart - which gives us longevity, testability and what we were calling the “right” solution at the start of this article.

This is a big part of sprinting - we iterate. Our iterations might be as follows…

  • Initial tactical solution ( service MVP? )contains features A,B and D
  • Add feature C
  • Remove feature B
  • Add feature X ( service is now feature complete )
  • Strategic refactoring to improve framework version
  • Strategic refactoring to improve data store
  • Strategic refactoring to improve architecture pattern

and each iteration may well be multiple sprints away from it’s predecessor. Each tactical solution must be done with conscious and well deliberated decisions regarding the future strategic end goal.

So now it’s a single standard that keeps the business and the developers equally happy, and we are always doing the right thing.

There is no such thing as "best" practice. There is only practice to your best ability to deliver.

Like
Reply

To view or add a comment, sign in

More articles by Paul Caligari

  • TDD for dummies like me

    TDD stands for Test Driven Development. With test driven development the test come first and the code is created to…

    1 Comment
  • Mocking APIs

    When we, as developers, write code we like to see it in action. To do that we execute it.

  • Constantly Id'ing problems...

    Time for another developer rant! I am constantly amazed by how foolish we developers can be. In this article I am going…

  • Do Design Patters Hold Hidden Dangers?

    Over the past 30 years I have seen a new language for developers to use emerge. It's the language of the design pattern.

  • Tracking Actions Through Multiple Micro Services

    In a monolithic application tracking what happens when a user clicks a button is relatively straightforward. You would…

    1 Comment
  • Programming from habit

    During an advanced driver training lesson, I was approaching a roundabout on an utterly empty dual carriageway, I could…

    2 Comments
  • Documenting Code

    I'm pretty sure we all hate documenting code, and we are all guilty of not updating the documentation when we make a…

  • When Unit Testing and Frameworks Collide

    I'm a big fan of unit testing. It allows me to be much more confident in the deployability of my code.

  • Refactoring - why "fix" what isn't broken.

    First, what is refactoring? Refactoring is changing things, hopefully making them better. To use an example from…

  • Why use docblocks and type hinting.

    We all know from countless computer science lectures that commenting code is important. The reasons given are wide…

Others also viewed

Explore content categories