A Frustrated Developer is a Passionate Developer

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.

A Frustrated Developer is a Passionate Developer

2 thoughts on “A Frustrated Developer is a Passionate Developer

  1. Chris says:

    While I agree with the basic premise of being frustrated over bad practices, you are really being kind of harsh in a few aspects. For instance, you think “poor programmers” use stored procedures. I’ve worked in places where I would kill to have coworkers use stored procedures, instead of the horrendous mess of in-line, parameterless SQL queries I was forced to clean up. There’s nothing wrong with SPs when they are used and organized correctly. They provide an extra layer of security over inline, they don’t require a full redeploy of an application to change them and in my opinion promote a nice layered approach to coding. Why cloud up your codebase with a bunch of CRUD statements? But I digess, as I know this is a hot area of disagreement between developers. I would also disagree that business logic has “no place” on the database. I would agree it should be ‘scarecely’ used, but sometimes it is your last line of defense against a bad programmer. A strong database design with good “business constraints” prevents the knucklehead new guy from writing some C# script that screws everything up.

    Other than that, this was an enjoying read. I can certainly relate to your frustrations, but I guess that’s why we get the bucks :)

    1. Thanks for the well reasoned reply, Chris. I realise how my post comes across but in my defence I’ve just come out of a particularly bad experience which had my emotions running high and in some ways this is an implicit dig at some people who I’ve worked with and companies I’ve worked for who would never recognise themselves anyway. I should probably learn to cool down before bashing the keyboard in anger.

      It’s not so much that poor programmers use stored procedures, it’s more that to them the stored proc is their hammer. It’s all they know and they use it all the time, ORMs or NoSql solutions not even considered. Same goes for architecture, that default N-tier layered application is used everywhere. Try and tell some of them about DDD and exploring the behaviour in the domain and they look at you with glazed eyes. It’s CRUD all the way for them. If it’s appropriate, fine I have no problem with CRUD, it has its place. I just want to raise the bar so that more people are aware of things like DDD and CQRS so that they focus more on behaviour and less on data but out in the real world it’s incredibly hard to push those ideas on people who don’t want to know and I’d say that’s the majority.

      I realise all these topics are opinions and as you say cause deep divisions between developers. My frustrations are a direct result of my own biases and expectations of others because I want them to see benefits that I’ve seen from these other approaches. Anyway, thanks for the comment, it’s always good to hear counter arguments and alternative points of view such as yours as it reminds me that not everything is black and white.

      Except for the stored proc argument of course, can’t stand ‘em! ;-)

Comments are closed.