Cutting Corners

Just yesterday we were having an interesting conversation about cutting corners while developing something. Cutting corners is bad - evil for software development I would say. The conversation was about meeting deadlines and hence taking the shortcuts. What I have understood in all these years of developing software is the apparant shortcuts prove to be the long term headaches. The system goes into an irrepairable state since everytime a deadline is to be met or the there is delivery pressure we tend to cut corners.
There are always deadlines when we deal with software delivery. If we keep on cutting corners, the whole structure is going to collapse one day quiet literally. Agile methodologies help you avoid cutting corners.

1. If you are following test first, you won't have to cut the corners, you are always honing those.
2. Frequent checkins are keeping your changes safe in the repository, less worry about the checkins and hene more time spent on coding rather than resolving conflicts. More effecient way to code, less pressure of deadlines.
3. Continuous integration is giving you flexibility to get continuous feedback on the work done.
4. Continuous integration and the tools which enable refactoring giving the freedom to change code without the fear of messing up.
5. In the ideal 'self organizing' and 'motivated' team of an agile project, it really becomes a habit to write quality code every single time, without cutting corners.

If 1 to 4 are taken care of, it really is matter of choosing the right people with the right mindset to avoid the pitfall of cutting corners and delivering substandard code. Reviews simply become redundant if you have the right people collaborating and developing software giving responsibility of maintaining the sanity of the codebase to every team member.

Legacy Code Lesson - Part 1

Legacy code has been teaching me a lot of stuff. Reminding me how important tests are, and making me realize the advantages of doing TDD. So here I am on a task of re-factoring a piece of 'working' functionality. There are unanswered questions in my mind-
1. How do I know it is working? I do not see tests..!
(But hey there are integration tests somewhere..! Ohh I hate those.. :( Long runs..!)
2. What is that's exactly wrong with it?
3. Where do I start?

With these in mind, finally I started with of-course writing tests. Getting unit tests running itself, is a big step. The very first unit test fails, and I grin like a winner. But hey, it fails because some configuration somewhere is missing. I start noting down the things to correct..!

1. The code is completely coupled, too many dependencies
2. Constructor doing more than it should
3. Lot of helpers a.k.a static classes
4. Lot of Singleton mess
5. String, strings, strings!!
6. Enums and lot of them
7. Method with 10 parameters. :( aww..!

And I am tired and up for a coffee break already..! There are bigger decisions to be made, re-factor or rewrite?