Bug / Task / Hot Fix

“To be or not to be …” or in today IT world .. “it’s a bug or it’s a task .. “. I know, pretty extreme, but have you ever experience with situation, when business sees something as a bug, but you as a developer see it as a task ?

Before I start, I want to define few terms I’m going to use

specificationdescription of a feature or behavior of an application. You can also imagine it as a “documentation”
clientany party, who creates a request to IT sector. Sometimes also marked as “business”
Table of terms used in an article

Also I want to point out, I will not mention or taking to an account agile or classic project management …

๐ŸžWhat is a bug ?

From my point of view, bug is something what should work according to specification, but it doesn’t. Simple as that. The main problem with that is simply – no specification

โ˜‘ What is a task ?

Task is definition of something, what is not part of the specification / application and we want to add to it. I see the same main problem as in previous case – no specification

๐Ÿ”ฅWhat is a hot fix ?

Hot fix is kind of application behavior, which can be defined as a bug, but has a big impact on application flow ( application does not work at all, application causes loss on company profit, application negatively influence processes inside of a company )

Some other views of hot fix are as “quick fix”. So please fix it as dirty and as fast as possible and you will have time in future to make it good. Problem with this approach though is, that in real world, there is never a good time to make a refactoring or “make it good” ( until it’s working as expected )

๐Ÿ’ธ Why is this important to distinguish ?

Only because one thing. Money. In case something is marked as bug / hot fix, development should pay for fixing the problem. In case something is marked as task ( user story, improvement ), Customer / business should pay for the development.

All other discussions – are they really needed ? At the end of a day, job has to be done. No matter it is bug / hot fix / task / feature / user story / improvement … job has to be done .. the only question is “Who will pay for it” ..

๐ŸŒ How is this all applied in real world ?

Long story short: Client always tries to find a way to prove, it’s a bug or hot fix. Development always tries to find a way to prove something is a new feature and it wasn’t specified ( even mentioned ) before.

Nice hacks I’ve experienced with are argument, that something is “market standard”. In case everybody around me has it, it’s logical I want it too and and discussion about “new feature” can’t be considered, because it’s something so obvious it’s not believable it wasn’t implemented at the beginning ๐Ÿ˜Š

๐Ÿง‘โ€๐ŸฆฑHow this applies to you ?

In case you are a client, you can now better understand, why your IT department ( or you IT agency ) always discussing with you if something is bug or not.

In case you are a developer, you can understand why there is mysterious funny smell in the air when you are talking about bugs. Also you should be aware, this discussion will never ends. In case you are working for agency, this is something very important as far bugs will be always for free and features will be always paid ( of course in case deal does not specify it else )

In case you are a developer working at internal IT team, you should know this kind of discussion will always be there. But at the end of a day, you should realize, it’s just a job to be done ( no matter what label it has ). You can only improve your programming skill to make an application to be better because of you.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.