Skip to main content

Are you a ticket closing developer?


"I have done my work. I'm taking another ticket."
"Can we close this ticket end of the sprint."
"Why is this ticket still open."
"We need to work extra and close these tickets."

Those are only a few phrases. If you have not heard those words, congratulations!! you are working in a super nice environment. Unfortunately for most, these are daily sentences they encounter.

The definition

I'm using this term for anyone, be it an intern, architect, manager or anyone whose main target is to close the ticket by themselves or by forcing others. They do not focus on, do not allow code improvements.

Why do they do it

As I can't read minds, I don't know. However they may be targeting big paychecks, promotions, praises, etc by showing they are very efficient, committed, etc. However they are just moving from one ticket to another.

How do they look like

  • Lazy to learn
  • Do not understand the value of good code
  • No proper use of design principles
  • No will to improve the code
  • No will to accept new ideas
  • Lots of private methods
  • Many helpers, utils
  • Trying to show off
  • Eyeing releases ignoring code quality

What is the problem

Quality of the code!!!
It does not matter someone's position if he or she sacrifices the code quality for their own benefits.
People do not care about nice clean code. It takes extra time to write that kind of code and you need good knowledge, practice also. This little effort (or big) will save a lot of future bugs and will save a lot of time when adding new features. However people are blind enough to accept bad code with quick delivery. More than that, they don't understand that the bug came from the bad code, which gives a higher cost.
As ticket closers easily go up (promoted), they force others to do the same.
Rembmer: No release has higher priority than a good code.


Most of the companies use Sonar to measure code quality. There are sets of rules defined and developers must satisfy those quality gates. Also there are unit test coverage integration tests automation tests, etc.

Quality of the code

Above quality measures are industry standards. That is true. However people can easily avoid those (sonar-rules-will-not-solve-your-design). For an example I wrote this regarding such a code (batch-processing-with-iterator-pattern). Most of the time ticket closing mindset will create private methods, helper classes, scattered logics, non extendable codes, etc and claim that that is a good design. But in the long run those will add more bugs to the system due to fragile code. Logics are scattered. Simple change needs a lot of effort. You change one place, a bug appears somewhere.

Unfortunately, most of the people (interns to architects) do not care about this as long as they can close the ticket which gives the praise they are looking for.

Is it management's fault

Yes and no. If you truly want to write good code instead of just closing the ticket it is then not your fault for now. But it is your fault for not asking time. If you yourself have this attitude then no one can help you.


Be agile, be truly agile!! It is unfortunate that most of the companies use the word agile only for the marketing purposes but in reality they use waterfall or ad-hoc practices.

Have a look at this agile principle.
"Continuous attention to technical excellence and good design enhances agility"
Now look at this agile value.
"Individuals and interactions over processes and tools"
Yes, in a truly agile environment it is your responsibility to fight for the code quality.
Read clean code. I have no words to explain the value of this book.

Again, ask yourself, what is the point of working with this ticket closing attitude when you are an engineer.