Respect

Nov 20, 2014

work programming advice

R-E-S-P-E-C-T, find out what it means to me. - Aretha Franklin

I'm feeling a bit crabby this morning, perhaps because I had to deal with a take-home exercise that passed for an interview. But that's another story. Today I want to focus on respect and how the software industry is mishandling it. To service the above quote, I also want to provide some insight into how I, just your average humble software developer, choose to define the term.

After reading Your developers aren't slow, which explains how it is often the process of creating feature requests that is slow and not the developer implementing the feature, I sent out two tweets:

Is it just me or do Agile, Scrum, and Kanban activities infantalize software developers?

How can our profession be respected when people see that we must be given games to produce quality work?

The worst offender by far is Scrum, which emphasizes things like daily standups, story points, and other such nonsense. Wipe away the names and activities and these are all games. There are not about writing better software, they are not about gathering more complete requirements from customers, and they are certainly not about providing a customer with a better product experience. They are used to create process and structure a work day. But must managers treat developers like children in order to create working software? Aren't developers smarter than this?

It is all a joke and it needs to stop.

Yes, software gets delivered. Yes, customers are happy. But has anyone ever questioned whether these same goals would be met without playing these games and infantalizing developers?

[Small note: The things I talk about next are how things happen in real life, not the utopia of the Agile manifesto.]

User Stories

To paraphrase Lewis Carroll, let's start at the beginning and talk about user stories. That's where it all begins, and the work life of a developer starts to go downhill.

User stories are a terrible idea and I'm surprised developers allow these to exist. The aforementioned article was discussed on HackerNews and one particular comment by dansingerman stood out to me:

"Writing good specs is important" - it's also really really hard.

It is all too easy for a developer to blame difficulties on poor specs.

But if you're doing agile properly, you shouldn't consider a user story a 'spec' - a user story should be a placeholder for a conversation.

It is unrealistic to expect a non-technical stake holder to deeply and accurately describe anything but the most trivial feature. It needs a developer mindset to poke the idea, see what holds water, see where it falls apart, foresee the consequences.

You can't do that in a spec. It needs to be a conversation.

Agile favours 'Individuals and interactions over processes and tools', and this is too often forgotten when someone is pimping their tool, or blaming their process.

Have a conversation, understand what's needed, build good software.

Yes, dansingerman is correct, a user story should be the start of a conversation, and yet what ends up happening in reality is it become the end of the conversation whose next step is to assign story points.

More to the point, there is no way to know if one is "doing agile properly," since developers don't jump between companies (Agile tends to different company to company, rarely team to team). And I would expect a stakeholder to describe a feature completely, because that's the definition of a stakeholder: they hold a stake in ensuring that the work is done correctly. What I have seen happen in many companies is the project/product manager will be the one talking to the customer and gathering user stories, then passing those stories off to the developer. Once the developer gets the story and goes "WTF?!?" the stakeholder has moved on and assumed everything is okay. Going back to the stakeholder is often met with silent derision against the developer that they somehow are too dumb to understand the feature requirements.

The most salient point by dansingerman is the last one, "Have a conversation, understand what's needed, build good software." If we translate that into an industry that is respected, it means have the developer work directly with the stakeholder to flesh out a requirement end-to-end, without intermediaries or user stories. This builds a specification and the developer can then get down to work. If there is a change to be made, that's fine, but the specification will enforce a modicum of rigidity to the feature so that wild changes don't ruin the time/effort estimates.

Story Points

These are a joke. This is where a project manager will go through each user story (a very brief description of a feature request) and ask the developers to each guess how complex the activity is by assigning it a story point. A story point can either be an integer (1,2,3, etc.), a colour (blue, purple, black, etc.) or anything the team chooses to denote the transition from simple to complex.

As each developer adds their guess to the user story, then an average story point value is assigned. There is no discussion about the story's complexity, that's not the point of this exercise (it happens later).

There are a few issues here:

1. The math is bunk. You cannot assign a value to a story with unknown complexity. That's like saying 3x = 3, where x is the unknown complexity of any all stories and 3 is the story point value. Somewhere in the burndown charts the complexity gets omitted.
2. You've reduced a complex topic concering the creation, testing, and deployment of working software into a 1/2/3 point system. How did developers get to the point where they think in such primary terms?
3. The story points are immutable. Once the sprint planning is complete, the point value is never revised based on new information. This is hugely ironic because the entire basis of Agile is to allow for changing requirements, and yet right here is a fixed value that resists change.

You are fooling yourself if you think it is easy to assign points to a user story. For an example of a real-life user story, see my post on Gathering Requirements Properly. Now assign an immutable story point to this.

Developers will conclude from the above statements that all of this will be ironed out in successive sprints. This pushes the discovery cost onto the customer, who just wants their feature implemented and doesn't want to pay for the team to figure out how to code faster.

Next time you want to see how stupid story points are in real-life, try this: Take your car to a mechanic and have a conversation with him about what needs to be checked, fixed, etc. Give the mechanism very vague requirements and have him determine complexity by assigning points (1, 2, 3) to each one. Then watch the mechanic get annoyed at you for being treated like a child.

Meetings and More Meetings

For a software development methodology that professes to help developers deliver software faster, I'm amazed at how many meetings are produced while the software is supposed to be implemented.

Daily standups sound great, but the intent of them is to get people to talk. If people aren't talking about problems when they happen, then the team has bigger problems. The first thing to do is to ensure that people can speak about anything, at any time, so long as they aren't interrupting work (email is great for this because it is asynchronous).

So daily standups are used to talk, but not to talk about an actual issue. That's "un-scrum" ¹ and should be discussed in yet another meeting. Instead, each person should state the following:

• what I did yesterday
• what I am going to do today
• what roadblocks I am encountering

This doesn't so much foster increased communication, but rather turns us into robots. Most people tune out until their turn comes up and then stumble through their own status update. This meeting format feels more like what we were trained to do in show-and-tell, and now highly-intelligent developers are reduced to the level of a primary school student.

What I have never seen discussed in a meeting is how to build better software, the right architecture to take to allow for growth, or how to better test the application. These topics are all considered non-work and are placed in a lunch-and-learn or some other time when software is not being written. Yet with these topics discussed and everyone in agreement, one could write better software in less time.

Here's my 16-year-tested, fool-proof way to reduce the number of minutes spent in meetings:

• everyone shows up to meetings on time.
• everyone already knows the topics that will be presented.
• everyone has prepared what they need to add to the topics discussed.
• everyone wants to make this meeting the shortest, most effective, meeting on record.
• when time-sensitive issues arise, they are brought up immediately with the smallest number of team members to solve the problem.
• everyone sends an email if they do not wish to interrupt others.
• everyone reserves 30 minutes at the beginning and the end of the day to answer all emails. Every email is complete. Practise Inbox Zero.
• everyone respects each other's right to privacy.
• everyone knows what others are working on because there is a tool that tells them that.
• everyone keeps said tool updated with their present status.
• everyone is a responsible adult and knows what the current goal is and what to work on to meet that goal.
• everyone is a human being.
• everyone is equal.

There, I just saved you thousands of dollars in wasted time, and simultaneously increased worker happiness.

And the award goes to…

Instead of treating the symptom, it is best to find the root cause of the problem. That is, the initial reason it started. And for that we have to thank ourselves. Yes, the software developers are the main cause of this problem because we have allowed ourselves to be subjugated by people running these Agile games all in the attempt to deliver faster and more frequently.

The strongest chains are the ones that the slave puts on himself.

[Meta] Waterfall and Other Bad Words

While proofreading this article I began to think that maybe someone will argue that I'm stating we should all go back to waterfall. That thought made me feel bad. But why should I feel bad about a thought and why do I allow myself to be identified by a particular methodology?

When speaking about Agile or Waterfall (there's more than two, but let's go with it), there is a particular fervor that happens. This argument reminds me of the oft-repeated accusation in American politics of being labelled a socialist. That is, if you ascribe any value to something the government should handle instead of private business, you are a capital-S Socialist and should be ashamed.

As with anything in life, it is not a black-or-white decision. Software was developed for years in a waterfall model, and everything turned out okay. Agile has been around for over a decade now and yet crummy software is still turned out by good developers. That doesn't mean we should throw either of these things away, it simply means that processes need to be tweaked and that the industry still needs time to mature. These Agile games being played by developers do not help mature the industry.

Developers need to resist the temptation to apply labels to themselves or to others, and stand up against all instances of subjugation.

Footnotes