Alright! It’s been a while. Here is what happened during all that time. I went on vacation in August and I had some changes in my life on the way back.
Just to inform everyone now that the posting should be more common. I’m planned to be on the Visual Studio Talk show somewhere by the end of October. Also, don’t miss me at the TechDays 2009 in Montreal and Ottawa! Some pretty nice subjects are talked about!
Talk to you all later!
What is one of the greatest advance of Visual Studio since the coming of .NET? You might think it is the Garbage Collector or the IL which allows interoperability between languages? I think of one the great advance of Visual Studio 2003 (all the way through Visual Studio 2010) is the debugger. Previously, debugger were hardly as powerful as Visual Studio. And that is the problem.
The quote from Wikipedia is “a debugger is a computer program that is used to test and debug other programs”. The debugger is used to find bugs and figure out how to fix them.
The debugger is used to go step by step, step backward, step-into, etc. All this, in the hope of reproducing a bug.
It might be one of the most powerful tools that you have under your hand. But it’s also one of the most dangerous. It encourages you to test your software yourself without having tools do the job for you. Once you are done debugging a module, you will never debug it again unless there is a bug in it. Then you start building around this module and you test the new modules against the first module. And then starts the fun. You start modifying the first module but don’t test again the first scenario that you built. Now, the next time another developer build something based on the same module, there is two thing that can happen. The first is that the developer is going to be afraid to change the module and will duplicate the code in another module to make sure he doesn’t break anything. The second option is that the developer is going to change the module anyway and rerun the application to make sure he didn’t break anything obvious. Okay, there is a third option that consist in adding test to address the new behaviour but we’re not interested in the good stuff. Just the bad.
Okay. After I just told you this nice little story, what do you think will happen in the future? As the other developers goes into the code, they will add over the modules again and again. As the modifications keep on coming, the module will keep on changing. As the changes goes “debugger tested” only, bugs will start to appear in modules that never had bugs before. To “test” the right behaviour, the team will start to add test script to execute manually to make sure no bugs are left behind. This will require interns or QA people to run the test.
Infect your code with test and stop using the debugger. That’s simple. I know that Ruby doesn’t have a debugger integrated inside the main UI it’s using. Ruby developer still manage to deliver quality code without the integrated debugger. In fact, lots of developer manage to make great software without debugger. Running without debugger and test however is NOT the solution. You must ensure that your code is covered with code as much as possible. When you find a bug, make a test that reproduce the bug and fix the production code. As your code gets tested, additional modules will not make break unless they break a test. This is the solution. This is the way to make good and clean code.
Every developer writes code. Every developer works or has worked on a Brownfield project. Working on a Brownfield project often makes developer complain about the code being poorly written and hard to maintain. That surely sounds familiar, right?
This is basically a pledge to good code. Bad code makes things worse and cost business money.
There is no scientific study about this. Primarily because most projects are private and won’t allow studies and there is still no clear metric that represent clean code. Mostly, metrics can’t represent bad code. So how much money can be saved? Well… bad code hinder maintenance, comprehension and scare programmers of changing a class that was working well before. I don’t think we can calculate now, but I think that Cyclomatic Complexity, LOC per functions and Code Coverage represent a big indicator of code that are hard to understand and difficult to make changes.
Code that have high cyclomatic complexity and huge LOC per functions scares programmers into making changes. Why? Because we all know that if we change something inside one of those method, the ripples of change will make something else break. This fear can be neutralized by high code coverage of those big methods and/or by splitting them up.
Time for totally unscientific numbers. I think that complex code will require more double the time to make modifications to. Why? Well… let’s say that the developer will have to spend a considerate amount of times in the debugger instead of running tests. Tests for a (big) module should take less than 10-15 seconds to run (including the test runner initialization). Debugging the same module to verify a behaviour will take normally a minute or two. Rinse and repeat at least a dozen times and you find yourself at 1 minutes for running the tests and 12 minutes for debugging an application. This is just the beginning. If there is no tests, a huge and complex method will take literally take at least 10 minutes to understand (depend of context). A test “infected” code base will allow for quick failure verification without having to spend hours in the debugger. Calculate as much as you want but… as Robert C. Martin said:
The only way to go fast is to go well.
So are you saving time in your company or are you costing your company money? I think we can all earn something from writing clean code. Companies will save on maintenance cost, programmer will improve their craft and become better programmer that are proud of what they do.
I’ve been thinking about this for at least a week or two. In fact, it’s been since I started (and finished) reading the book “Clean Code” by Robert C. Martin. There is probably only two way to go.
This method is called refactoring and “cleaning” the code. This of course, you can’t truly know what code is bad without having a Static Analyser tool or programmers working on the code. The tool will allow you to spot piece of code that could bring bugs and/or be hard to work with. The problem, refactoring code or cleaning up code is really expensive on a business perspective. The trick is to fix it as you interact with the code. It is probably impossible to request time from your company to fix code that could cause bugs. If you ask your company to fix the code, you will probably receive this answer: “Why did you write it badly in the first place?”. Which brings us to the other way to improve the code quality.
If you don’t write the bad code in the first place, you won’t have to fix it! That sounds simple to an experienced programmer that improved his craft with years but rookies will definitely leave bad code behind. Eventually, you will have to encounter this bad code. So how do you avoid the big refactoring of mistakes (not just rookies)? I believe that training might be a way to go. When I only had 1 year of experience in software development, I was writing WAY too many bad code. I still do. Not that I don’t see it go through. Sometimes, things must be rushed, I don’t understand fully the problem and some small abstraction mistakes gets in. I write way less bad code then when I started. However, this bad code is not just magically disappearing. It’s stays there.
I think that training and/or mentoring might be the way to go. Mentoring might be hard to sell but training is definitely not that hard to sell. Most employees got an amount of money related to their name within a company that represent training expenses that can be spent on them. What I particularly recommend is some courses in Object-Oriented design or Advanced Object-Oriented Design. Hell, you might even consider an xDD course (and by xDD… I mean TDD, BDD, DDD, RDD, etc.). Any of those courses will improve your skill and bring you closer to identifying clean code from bad code. Other training that will form you specific framework (like ASP.NET MVC or Entity Framework) will only show you how to get things done with those framework. The latter can be learned on your own or through a good book.
So? What do you all thinks? Do you rather have a framework course or a “Clean Code” course?
I’ve always found that the best practices inside my field were not always respected. Doctors always wash their hands, architect follow all the rules to have a building that is safe for the people living/working inside it. However, with software, anyone can improvise himself “Software Architect” or “Software Developer” without having any problem to find a job. Most people in the .NET community will follow what is given to them by Microsoft. Be it SharePoint, Entity Framework, Linq To SQL, Visual Studio, or whatever. Sometimes, alternative is good because they offer you a different view on the state of things.
When I met Greg Young for the first time, it was in .NET Montreal Community meeting where he was doing a presentation on DDD. We took a beer together and talked about improving the level of those in Montreal. Improving the level of average developer in Montreal is a hell of a task. First, there is people like me, Greg and Eric De Carufel who are passionate with their craft and are not satisfied with the status quo. We believe in ALT.NET but are most of the time called “passionate programmer”. The people like me and Eric are the easy one to help. Then there is those that want to improve themselves but that doesn’t have time (life, family, house, etc.). They are not easy to attract and the best way to instruct them is to do it internally (official training or coworkers). Then there are those that don’t care about their craft. Those are of no interest to me.
When I took a beer with Greg Young, he talked about action on what would be needed to improve the level. That is the reason why I started (or at least… still trying) to start the ALT.NET Montreal Community. We started a month a ago. We were only 7 back then. It was small but friendly. Now, on June 25th, we will hold our second Coding Dojo of the ALT.NET Montreal Community.
What is important to remember when starting a community I think is, to start! So, if there is anyone from Montreal who wants to help us boot start a community… the ALT.NET Montreal Community, you are all welcome to our next Coding Dojo on June 25th.
