Robert Martin gave a very entertaining keynote this morning. He basically spoke about defining our profession and what it means to be a software professional. As an industry we've traditionally been all over the map with each developer did what he thought best in a given situation and he tried to address some of the aspects we as an industry need to work with to reach a higher maturity level.
So how do we define professionalism? Robert Martin's idea of professionalism boils down to a shared mindset and a set of techniques. The mindset part of it is basically what the agile manifesto sets forth with the individual being responsible and generally behaving like "the good citizen". He elaborated on this by giving a couple of examples: If you write code try and leave the code base just a bit prettier than you found it. This resonated especially well for me because I inherited a large code base a couple of years back and actually adopted that very mindset. The result of this is that the code base is in much better shape than when I got back then. Furthermore he mentioned that the mindset you want developers to adopt is a that of "zero defects". Of course this is a utopian goal but if you strive for perfection you're sure to create a better product than you'd have done if you from the get go start out with a "shit happens" mindset :)
Another of his points that resonated with me is that of short iterations and no big redesigns. If you have a big mess in your system don't go down the road of a total redesign, chances are that the specs for the new system will change too rapidly making the new system obsolete before it's done. Instead try to tackle the mess one step at a time, much like the "leave the code base in better shape"-rule. This fits quite well with the idea of refactoring and as such is something I not only think is a good idea but something I've seen work in the trenches. Again this is not something which is set in stone as you will experience situations where a complete system redesign is not only appropriate but necessary; like for example when you're moving from one platform to another which is fundamentally incompatible with the other. Even in this case you could argue that technologies like web services can indeed enable an iterative approach to porting the system. But that's another story entirely :)
Test driven development is another topic he dwelled on for quite some time and with good reason too. I'm coming to believe that TDD is going to be an essential part of the modern developer's skill set and as such we need to start thinking about architectural support and guidance on it. With TDD as a natural part of development we simply put ourselves in a much better position to support our customers in the future. How many times have you experienced that development ground to a halt due to complexity, not necessarily business complexity, but complexity imposed by the fact that the system has become too much of a mess for you to be able to gauge the risks of adding a new feature, much less comfortably test it for release? With TDD this because a non-issue because you know that the system is passing your tests at all times. Thus you can actually achieve the "!refactor mercilessly" approach to software development that Martin Fowler et al advocates.
Finally apprenticeship is a topic which rung true with me. The premise of this topic was the fact the newly educated people simply don't possess the skill set to participate in a software development process right out of school. Therefore Robert Martin proposed a notion of apprenticeship for newly educated people getting hired into a software development organization. It's an area I've done a little bit of dabbling in but I've never actually gotten a completely fresh guy right out of college, my work focused more on getting people with experience up to speed in areas which they were lacking.
Robert Martin is a very skilled presenter who managed to keep the crowd entertained. His style of presenting is very active which makes it even more engaging. The keynote certainly bodes well for the rest of the conference.
The opinions expressed herein are my own personal opinions and do not represent
my employer's view in any way.