About my blog

I write about the technical and non-technical aspects of software development

How it works

Microsoft ASP.NETASP.Net
BlogEngine.NET BlogEngine.NET
Azure DevOpsAzure DevOps

Contact info

 Email
 Contact

Follow me

Prod-20240407.1

Tearing up the rulebook

We often like to think that a business - especially our business - is a completely unique, a free agent that can tear up the rulebook and do whatever it pleases in any way it chooses. This series of articles will show you how, but be warned, there are consequences!

Tearing up the rulebook

We often like to think that a business - especially our business - is a completely unique, free agent that can do whatever it pleases, in any way it chooses. This is no surprise; many businesses are started by people who feel stifled by the constraints of employment or corporate life.

In reality though, there are often 'right' ways to do most things, irrespective of the supposed freedom to “go your own way” or the belief that one’s business somehow "breaks the mould".

We might call these 'best practices' or 'standards' or even 'rules'. In general it's advisable to follow such methods because they tend to be tried and tested, efficient, well understood by others, and ultimately, cheaper or at least more cost-effective.

Luckily, if you or your organisation are one of those who want to plough your own furrow regardless, there is usually a measure of customisability to most methodologies or best practices. You, your organisation, department, or team needs to find the sweet spot that works for you.  It is understandably a process of trial and error, measurement, assessment, review, and continuous improvement.

The difficulty arises when you or someone in your organisation takes the "our business/sector is unique" epithet a bit too literally. They start to believe that the fundamentals don't apply to them, and either ditch some practices altogether or bend and twist them out of all recognition, to find a shortcut that satisfies short term targets.

If you are one of those people, you've come to the right place!

The first thing you want to do if you're intent on breaking the rules and you're in the technology or software sector, is to justify your dismissal of industry best-practice by giving yourself a catchy epithet such as disruptor, innovator or unicorn. Stick a catchy meme or quote from Steve Jobs or Elon Musk in your office kitchenette.  You're on your way.

Rules for rule-breakers!

So, you want to tear up the rulebook, right? Why would you do that?

Usually, it comes down to the idea or hope that it will get your projects delivered faster, with lower cost. This means cutting back on process (planning, analysis, QA), expenditure (hardware and software), and human resources (developers, project managers, analysts, testers).

As a contract software professional of over 20 years, I've dealt with numerous organisations from single-office companies through to teams within global enterprises, that to all intents feel that the basic rules or methodologies of software development and delivery don't apply to their "unique" situation. 

I've seen businesses take a core principle and instead of learning how to adapt and implement it, will twist, trim, and deform it to fit with their existing management style, corporate culture or preconceptions. And what happens?

Well, usually, nothing happens! Which is of course, why you and many organisations may as well ignore them.

True, it might cause delays, disruption, system or process failures, errors, and ultimately customer dissatisfaction and reputational damage.  But, then again - it might not!

If it happens infrequently enough and is of low severity, you can chalk it down to unfortunate business-as-usual incidents, and justifiably avoid any action.  After all, the perceived or real cost of fixing the root causes may exceed the cost of the incident itself, so why bother?

If it happens more frequently or with higher severity, you may be forced to correct the underlying systemic issues.  You might need to re-train staff, increase headcount, implement better management and processes, better infrastructure or allocate more time for quality assurance.  This is of course, a pain, but there are ways to get around this too! 

And of course, once you've fixed the serious issues, you can look for other shortcuts!

In this series we’ll be looking at three facets of software delivery: planning, analysis, and quality assurance. Over the next few posts, I'll show you how you can take shortcuts and thrive in spite of the consequences!  The links below will be enabled as each post gets published.

  • There is no Plan A!Cutting back on discussions, workshops and planning of work, or even skipping them entirely, is an important shortcut that could reap dividends!
  • Analyse this! A popular shortcut is to leap over the analysis phase, with the hope that issues will be easily resolved during implementation
  • Testing timesAnother favourite! Shortcuts on testing and quality assurance is a great choice if you're keen to cut back on cost, resource and time
  • Getting away with itSo you've cut corners and played fast and loose with best practices. Here's how you can still succeed in spite of the consequences!
  • The gods among usThe ultimate, and most effective solution to managing the fallout from shortcuts. But there is a price to pay!

You Might Also Like


Would you like to share your thoughts?

Your email address will not be published. Required fields are marked *

Comments are closed