6 – Hacking away in Programmer Anarchy, motherfucker.

#begin

Writing the previous blogs about agile got me thinking about how I would handle things personally. What my preference for a software project management and development methodology would be, if it were up to me. This is going to be a fun blog to write and probably a rather controversial one, just keep in mind, these are just my opinions.

Introduce a little Anarchy, and everything becomes chaos better!

I immediately remembered a conference talk from GOTO 2014 by Fred George named Implementing Programmer Anarchy. In this talk he explains some of the problems with agile. He says that programmers often feel like drones, being controlled by the customers, product owners and Scrum Masters. They are just robots, picking up ticket, after ticket, after ticket… and as a result they are disconnected from the business domain. This nicely relates back to a previous blog I wrote about the Bills of rights which describes the rights everyone on the project aught to have and is entitled to.

He then goes on explaining that part of this problem lies in the fact that, in Agile, everything revolves around “user stories” or “tasks”.  These stories or tasks are on such low level of detail, that anyone trying to manage them, is doomed to end up micro-managing everything. This is not what you want of course. We want to be able to trust the experts, in this case the developers, to handle this micro-management themselves.  They need to be able to communicate on a higher level of detail. When we look at user stories or tasks, they are often part of some greater feature, so communication on the feature level is perfect. Now, I do recognize that you must be able to trust your developers to manage these features from front to end.

To make the developers be more responsible for the work they do, he explains, we need to cut some roles from the project. Mr. George says that the developer and customer roles are of course here to stay but roles like: Project manager, Business analyst (BA), Quality assurance(QA), Scrum Master/”manager of programmers” might be obsolete. He starts with saying, we do not want “managers of programmers” anymore, period. Personally I have to agree with him, I’ll get back to this later in this blog. Then he explains that there is no place for QA as well. He makes the case that historically QA were not programmers, QA did not really need to know how to program but in this current day and age QA often need tools like Selenium or Cucumber for testing. This also requires them to understand the software architecture. So essentially, they now need to know how to program and they need to understand the architecture of the system, this sounds a lot like developers. So he says, all QA people, are now programmers as well. To handle the issues QA would normally do, we need to shift our attention from acceptance testing to active monitoring. Acceptance testing is often a one-shot-thing you do when deploying, but modern live systems have (cloud) dependencies all over the place, so an active monitoring approach is more fitting.

Next he talks about how we do not need Business Analysts anymore; a BA is just a middle man where programmers can ask questions from, the BA then goes on and ask the same question to the customer and then gets back with the answer to the programmers. So why do we need this BA? Well BA’s will tell you that the business domain is far too complex for programmers to understand, really..? Shall I explain the concept of a monad to you? Or how about model checking, or even better Q-bits and quantum computing or deep learning? Developers are perfectly capable of handling complex problems and understand the business domain, just explain it… They might also tell you that programmers are not able to talk and communicate very well. Yeah, this might have been true back in the early days of computing. But now, the “stereotype programmer” no longer exists. Most programmers are very good communicators, if you give them a chance to talk.

He then talks about how mangers are not necessary for a project either and refers back to Kent Beck’s book on eXtreme Programming where there is also no mention of a role called manager. In original XP there was the role of a clerk that essentially just keeps track of user stories. Then, the manager role can be broken down into different attributes like; Leadership, being the lead (dev) for a certain project. An Ambassador role which purpose is to act in the group’s interests but never makes decisions for the team. He just promotes the team and the project. And there is the coaching/mentoring role we know for SCRUM. Lastly, there is the concierge role that can act as some concierge, some guy, who works for the team, not the other way around. If all these roles are fulfilled by members of the team, you do not need a manager.

Some anecdotes are told and Mr. George explains how the anarchy movement made a lot of sense, and money, in these examples. I encourage you to watch the presentation yourself to find out exactly what they are.

He finishes his talk with some detailed information about what roles and positions remain. He says, that anyone entering the company starts of as an apprentice programmer for a duration of 2 to 6 months. During this time you need to prove yourself and you will be come a journeyman, if not, you should consider another career. Then, after about 2 years, or more, most likely, never.. you will transcend to a master title. Most people will never reach this, since they take a different career path like becoming some manager somewhere else, or shifting more into software architecture instead of staying in the programming game. Now, before you might become a master developer, he explains there are two career paths to follow. One, is to focus on 1 technology/programming language your entire career and really become an expert. Second, you become the jack of all traits and learn multiple languages, or frameworks between 5 to 7, what he calls a systems developer. The important part here is that there are two choices for developers to consider.

I think the anarchy movement is really interesting since it removes the power hungry roles from the equation. Programmers are respected and in charge of their own projects, communications and career path. The video below is the presentation I am talking about:

One Hacker Way

This is the title of a talk by one of my heroes, Erik Meijer. I think this is one of his more (in)famous talks since this is essentially a 45 minute rant on everything that is wrong with agile and his intense hate against it, cursing and swearing included. I found it so darn funny, yet really sad that this is reality and people still work in a strictly, constrained Agile manner. In this talks he hits all the right notes that are wrong with agile. Let’s discuss them:

Erik starts with a profound statement about agile which I previously never gave much thought: Agile is an “evidence-based” management technique. Well show me the research, show me the evidence! He continues by saying that SCRUM is all based on anecdotes, not on actual research or empirical evidence. I think he points out something really important here; the SCRUM practice is subjective, based on how you implemented it, in your company. This is another thing that is wrong with SCRUM according to Erik. SCRUM is to constrained… Why must a standup meeting be exactly 10 minutes, why not 9 minutes, or 11.5 minutes. Where is the research, where is the evidence!? Will the SCRUM-police come pick you up if you spend more?

He says SCRUM is all buzzwords, talking about talking about code, but not about writing code. We are developers, we write code. People who call themselves “Agile” developers are all clowns because they spend to much time in stand-ups, review/retrospective meetings or making burn-down charts. Again, they talk about code, yet don’t write any. Maybe they do all this because they are SCRUMMaster, they have some fancy title. Well, Erik has some news for you; if something has a fancy title it probably means nothing and you are being scammed.

Yet, the worst part of Agile is the notion of managers having “Subtle Control”, you are being beeped, you are being fu, we are all being fucked. Agile is supposed to promote self organizing teams, yet managers still have subtle control. Controlling developers as if they are sheep. Funny or sadly enough, subtle control is actually a form of relational abuse… When Erik is  explaining this, you can really read the disappointment from his face. He then points out that Bertrand Meyer wrote an entire book about this, where he debunks the mythical Agile pyramid scheme.

After this rant, he starts giving an alternative; The Hacker Way. This is an approach written down into a letter to investors by Mark Zuckerberg at Facebook when they went for IPO. Here is a nice abstract of what is in there, you can read the entire letter here:

The Hacker Way is an approach to building that involves continuous improvement and iteration. Hackers believe that something can always be better, and that nothing is ever complete. They just have to go fix it — often in the face of people who say it’s impossible or are content with the status quo.

 

Hackers try to build the best services over the long term by quickly releasing and learning from smaller iterations rather than trying to get everything right all at once. To support this, we have built a testing framework that at any given time can try out thousands of versions of Facebook. We have the words “Done is better than perfect” painted on our walls to remind ourselves to always keep shipping.

 

Hacking is also an inherently hands-on and active discipline. Instead of debating for days whether a new idea is possible or what the best way to build something is, hackers would rather just prototype something and see what works. There’s a hacker mantra that you’ll hear a lot around Facebook offices: “Code wins arguments.”

 

Hacker culture is also extremely open and meritocratic. Hackers believe that the best idea and implementation should always win — not the person who is best at lobbying for an idea or the person who manages the most people.

Erik continues by saying the hacker way captures a lot of what agile is trying to do, but does from the developer point of view. He points out that the hacker way is hands-on, code always wins, not the person who does the most lobbying. In Agile, the manager most often wins. The Hacker code is all about how good of a developer you are! It’s not about being a smooth talker during standup meetings. It is all about the quality of your code and your work.

He ends this talk with saying that good developers should be treated as rock-stars. With rock-star salaries and respect. He compares rock-star developers with Lionel Messi. Lionel Messi is all about football (no, not soccer…). All he cares about is football. He is a true expert in his craft and is treated as such. This is reflected in his fame and his salary of course. Erik says he knows some developers in silicon valley who earn over 3 mil. dollars each year. That’s the way developers should be treated! He then gives the best analogy of developers and managers I have ever heard, I think this is truly golden:

Managers should act like beekeepers, and the developers are the bees. You can domesticate programmers the way beekeepers tame bees. You can’t exactly communicate with them, but you can use smoke and protective gear to make your way around them. In the end, if you do it right, you can harvest the honey, the true golden sweet (source code) honey. And the bees do not care, they will continue to make more honey. Just like developers, they write code, you ship the code, and they write more code! The job of the manager is to keep them focused on the end goal, where is the most impact and keep the developers producing the right honey.

In the case of Agile, managers act more like sheepherders. Just moving and controlling the herd… You can read the original post about this analogy here.

Pragmatic Dave Thomas also has a nice analogy; You cannot herd racehorses and you cannot race sheep. This boils down to the same thing. You need to steer the developers in somewhat the right direction, and leave them alone. Let them figure out the best way for solving the problem.

Those two analogies also remind me of something another great mind in the industry once said:

“It doesn’t make sense to hire smart people and then tell them what to to , We hire smart people so they can tell us what to do.”

This of course was said by Steve Jobs.

Erik Meijer ends his talk with a very nice slide, this one:

You can view his talks about The Hacker Way here or here:

Programming Motherfucker! Do you speak it!?

I remember stumbling upon the http://programming-motherfucker.com/ a long time ago. Back then I thought this was just someone with a high degree of humor. But now, after having worked almost a decade in the software industry I think this motherfucker was on to something! I also recognize many of the problems other people have recognized with agile for years. People have been giving out warnings about Agile for a long time now. I think it is interesting that many people, even among the founders, have issues with agile despite it’s insane popularity. Jeff Sutherlands marketing machine really did work very good…

But what is this “programming motherfucker” thing you might wonder. Well it’s sort of a rebellion against agile, which started as a joke but gained traction very quickly. It was created to show how you create some propaganda in our industry by hitting certain key points like: Community, Humiliation, Enemy, Unity, Profit/Power. You can watch a presentation about this here. It is a statement against popular software development / management methodologies since they treat programmers as if they are babies. The front-page of the website says programmers are humiliated by these methodologies for years and they are tired of it. Programmers should care about, well, programming, motherfucker… and we must get rid of these methodologies since they stand in the way of programming.

Zed Shaw, the creator of this webpage even put up a nice manifesto like the agile or craftsmanship founders did. This manifesto augments the agile manifesto in an interesting way. It goes as follows:

We think the shit on the left, is really just the con in the middle, and that we really need to just do the thing on the right…Programming, Motherfucker.

How funny or stupid the above manifesto and website are, many people will actually agree with this in some sense. I bet Erik Meijer feels the same way… When you think about it, there is some truth in here, that is where Erik was talking about in his talks. Agile is too much about talking about code, but not about coding. This is shown in the first statement of the manifesto. Then, agile promotes TDD, which Zed Shaw and Erik meijer obviously think is worthless since the software will ultimately fail in production due to dependencies it has somewhere else, which you can’t write unit tests for. That is why you need to test in production and employ a fail fast strategy. Netflix’ Chaos Monkey is a perfect example of this. The third point about customer collaboration is just the con of bleeding clients dry is a though one since I think it is proven you cannot make valuable software for someone without proper feedback. I think you need to get the customer in on the project. Erik also talks about this in his talk where he gives some explanation about feedback loops. The last statement in the manifesto is a rather interesting one; Responding to change is the con of instability and plausible deniability. I have certainly heard stories about scrum projects that completely derailed and where the customer is to blame. I think the software company should be blamed since they are the ones running the project. Plausible deniability is a problem I think.

My opinion

So, finally, after all this explaining I’ve come to the part where I give my take on this. Let me just step back a little; I’ve seen many conference talks about agile, why it is awesome and we should all do it. They often start with some history, just like I’m doing right now. They talk about their bad experience with the waterfall methodology, and that the waterfall methodology was just a way to control the influx of young programmers in the industry. These 20 something year olds needed some process to control them because they lack the discipline to write good software and do not understand business. They act immaturely and create a mess quickly.

Well, agile guru’s, maybe you have some reflecting to do… You are proposing the same thing with Agile. It is just some way of (subtle) control of the programmers. Now, I can happily say that I have never worked in a strictly waterfall way (thank god!). I’ve read a lot about it though. It is interesting to me that waterfall was such a popular methodology back then. I also think, Agile was certainly a step into the right direction. It just got messed up by marketing, certifications and power hungry assholes (yeah swearing is a thing now, motherfuckers).

So, in my opinion we need something of a hybrid approach between Craftsmanship and The Hacker Way. Why not Agile? Well because it is just too deformed by marketing an business. Agile is about people, not code… The craftsmanship movement is an augmented version of Agile where code and quality has a higher priority than talking about code and playing planning poker. So, I think we need to combine some of the practices of the craftsmanship movement and the hacker way. I think Erik and other strong believers in the hacker way will disagree with me, but hear me out.

I think the hacker way would be my favorite way of handling things yet, I want to be able to do TDD on certain occasions, I want to pair program when I think it is beneficial without being looked at as if I’m some (agile) clown. These practices have their value and I would not just dismiss them. We just need to use them when they are most effective. The other practices of Agile; Refactoring, Simple Design and Continuous Integration/Deployment are truly hard-coded into the hacker spirit.

I think when we combine The Hacker Way, with the technical practices of software craftsmanship and destroy all pointless roles to move closer to a programmer anarchy methodology, software projects would run much smoother.

#end

01010010 01110101 01100010 01100101 01101110