More and more I see both in job request, and in general overall conversations – that MS (or probably any technology) developers tend to get really wrapped around what technology they are using vs. understanding the core software development/craftsmanship.
The common thing I will hear is ‘do you know Sharepoint’, or ‘do you know MVC’, ‘do you know Unity’, etc… Quite honestly, I think any developer who has a firm grasp of software principles and patterns can easily pick up and learn these technologies.
On the flip side, what I tend to notice though is that these solutions are typically cobbled together and not really designed properly. This leads to a tangled code mess, lack of good testing, etc… and the projects quickly become unwieldy.
I’ve seen this both in a few webform projects as well as a silverlight project. The concentration was on ‘using ajax’ or ‘knowing how to use a GridView’ – and meanwhile the entire application was very poorly constructed – with 1000 line code behind files and data access inside the code behind. There wasn’t an SRP or cohesion in the code base. The result was buggy and hard to maintain code. Performance issues crept in from every side. Whether or not you use webforms or not, there is such a thing as proper construction and design patterns. Within a few moments of inspecting the code, I saw three or four different signs of how some composition and layering would help.
The other example was with Silverlight. The core focus was on ‘RIA Services’ and ‘Telerik’ and ‘MEF’. All very important tools – and yet, the lack of layering, no DTO, etc… was a cause of problems. One database change would wreck the entire app as this code generated entities were used all throughout the code. This was done to be ‘RAD’ and yet by not properly separating out these features it caused it to be brittle and difficult to manage. Checking in a database change caused build errors across the entire app.
The one positive was the use of MVVM. That said, I think knowing MVVM, composition, design patterns, loose coupling, how to write tests, etc… are much better things to be grasping than ‘do you know Sharepoint’ or ‘Silverlight’. Understanding source control systems – like merging, branching, etc… are far more useful than just ‘knowing git’ or ‘knowing TFS’.
I encourage developers to disassociate themselves from being ‘specialists’ in a particular technology and really understand software craftsmanship. Not just ‘knowing’ what SOLID is – but applying something like SOLID even when working with whatever technology or tool your using. Not all tools are bad, I might add, some tools help at least spot issues and make developers think – ie. FXCop – I’ve been on a product using it, and it can be very particular about the syntax and code use. Certainly it might slow down a sloppy developer, yet it means the rest of the team is working with a code base that has checks and balances. The main premise is that we are building code with craftsmanship at it’s core, regardless of what web or desktop technology was chosen to be used.
Quite honestly, the best possible development environment is one where you have some senior staff members who can do code reviews, discuss proper design, etc… Projects that attempt to cut corners and not have these valuable resources in place, end up really shooting themselves in the foot. I hear sometimes the same old adage, ‘well we can’t afford to spend time writing tests’ – and quite honestly, I think the answer is ‘you can’t afford NOT to be writing tests’. Tests uncover design flaws and bugs – they are proactive – they provide a place to review how the code works, etc…
I’ll last just suggest that perhaps the next book you pick up might be something like ‘Clean Code’ by Bob Martin vs. some book on ‘Silverlight’, or whatever the latest greatest fad is. The principle and concepts of understanding how to write good clean code will take you much further than knowing just a particular technology. If you want to be a specialist, specialize in being a software craftsman. Lastly, be careful wrapping your head in a particular technology and throwing out your good sense of building software. ie. many of these API’s are not designed to be just exposed and used directly. Encapsulate what varies, maintain SRP, look for flaws in the design that later will lead to a more cohesive and manageable code base for you and your team.