The Guild of Incompetent Programmers (GIP) is a group of programmers who are doing it wrong. Even though the GIP as a name, entity or organization is not very well known, most people have encountered one of its members or at least work produced by one of its members. There are a lot of sister organizations like the Guild of Incompetent Designers and the Guild of Database Bullies but for now though, I am just going to talk about the GIP.

The members of the GIP can be summarized with the following qualities:

• big design up front (BDUF)
• can only do it imperatively and love global state
• do not use the right tool for the job
• think OOP is all about classes
• solution over problem
• are clueless about our field
• shy away from learning
• cannot use anything but the shredder

The GIP as a whole is a group of developers and programmers who enjoy in reinventing the wheel over and over for every problem they face. It might be any combination of sheer obliviousness and/or an angst for new things and threading on unfamiliar territory. Or it might be something else altogether. Anyway, they are doing it wrong and because of this they cause themselves and the rest of the world a lot of problems in the process.

Big Design Until Fail

Big Design Up Front (BDUF) is a software fail of global proportions. This probably means that global economy is involved as well so it’s not a particularly small problem. What amazes me is that I still see cool young people trying to do BDUF when they are fresh out of college (or still learning) but this probably means that a large part of the teaching staff are members of the GIP too. Another explanation might be that these people are so afraid of the actual typing in of code that they try to create a sort of a safety net: if the actual coding fails they will at least have the big design to show for their efforts.

BDUF fails because it is part of some bureaucratic dance that is performed to make one or more people that have absolutely nothing to do with actual development happy. Another way of saying this is that BDUF is just a waste of time. The actual big design is unfortunately useless once you’re ready to start coding. Although, to be fair, on rare occasions it will hold until the first customer review.

To be clear: there is absolutely nothing wrong with doing design or trying to get to know a problem domain with some other means than code. Things just get ugly when solutions are designed with some other means than code. It’s comparable to the idea of building and assembling every component of the metaphorical bridge (on site) 1:1 before building the actual bridge. No engineer in his right mind would even consider this.

Important!

Note that I’m not comparing the actual craft to building a bridge. This would be like saying that writing a book is like building a bridge. Although it would be an interesting philosophical discussion to investigate how far these do align it think most people would agree that writing a book is somewhat like writing a song but nothing like how we actually construct a building or distribute the song. For now though, I am going to leave the rabbit hole of software development metaphors for later and continue with the rant.

The Imperative Way

It is not that everybody is doing it. Imperative programming is sometimes required, frequently handy and also sometimes the clearest way to express a solution. Imperative programming in itself is not necessarily bad or wrong but the unwillingness of some people to look into these other paradigms is striking and almost offending. Often, this is exactly the same group of people that just love the global state container, write their stuff in 600+ line of code chunks and feel strangely comfortable when there is a list of 100+ global variable declarations on top of their module, class or whatever top level their using. Unfortunately though, these people are also completely unaware of the impact and consequences that making heavy use of global mutable state (and also local mutable state) may have:

• threading issues (requires locking)
• hard to trace bugs (requires debugging and stepping)
• hard to (automatically) test
• poor orthogonality
• readability most likely suffers

Threading issues and hard to trace bugs make the code hard to scale and maintain. Setting up the code base in such a way that lots of mutable state is involved usually implies that testing stuff in isolation quickly becomes difficult or at least very annoying. This in turn often leads to poor orthogonality and an overall poor design which will quickly evolve to a monolithic piece of code that no sane person would like to work on. On top op that, it will also have lot of broken windows all over the place. Now imagine a gigantic pile of shit, which is somewhat the same. Would you like to work on that?

A Rock and a Stick

A lot of this is in a separate post but as it also has to do with the unwillingness to learn and the unawareness of those that came before us (history of our field) a few things can still be said. One of the things that I have trouble comprehending is why someone would not be interested in learning about technology, concepts and ideas that are relevant to his or her field of experience. If you can tell me your ideas about games or movies, why can you not tell me the equivalent about the field of your profession? This is the knowledge and experience gathered throughout the times that actually enables us to make our living. More and more of that knowledge becomes available everyday and is should be readily accessible for everyone (and that means everyone).

Nobody can be expected to know everything but you should be able to formulate what interests you in your field of profession. Who are your heroes? What are you experimenting with? Who do you admire? What magazines or blogs do you read or who’s feeds are you subscribed to? (feeds? what’s a feed? you’re a feed!) Most of the people have not even considered these questions for themselves so there is no reason why they would have an answer. So with a blank stare and thoughts about food or females they continue on their merry way. Rock and stick at the ready.

OOP: Look Ma – No Classes!

Once upon a time, I thought I could handle the big stuff. I was a rock and stick programmer who mastered the rock as well as the stick. But, I was insecure. Until now, on a small scale, my simple creations turned out reasonable well. Yet, how do these really big programs and systems work. How can they work? How can someone develop and maintain them with a team of people? How can some actually reason about them without resorting to a bunch of code?

Then, I found a job pretty much in my technological hot spot of that time and proudly went out with my polished rock and stick for an interview. I was excited to get the job but quickly found that the simple rock and stick that my education thought me to use so well were not very useful for constructing solutions to real-life problems. Also, I found that the guidelines on how to construct blueprints for the things I was to build were not really applicable. I really tried and my first project went actually pretty well but that was only because I was the only one working on that with full control over everything that went on with it. Doing a little bit of work after-hours was an easy way to pull stuff right back on track and way in front of the schedule. Even if it meant sucking up bad decisions made a few weeks earlier.

So, what does all this stuff have to do with Object Oriented Programming? Well, it was exactly during that time that I found there was something lacking with the whole concept. Of course, I was thought everything about class, interface, override, static, private, virtual and a whole host of other useless stuff and also all the shit about polymorphism and that other important concept that I always forget about (just call it polyotherfuckism, it does not matter). I knew all that religious shit by the letter but eventually found out that none of it really matters. It’s all just shit. Forget, all those fucking keywords. You know what OOP stands for right? Object Oriented Programming. That means programming with fucking objects. Who the fuck would have thought that huh?

For a while I’ve been trying to convince my colleagues that OOP is about objects rather than classes but somehow that shit does not sink in very well. They always come up with contrived class hierarchies involving animals or vehicles but unfortunately not one of my projects involved those kinds of entities or such a perfect mapping from example to real-life. Strangely enough, nobody ever turns up with the human analogy even though that one makes the most sense. It just proves that these people do not understand the fundamentals principle to OOP:

Hide mutable state in objects (and everything is an object)

You see, that is not too hard. Just hide the fucking state. Make sure that nobody is mutilating something that is not his or her own. Actually, the part in brackets is the real definition but unfortunately that is too vague for the people who are the target of this rant. To them, I can offer the following consideration to make it extra clear. How would you feel if I asked you: “can I chew on your fingers for a while please?”

A lot of object oriented programming languages do not even have classes to begin with. Instead, you just define an object globally that has the properties for a large group of other objects and clone that mother fucker for each new instance that is required in a local scope. It is much more to the how nature works which has mothers (mutual parents) and local variations (trapped in a scope like a valley, mountain top or cave. These are prototype based languages. Sometimes though, it is possible to affect all clones of some object even after they have been instantiated (like in current JavaScript) but while quite powerful, it allows people to easily construct their favorite class based inheritance adapters on top of the language thereby foregoing the much more powerful and arguably more natural prototyping. This is like adding Asian treats to Caucasian Europeans after they are born. A powerful, strange and dangerous concept indeed.

Object oriented programming is not about classes. It is about objects and hiding mutable state within objects to send around as packages to some other part of the system. Objects should not go about mutilating other objects. Instead, they should offer a set of operations that either are safe to call every time you feel like it but ideally offer some kind of mutated version of the truth that cannot be changed but can be used to create a new future truth. Classes have nothing to do with OOP and everything to do with code re-use. Prototyping is king and interfaces rule. Favor composition over inheritance and for the love of God, please forget class hierarchies.

Don’t tell me what to do!

If you want something, say what you want. Do not tell me how to make it or you will regret it later and try to blame it on me. It’s that easy. To stick in another fucking analogy: if my car makes a stupid noise I go the garage and say: “get rid of that fucking noise.” I do not say: “change this part and that part and maybe that part and then check that and then also that that motherfucking other piece of shit that’s supposed to be working in tandem with that other piece of crap…”.

I do not tell them what to do. I tell them what the outcome should be and let them figure out the path to arrive there. And this shit is true not just for people, it also holds up when your coding. Treat objects like people. Make them responsible for their tasks and depend on them to do the right thing. You’re the orchestrator making stuff dance or perform to your will. Don’t try to be the dictator.

If you are someone in charge of managing developers please know that we are only here to please you. But please tell me what you want, not how want to have it done. Otherwise, hire some monkeys.