Intro

You know, during my career I've worked on some good sysytems and some bad systems - software development is a fast moving industry, things are changing constantly.... Or are they?

Most of the things that are coming "into vogue" actually date back to the 1970's, people need to remember that above everything, the technology, the good ideas, the bad ideas, that good software - code that is seperated well and has clear boundaries - can transend time and technologies.

With that in mind I wanted to talk about 5 things that developers tell themselves (and sometimes others) to defend and excuse their bad choices.

Note: you should always try your professional best to produce what is your best effort for every single line your write, no matter the curcumstances

Other note: Yes, I have been part of the problem in every case I'm about to list, plese learn from my mistakes

5 - We need to (take a period of time to) refactor

This is just plain wrong, I've ended up in this situation where you feel like you need to just take a quarter or hell a year to just reorganise your code. You've just come off of a big project or have just implmented your feature and are feeling good about yourself until the next request comes in and now the wind has been stripped from your sails because it is something that has been unaccounted for and now you have to cough rewrite cough everything.

We need to remember that unexpected requests like this are going come in, and we need to react to them - we need to be honest with managers and product owners to say that what they have listed was out of scope and that if they want this feature that a lot of re-work will need to be done as part of adding the feature.

We cannot as an industry take "time off" to refactor all of our code to keep our selves happy - it has to be natural, part of day to day living other wise we will fall behind or just be in a perpetual cycle of refactoring.

Remember that Perfect is the enemy of good enough

4 - We need take a maintenance sprint

This is an extension on the last one but moe focused on bugs (and maintenance). Bugs should be apart of your day to day life, if your application is erroring and it takes you 10 minutes to fix each time and the fix is only an hours worth of work then just do the work..... I don't know how many times I've been in a situation beeging and pleading with product owners to allow me to put fixes in for issues like this.

Now I just do them, and when they ask I say "You're welcome" because that's a lot of time and responsibility I'm taking away from my day to day to focus on more important features.

3 - This technology is not fit for purpose let's try....

Before I start I should say: always do your research when beginning a project to try and find the most appropriate technology for your sue case.

Now... This has kind of gone out of fashion because the whole "front end" SPA framework wars are finally dying down (a little) but you don't know how many times I've heard the words "This would be so much easier if we did this in X technology", that may be the case - you may be right - but it adds nothing.

Remember that the technology that has been chosen has been chosen for a reason everything has advantages and disadvantages, the grass is always greener on the other side. When working on one technology for a long times (3-4 years) your bound to find that you're frustrated, just remember because another technology looks easier or better doesn't mean that you should hop onto the "hype" train as soon as the opportunity arises.

For me this is a big one because developers have a huge need to want to keep up to date with the industry (or at least what they hear about the industry) so if they hear that the industry has changed from one thing to another then they immediately want to switch, use case be damned.

2 - This is only a prototype

IT IS NEVER JUST A PROTOTYPE.

That's all I have to say here 😂

1 - A re-write is coming (soon tm)

No it's not.
I don't care if your boss told you that it is. it's not.

Even if it is, what are the chances of that code base being the nivana you want it to be? I MEAN REALLY? What if a new feature request comes in and now you have to rewrite the rewrite.

This is the ultimate cop-out in my books "I don't have to implement this properly now because in a year we'll be replacing it anyway" attitude has lead to some pretty horrifying stories.

I have not once ever seen a complete re-write of a system pan out, even when they were started developers were complaining about the new code within a year. It never happens. Do the best with what you all ready have.