Last night saw an impressive attendance at January's BCS event, on Test Driven and Behaviour Driven Development. This is possibly an indication of what people want from their BCSin terms of subject and engagement with the content.
The talk by Zakir Hoosen, from Fuzzelogic Solutions was very interesting, and proved to introduce the principles behind an increasingly widespread method of development to those who would otherwise not have had the opportunity to see it being used. This included myself. The concept of "Test Driven Development" was alien to my previous job, not because I didn't want to write good code, but because the organisation failed to engender the opportunity to spend time on code improvement processes. After seeing that while most people in the room were developers, only 5 or so actually used these methodologies, it made me feel slightly better that while my career had suffered as a result of the rut I had found myself I certainly wasn't on my own. In the "real world", it isn't always possible to find the time to look into design and test methodologies, let alone have the skills and time to implement them and surrounding processes.
Testing aside, a couple of interesting design principles came out of the discussion (and it was a discussion), which align with my own thoughts around best practice:
- Keep inheritance to a minimum, use Interfaces extensively. Whenever I expose any form of object (via an API or otherwise) to a public facing consumer, I always use an Interface. Not only does it provide benefits of abstraction, but it also helps in inversion of control, dependency injection, etc. It's also a great way to clarify in your own mind the true purpose of a particular class. All classes have their helper methods, but those implementing an interface are seen to be the "meat" of the class.
- Name your classes around the pattern that it is using. As mentioned above, I use Interfaces extensively, and you can't instantiate an interface (as such), so this is a great opportunity to implement Factory patterns and dependency injection. If you have a class that creates instances of an Interface, call it "Factory". For example, in one project I am working on, I have a ClientFactory, which produces IClients. It does what it says on the tin. Other patterns which naturally lend themselves well to forming part of the class name are Mediation ("ClientSearchMediator" for managing searching for Clients), Wrapping ("OutlookWrapper" for wrapping a component you can't necassarily change, for example, Microsoft Outlook) and Proxy (WCFProxy for when a class simply proxies calls between two objects or services, which may or may not include some form of translation). Unfortunately, some of the principles adopted within the .NET Framework and Visual Studio's automatic code generation don't always lend themselves to this style of naming, in particular, instead of having a ButtonObserver for the Observer pattern, you tend to get a button_Click method within your presentation class (be it a Windows Form or an ASP.NET Web Form).
The content of the talk was clearly welcomed by the group, much of whom were developers. As a developer, on an island, any opportunity I can get to see techniques I might not have been exposed to is welcome. Owen asked if we would like to see not only more sessions of this type, but also small "code camp" sessions where a developers collect and work around a topic, hammering out code together. This is a great idea. As many schemes in the US, whereby programmers congregate from all over the country to attend intensive code-athons, this has many advantages. As an island resident, I get to meet my peers in other businesses, learn about methodologies I haven't necessarily been involved in and be able to implement with guidance of someone who has already traversed the learning curve. While I was particularly pleased that my platform of choice (and language, I would sit there cringing if it was in VB.NET rather than C#!) was being used as the basis of the presentation of test/behaviour driven design techniques, this might not be so easy if we all "jump in" with our own preferences. We all have our own language, platform and coding conventions and standards so this may present a challenge, but also an opportunity to improve our platforms/coding conventions in the workplace as a result of seeing how others do it.
While this technical content was a welcome change, I do not want to see a 100% technical syllabus. I would still like to see "softer" subjects, such as the previous talks we have had on Search Engine Optimisation, social knowledge using Wikis, etc. This presents an opportunity to maybe create an additional technical channel to complement the softer content and encourage more technical professionals to attend, which can only be a good thing for the BCS as not only do members increase, but also professionalism is shared amongst peers which is what the BCS is all about.