I attended my first BTVWAG meeting and was very impressed with the turn out. I didn’t count the attendees but I expect there were around 30. I was especially surprised to see no one I recognized from the Vermont.NET User Group. In fairness – the .NET meeting was Monday so two meetings in 3 days is a bit much – especially during the holidays – but it was well worth it.
Rik Dryfoos gave a great talk on Software Craftsmanship. Though the talk was aimed at management / product owners (ultimately getting buyin), there was a little something for everyone, and ultimately getting the coders on management on the same page regarding code quality is greatly needed – and now we have a term for it – Software Craftsmanship. Why do we need a term for it – whats wrong with Code Quality? In short, in my opinion, its because writing great code is more of a craft, than an engineering discipline. It takes a new term to move heads.
If you weren’t able to attend – take a few minutes and race through the slides available here.
Now for my own notes from the meeting:
Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin was added to my Wish List (hopefully that means someday I will find the time to read it)
The term YAGNI was mentioned briefly (You ain’t gonna need it) and I wasn’t familiar with it, so a quick google search led me to wiki where I realized that it is the idea that you should wait to do that really cool thing until that really cool thing is needed. I have a poster on my wall that communicates this same message which can be found on slide 22 here (I added a screenshot below).
Code smells was also brought up with a great link here. I hope to eventually find some time to automate the measuring of these code smells. I know fxcop does a lot of them but wouldn’t it be great if you could measure the total stench of your code?! We have to be careful though – measuring gets us a little too close to engineering..
One smell that was new to me was Cyclomatic Complexity which in my own words – measures the the number of computational branches your code can take. In other words if there are no If statements than the complexity has only one path and a Cyclomatic Complexity of 1. I find this smell particularly interesting, because I could use it ask myself, is this module complex for a good reason or did it just turn out complex.
The Software Craftmanship Manifesto was introduced and on its old style paper layout it feels something like joining a brotherhood
During the presentation there was an analogy to a blacksmith that was made – which is quite fitting with the old style paper above… One part of this analogy that really hit home for me was that a manager can’t mentor a blacksmith, it takes a blacksmith to mentor a blacksmith. I personally have experienced this level of micromanagement and it simply does not work. You can’t tell the blacksmith how long its going to take to mold the metal – he has to tell you.
On one of the slides, it was mentioned that Rik would give his company a Red (not so good) for Pair Programming, which isn’t much of a surprise as most companies struggle to implement Pair Programming. I asked him what it would take to be Yellow or Green. I was surprised by his answer. He said that for Green, every piece of code would need to be Pair Programmed. I respect and appreciate his answer but personally find that to be excessive “craftsmanship.” I have done Pair Programming and can vouch for the value. We were able to come up with a much better design than either of us would have come up with on our own, and we both had intimate knowledge about how and why it was designed the way it was that can’t be compared to trying to “show” the how and why afterwards. But, then we went our separate ways and worked on the less challenging parts of the design in parallel. I can’t imagine the boredom if I were forced to Pair Program an entire application. To go back to the blacksmith example, do you tell the blacksmith that it takes two master blacksmiths to heat up the metal? We might want two when it comes time to shape the metal or some other intricate part of the process, but not the whole process.
Towards the end of the talk during some questions – the importance of the ability to say No was brought up. We need to ensure that our programmers understand the value of speaking up and are enabled to say no. For too long, we have been the blacksmiths that return a piece of metal that soon breaks, because we are never listened to when we say – the fire won’t get hot enough or the metal won’t cool long enough.
I appreciated the talk and especially thank Rik for his time and contributions to a better community of software professionals.
No comments:
Post a Comment