Once in a while I have to get things off my chest. This is one of those times. Feel free to move on.
I have a long held belief that the more passionate you are as a developer about your craft the more likely you are to get frustrated about the constraints that you have to work with within the work place. Your job as a developer is to solve problems that are important to your employer. If you’re passionate, and care about what you do, you desperately want to provide that elegant solution that can mean the difference between a mediocre or awesome application. Sometimes it’s not even about the elegant solution, sometimes you just want to do something simple but you have to jump through hoops that are there because of prior sub-optimal decisions that are now embedded so deep into the business that they are unlikely to ever be overcome.
Often we have to integrate with existing, poorly implemented systems which usually means we can’t help but end up adding yet one more mediocre application to the existing suite. I see this most often in enterprise development where the business often bases their whole I.T. vision around the single, central database, a common but seriously flawed decision which in the long term only causes pain for all concerned. The problem as I see it is that the business gets confused as to what it is that is truly important to them. What they should care about is the data, not the database. The database is important, but it’s only one implementation detail, and when you talk about databases with the business they generally only know of one way to skin that particular cat and that is to use a SQL database. If you’re a .Net shop then it’s likely to be SQL Server. The problem is not SQL Server per se but how it gets (ab)used. My number one pet peeve is business logic. It has no place in the database. None. There’s a reason why the Q in SQL stands for Query and it has nothing to do with business rules. The only people likely to benefit from you writing the best part of your application in a SET based language is the database vendor because now you as a business are locked in for life. Happy days for them, but not so much for you as a developer. I’d have less to complain about if performance was acceptable and didn’t make me pine for alternative solutions, and truth be told, there’s no reason why a properly designed and implemented database shouldn’t perform acceptably but again the reality for me through first hand experience is that these things are not done anywhere near properly and performance is often excruciatingly bad. It makes me wonder who implemented them and whose systems are they being paid to screw over now? As more applications get built, all using that one central database, contention increases and performance degrades. It get’s harder to move away from that approach because all your apps need access to that data and it all lives in one place. It becomes the default architecture.
Constraints aren’t always technical of course, they’re often about people too. I see developers who are content to work with such systems and shrug them off as normal. Often they don’t even recognise the problems they’re mired in. They tend to come from a traditional client-server mindset, think the Enterprise Library is state of the art, love stored procedures, write loads of “Manager” classes, and think they know DDD because they use the Repository pattern. Meanwhile, they keep on doing more damage while the business thinks they’re doing great work. If the business shouldn’t care about the database, they most certainly should care about the developers they employ. Good developers want to make a difference. Mediocre developers are happy to coast. Good developers help raise the bar whilst poor ones drag us all down. What I’ve noticed is that the one thing you can be sure separates the good from the bad is passion and to me passion is a pre-requisite to quality work. In fact, I believe that a passionate developer who has less technical skills is worth more than the experienced but lifeless mediocre developer because eventually his passion will lead him to greater technical excellence through sheer determination to be the best that he can be. If you’re not passionate, you’ve stopped progressing because you no longer really care. Good passionate developers still need tools to help them achieve their best work though and it’s unfortunate that sometimes businesses are reluctant to buy those tools. In the long run the right tools can save them money, improve the quality of their software assets or help to reduce their time to market. Give a good developer the tools he requires to do his job and you’ll have a happy developer and consequently, better software.
These things, in case you hadn’t guessed, frustrate me greatly. Poor systems, poor developers, poor business decisions. None of which are conducive to great results. We can change poor systems but not with poor developers. The state of the software industry is such that I don’t think it will ever be labelled a profession. There are just too many “cowboy builders” in the real world doing their worst, oblivious to their own inadequacies, that the passionate devs, the ones who eat, sleep, and breathe code, the ones who spend all their waking time reading and learning, will ever be able to overcome. To the business we’re all just developers. They don’t have the technical nous to differentiate between who’s good and who’s bad so they delegate to the tech lead to make that decision but what happens when the tech lead is worse than the candidate? I could tell you as I’ve just recently witnessed first hand this very situation and as result I saw some of the most horrendous systems and code bases I’m ever likely to see. It wasn’t pretty and that business is suffering hugely as a result. Trouble is, they’re still employing the very same people who got them into that mess in the first place, and to top it off they’ve just employed an Enterprise Architect. Good luck with that one!
Yes, I’m frustrated but that’s because I care. I’m incredibly passionate about what I do. I love to cut code and I always make an effort to write the best code that I can. If somebody can show me a better way, great! I’ll take it onboard and try it for myself. I may not be the best and I certainly don’t know it all but I do strive to be the best that I can be. I want to develop great software so I learn about great architectures because I believe it will help me. I read books, and blogs, and write spike after spike trying out new ideas because I believe I’ll get better at what I do. Unless all developers feel the same way though, we’re never going to be able to collectively raise the bar and that’s the most frustrating thing of all.