Dogma Driven Development

We really are an arrogant, opinionated bunch, aren’t we? We work in an industry where there aren’t any right answers. We pretend what we do is computer “science”. When in reality, its more art than science. It certainly isn’t engineering. Engineering suggests an underlying physics, mathematical models of how the world works. Is there a mathematical model of how to build software at scale? No. Do we understand the difference between what makes good software and bad software? No. Are there papers with published proofs of whether this idea or that idea has any observable difference on written software, as practised by companies the world over? No. It turns out this is a difficult field: software is weird stuff. And yet we work in an industry full of close-minded people, convinced that their way is The One True Way. It’s not science, its basically art. Our industry is dominated by fashion.

Which language we work in is fashion: should we use Ruby, or Node.js or maybe Clojure. Hey Go seems pretty cool. By which I mean “I read about it on the internet, and I’d quite like to put it on my CV so can I please f*** up your million pound project in a big experiment of whether I can figure out all the nuances of the language faster than the project can de-rail?”

If it’s not the language we’re using, its architectural patterns. The dogma attached to REST. Jesus H Christ. It’s just a bunch of HTTP requests, no need to get so picky! For a while it was SOA. Then that became the old legacy thing, so now it’s all micro-services, which are totally different. Definitely. I read it on the internet, it must be true.

Everyone has their opinions. Christ, we’ve got our opinions. Thousands of blogs and wankers on twitter telling you what they think about the world (exactly like this one) As if one person’s observations are useful for anything more than being able to replicate their past success, should you ever by mistake find yourself on their timeline from about six weeks ago.

For example: I wrote a post recently about pairing, and some fine specimen of internet based humanity felt the need to tell me that people who need to pair are an embarrassment to the profession, that we should find another line of work. Hahaha I know, don’t read the comments. Especially when it’s in reply to something you wrote. But seriously now, is it necessary to share your close minded ignorance with the world?

I shouldn’t get worked up about some asshat on the internet. But it’s not just some asshat on the internet. There are hundreds of thousands of these asshats with their closed minds and dogmatic views on the world. And not just asshats spouting off on the internet, but getting paid to build the software that increasingly runs all our lives. When will we admit that we have no idea what we’re doing. The only way to get better is to learn as many tools and techniques as we can and hopefully, along the way, we’ll learn when to apply which techniques and when not to.

For example, I’ve worked with some people that don’t get TDD. Ok, fine – some people just aren’t “test infected”. And a couple of guys that really would rather gut me and fry my liver for dinner than pair with me. Do I feel the need to evangelise to them as though I’ve just found God? No. Does it offend me that they don’t follow my religion? No. Do I feel the need to suicide bomb their project? No. Its your call. Its your funeral. When I have proof that my way is The One True Way and yours is a sham, you can damn well bet I’ll be force feeding it to you. But given that ain’t gonna happen: I think we’re all pretty safe. If you don’t wanna pair, you put your headphones on and disappear into your silent reverie. Those of us that like pairing will pair, those of us that don’t, won’t. I’m fine with that.

The trouble is, in this farcical echo chamber of an industry, where the lessons of 40 years ago still haven’t been learnt properly. Where we keep repeating the mistakes of 20 years ago. Of 10 years ago. Of 5 years ago. Of 2 years ago. Of last week. For Christ’s sake people, can we not just learn a little of what’s gone before? All we have is mindless opinion, presented as fact. Everyone’s out to flog you their new shiny products, or whatever bullshit service they’re offering this week. No, sorry, it’s all utter bollocks. We know less about building decent software now than we did 40 years ago. It’s just now we build a massive amount more of it. And it’s even more shit than it ever was. Only now, now we have those crazy bastards that otherwise would stand on street corners telling me that Jesus would save me if only I would let him; but now they’re selling me scrum master training or some other snake oil.

All of this is unfortunately entirely indistinguishable from reasoned debate, so for youngsters entering the industry they have no way to know that its just a bunch of wankers arguing which colour to paint this new square wheel they invented. Until after a few years they become as jaded and cynical as the rest of us and decide to take advantage of all the other dumb fools out there. They find their little niche, their little way of making the world a little bit worse but themselves a little bit richer. And so the cycle repeats. Fashion begets fashion. Opinion begets opinion.

There aren’t any right answers in creating software. I know what I’ve found works some of the time. I get paid to put into practice what I know. I hope you do, too. But we’ve all had a different set of experiences which means we often don’t agree on what works and what doesn’t. But this is all we have. The plural of anecdote is not data.

All we have is individual judgement, borne out of individual experience. There is no grand unified theory of Correct Software Development. The best we can hope to do is learn from each other and try as many different approaches as possible. Try and fail safely and often. The more techniques you’ve tried the better the chance you can find the right technique at the right time.

Call it craftsmanship if you like. Call it art if you like. But it certainly isn’t science. And I don’t know about you, but it’s a very long time since I saw any engineering round these parts.


15 thoughts on “Dogma Driven Development

  1. Matthias

    Slightly off topic, and not that my advice should be any value to anyone, but sounds like you should maybe change your job? There are companies that are making world a better place, as a side effect of useful software they create. I recall that feeling of “getting paid to put into practice what I know” from the places I’m happy I left.

    1. Funnily enough I actually really enjoy my job!! I’m lucky that I get to work with some really smart people on interesting projects. However, in past lives, I’ve come into contact with more than my fair share of dogma – which is what inspired this rant.

    2. Tom G

      Sorry, Matthias, but I really don’t see the relevance of your point to the DDD posting. I did not see any negativity in the post, except towards people that invent a “new wheel” is better, claim it is better and that everybody should use it – and don’t recognise that their wheel is just as elliptical as all the other “new wheels”.

      1. Matthias

        From my anecdotal experience dogmatic people are prevailing in places that are somehow isolated from external (real) world for some (random) reasons. It’s difficult to change such environment – or maybe it’s just me who never made it – that’s why I favour the ‘move on’ advice. Anyway, it’s good to read in comments that our precious author is doing well, and the things he writes about are not the ones killing him any more.

      1. Tom G

        Yes 😦 But then dzone is now little more than people’s logbook of “how I followed instructions and installed Frobnitz v2.4”.

  2. +1. The level of intolerance and ‘one size fits all’ is depressing.

    I wouldn’t say we know less about how to build software that we did 40 years ago though – we know much more about how to build software. The thing that has changed is the massive distance between the 0s and 1s that a computer deals with and the problem that the software is solving – that is what we don’t know how to build, solutions for bigger problems. Oh, and the fact that as an industry we tend towards the ‘kids in a sweetshop’ mentality.

    Also – please tone down the language, as a Christian I find it slightly offensive and it has the same overtone of hysteria that you are complaining about ;).

  3. The people going for their Masters and Ph.d in CS are changing the world by building on the current achievements and taking it one step further (in fact as far as I know a dissertation is required to contribute something new and significant to the field). While in college I used recently written research papers and dissertations of others throughout computer science academia as a starting point and built off of them. Even in college the dogma was rampant, though is much worse out of college in the traditional industry. I do my best to be open to new ideas. It is hard to deal with others when their idea of computer science is a bit close-minded, but shunning them can be just as bad, a kind of racism of its own. We need to embrace the open-minded and close-minded alike. Yin-Yang says we do best when we work together with others from all parts of the spectrum of ‘minded-ness’. A well oiled team is like a well oiled marriage, it takes sacrifice and and an understanding of the feelings behind the decisions people make that leads to the team working well together and being efficient. On my own I understand how the concept of ‘I need it finished yesterday’ and ‘by any means necessary’ undermines the principles and processes that will lead to more substantial improvements that come when we take time for test driven design and technical documentation and code reviews and building as much as we can off of others hard work (and ironically the extra effort will be what leads to greater overall cost savings). Linux is gaining traction especially in Europe, the next generation of developers have the built-in mindset of open source and working with others and taking the best version of a wheel and making it better instead of reinventing the wheel. Until they take over I think we can do well to make the best of what we have. As long as I work on a team with at least one other open-minded person I should be ok. Sure maybe I prefer a person who is both open-minded and a hard worker, but I would still choose a close-minded person who works hard over an open-minded person who slacks off.

    1. Wow, there’s a lot to reply to there!

      I know some great work is done in computer science research. Very little of it, unfortunately, has anything to do with what most commercial software developers do day-to-day. This doesn’t make the research any less valuable; I just wish we could find a way to improve the way the millions of dogmatic, fashionista developers are going about their daily lives.

      I’m also not sure I see any evidence that the next generation of developers are any less vulnerable to dogma. I think our industry’s obsession with the new & shiny continues apace – this is purely fashion and dogma, there is no science behind it.

      Interesting question on open-minded vs hard-worker. Is someone working hard against the rest of the team actually productive?

      1. The research that led to the Havoc physics engine was available for years before the Havok engine came out. The research into linear algebra and computer graphics led to 3d graphics acceleration hardware, and eventually hardware pixel shaders. The best research does end up used in our daily lives as developers and tech consumers, but we have an opportunity to embrace it much sooner than the 5 or 10 years it takes to naturally be integrated. Such use helps shape early adoption and may be a catalyst for natural integration.

        In the Linux development world, it is necessarily more open minded. The entire OS is open source. A software developer who wants to be recognized publishes their work as open source, which allows anyone to rebuild binaries for their specific hardware platform. For someone who is porting Linux to a brand new hardware platform that they are creating, they necessarily have to work with the Linux and open source community. The Windows development community tends to be close-minded, of course the dogma is still out there. But Linux is growing in popularity and tends to be a more open-minded community.

        A close-minded person isn’t working against the rest of the team. A superstar who is full of himself is the guy that is working hard against the rest of the team, and it isn’t productive. Having an inflated ego is not the same as being close-minded – a close-minded individual still has the potential to consider that each member of the team has an equal worth. Refusing to work with someone or trying to get them fired because they are close-minded is also less productive than finding a way to relate to them and work with them. Especially if I hypothetically have a boss that is close-minded, I’m not trying to quit or get fired, I am better off understanding my boss’ reasoning to a point that I can pitch ideas to them with the right spin that sides with their internal reasoning. The best PM helps the members of the team to relate to each other and to connect, it is his job to find a way around the dogma, rather than firing the people that are harder to work with. Though if it is really that bad then they will eventually get fired. Unless you work in a place that is 100% dogma, in which case maybe find a different job.

  4. Lupin, l'incorreggibile Lupin

    LOL @ “Is there a mathematical model of how to build software at scale? No.”

    Try turning off Twitter and cracking a book some time.

    1. Got any good suggestions? Seriously – I’d love to see some real work done in this area. I’ve read some pretty interesting studies, but nothing that I would describe as a universal law of building software at scale. Nothing that finally identifies the one correct way to staff, design and build an arbitrarily complex software system. Nothing even close.

      Building software is a social activity, it’s very difficult to ultimately prove anything with universal applicability.

  5. Love it.

    I began working in software in the late 1970s and by the time I retired in 2005 what had changed was the shear amount of software being written and the large number of tools available. Qualitatively, there wasn’t much improvement. that I could see. In some respects SW development is worse now than ever. The prevalent attitude seems to be “write it and get it out the door, we’ll patch it later”.

    Where is the concern for users. More attention seems to be paid to changing the user interface than to adding/improving functionality. Upgrades often break the software. Hasn’t anyone heard of regression testing.

    I don’t care what language or tools are used. If you can’t get a clean specification written, produce code to meet that specification and then test the hell out of it, your going to produce crap. Also what often is overlooked is that not only should you make sure the software does what it is suppose to do, but that it does NOT do things it is NOT suppose to do.

    Human’s do not think like computers. It is hard work to translate requirements into code that runs on a machine having an alien intelligence. If we keep that in mind, with a little humility and teamwork, we just might produce some half decent software.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s