Did you here the words "can't have time now, implement that quickly" or "we need a.s.a.p. that for a presentation"? If you did that, you should know that you are in the middle of the battle. Invisible bullets go near your ears and you and your team are living on the edge. That's not bad in itself, but can became as bad as can be soon, if you can't handle. I'll explain why.
When you have to implement something, either is a new feature or a solution for a bug, you face one common problem. You can take main scenario, fix what it should do and go further. That's called quick and dirt. That is because the code resulted from that is really dirt. The second and best approach is to face to problem for today and tomorrow. Think hard and implement the optimum solution, use a good design. As I said, there are times when quick and dirt saves you from something. Is like in management, the difference between important and urgent. The urgent sometimes is more useful than important. But this has a trade off.
Ward Cunningham invented a metaphor for that, which fits well in understanding the implications. This metaphor is called Technical Debt. Technical debt is similar to financial debt. When your business needs something urgent and you don't have enough money, you borrow some from the bank and do your job. After that you have to pay interests and principal to return the debt. Same in software, but here you deal with quality in place of money. Sometimes to get a good deal, to touch a milestone or to give something with few resources you can accept quick and dirty. After the deal is done you can decide if you live with that or you refactor it, using a good design this time.But you must have always in mind the working on poor code means paying more interests. And if you pay too more interests your deals could became a bad one. So, for your health, refactor as soon as possible. That is called paying the principal and eliminate the technical debt.
Quality in software means resources. You have to spent more resources to have better quality. As Martin Fowler said here, technical debts hurts performance. And the performance is almost unmeasurable in software. You have to manage a proper balance in your technical debts. If you hear the magical words which leads to quick and dirty, open your ears. If you don't hear soon about refactoring tasks, you should put your questions. If these things come again and again then you could go into a swamp with your projects. Everything begins with parts of code which is considered ugly and unmanageable. These become to stink. The project can go to the slowly path of death by technical debt suffocation.
How to handle technical debts?
There no standardized solutions. That's because is hard to measure and because managers like Excel too much. They like to see numbers, that give them the sensation of control. But numbers are not so bad. They really don't show the things how they are (don't let the managers know that!), but the process of getting these numbers enforce some processes which could help in handling technical debts.
A good individual exercise which I practice is using of IDE meta comments like TODO, FIXME or somebody else from the family. When I begun to implement something which is complex somehow I use TODO comments. I use them as bookmarks to remind me that I should complete something. These marks will be removed until I submit. So they exists only to remind to my poor memory that I did not finished the job. Before submit I check to see if everything is like I want by verifying and removing these comments.I call them Transient Technical Debts. Transient because these technical debts are not persisted into version control system.
A similar approach could be followed for the persistent technical debts or the normal technical debts. You can you a marker like FIXME. Maybe a FIXME and a date. Better is to have also a system for controlling them. A good approach is to put an effort in the next iteration of your software and eliminate them. So all the technical debts you accumulated on the current iteration will be paid in the next one. Just to keep things in control.
Another approach is to keep that ledger in the bug and task tracking management system. You can have some attributes on tasks and bugs which tells us if the job was done quick and dirty or not. If we have to spent more effort to put a good implementation in place of a poor one. A mixing solution is to have code comments linked to that kind of a system.
These kinds of ledgers are good because they can give you numbers also. It forces you to have a health quality of the software and keeps you manages happy. They have the input for nice charts and reasons for raise your salary. Anyway, keep your ears tuned and don't go int the technical debts swamp.
No comments:
Post a Comment