Slashdot Mirror
It's Not Developers Slowing Things Down, It's the Process
An anonymous reader writes: Software engineers understand the pace of writing code, but frequently managers don't. One line of code might take 1 minute, and another line of code might take 1 day. But generally, everything averages out, and hitting your goals is more a function of properly setting your goals than of coding quickly or slowly. Sprint.ly, a company than analyzes productivity, has published some data to back this up. The amount of time actually developing a feature was a small and relatively consistent portion of its lifetime as a work ticket. The massively variable part of the process is when "stakeholders are figuring out specs and prioritizing work." The top disrupting influences (as experienced devs will recognize) are unclear and changing requirements. Another big cause of slowdowns is interrupting development work on one task to work on a second one. The article encourages managers to let devs contribute to the process and say "No" if the specs are too vague. Is there anything you'd add to this list?
This is not exactly accurate. It hinges greatly on the type of manager we're talking about.
For example if the manager is very hands-on, goes into the details, produces proper mock-ups, flow diagrams, and everything is properly documented: This type of manager can actually accelerate the development process significantly since developers now know exactly what to do. But again, this manager has to really know what he's doing, and have some serious programming experience in his past.
All those moments will be lost in time, like tears in rain... time... to... die...
There is also the management of the manager: If the manager has too many products/projects on their plate they can't dedicate the time and focus to being that detail-oriented manager that gets things done. A good manager can turn into a bad one if they can't focus. That's where even higher-level management needs to set expectations and manage proper headcount.
You don't want to take managers out of the equation. They're the only people keeping the other departments from running you over. You see that most clearly, ironically, when you have an incompetent manager and you get run over in spite of it.
And a bad manager in this sense isn't the evil taskmaster, it is the guy who has no idea of his team's capabilities and taskload. He's also probably a little clueless about what is or is not possible, but in that sense, it's more of a feature of him making promises without talking to the rest of the team first. That manager goes to meetings and lets himself get cowed into submission when sales or marketing goes after him because he has no facts. Removing someone in that position just means that engineering is no longer even a speed bump to unrealistic goals.
Saying "No" to business people is not a valid strategy. You'll just find yourself replaced. Saying, "yes, but you'd need to spend 2 million dollars on it" with proof is a valid strategy. You don't want to sit around and come up with that data, that's what the manager is supposed to do.
I agree that indecisive managers and overwrought process is probably the top cause of problems with productivity. However, there are good managers and bad ones. It pays to understand the difference.
That is a good one. Sometimes, managers are having too many projects to manage at once and are experiencing the exact same problem as lead developers. They have to switch context so often they lose completely the focus when time comes to a particular project.
Usually, when a position post description mention: "must work well under pressure", "must be able to multi-task", "seeking for rockstar developer", etc; you can be sure you don't want to work there. It is symptomatic of a shop which operates without enough staff and on low budget expecting miracles to come out from the process.
Achille Talon
Hop!
First, that doesn't seem to be what the article is saying. Second, I don't really believe that it's true.
When I say "don't believe that it's true", I'm saying, "I don't believe that the removal of managers necessarily gets work done faster." I'm not talking about programming specifically-- I'm not a programmer, and managing programmers is not my expertise-- by my general experience is that a lot of people think managers are just wasting everyone's time, when the reality is more that most people don't understand what managers do. Unfortunately, this sometimes includes managers.
A good manager often spends his day trying to figure out how to remove obstacles so that the people he's managing can just do their jobs. For example, the summary says, "The article encourages managers to let devs contribute to the process and say 'No' if the specs are too vague." That sounds right to me. First, a good manager will of course listen to the people he's managing. That doesn't mean doing whatever they say, but when I have managed programmers, I assume that they know what they're doing better than I do, so if they say there's a problem of some sort, there's a problem of some sort. I wouldn't always go with their recommended solution, but would I listen to their explanation of the problem and try to come to a solution that addressed the programmers complaint as well as meeting the business needs we were trying to address.
If specs are too vague, that seems like the sort of thing a good manager would help to work out. For example, I might suggest talking to the programmer, trying to figure out which aspect of the specs are too vague, and then meeting with the stakeholders to try to clarify the specs. I wouldn't necessarily make the developer get involved in the process of clarifying them, since unless they're needed for the discussion, they probably have better things to do.
But being a good manager is pretty difficult in general. It's often not clear what needs to be done, or how it ought to be done, and it's your job to figure that out. It's pretty much impossible to be a bad manager without annoying people, but even the best managers might seem annoying or clueless because you don't see what they're doing for you. Sometimes good managers are only noticeable in their absence-- when they go away, you suddenly go "Oh jeeze, things are falling apart a bit here. How was it that we never had these problems before?" And the answer is, you were having those problems, but your manager was dealing with them when you weren't paying attention.
On time completion: It will be done as soon as it can be done, only experienced teams can provide reasonable estimates, developers provide timetables not managers, there's a specific amount of work that must be done before release and putting dates on it won't reduce the total amount of work that needs to be done.
Unclear requirements: It's now the developer's job to talk to the stakeholders and find out what all the requirements are at the point in time they need to size or implement them. They get a vague 'story' that gives an overall concept of a requirement, and then it's up to the dev to talk to whomever needs talking to, then.
Changing requirements: This happens and everyone expects it. So you do only the least work required to complete each requirement so the overhead in a change will be the smallest, and then you just pop that item on the queue and it gets done, that's it.
Context switching: Tasks are assigned to a team by managers, not as a sole developer, so if context switching is causing a problem, it's up to the team to figure out how to minimize it.
Take responsibility: They are, and increasing the duties that a developer has, while removing certain responsibilities from managers and product owners, which more accurately represents the reality of the situation.
Caveat: Recent studies have shown that Agile is not as good as a waterfall-agile mix, where you do a good amount of planning (especially architectural planning) prior to the agile-like development, which makes a lot of sense. If half your work effort is refactoring, at some point you start take a severe hit to either efficiency, quality (robustness, maintainability, operational limits like memory or speed, etc), or time.
That's nice, you left out architecture. Who's doing the overall architecture? Has it been done before? If it is new, better spend a lot of time doing the architecture. Unless....
You have caught Agilitis. In this case, spend no time doing the architecture up front, do it on the fly. Add time to every single task you think you see for doing architecture related stuff. At the end, allocate a large blob of time to figure out the correct architecture rather than the one you built which now resembles a dirty snowball. And begin rebuilding the thing, reusing any errant parts you did in pass one. And because you are agile, be sure to appropriate time for execs who understand agile as they get to change what's necessary on the taste of their coffee that day, whether their secretary gave them a perky Good Morning, or whether their hair will turn sufficiently silver in time for that next promotion.
Yeah, my company does that.
75 features to be implemented by the end of the quarter.
2 weeks in, cut it down to 50
1 month in, cut it down to 20.
Actually deliver 12 features.
Planning & prioritization are all over the place for the first month. And code freeze is 2 weeks into the second month.
Every single quarter. Why don't the people expecting 75 features every quarter get fired?
I'm just glad I'm not a developer here.
There are two types of people in the world: Those who crave closure
Especially funny. Rock Stars don't multi-task. They lock themselves away in a darkened office working on the currently interesting single problem until it is solved. Then they come out, decompress, and repeat.
Part of why they have rock star performance is that they don't multi-task and don't sit through endless meetings re-hashing yesterday's meeting.
Good lord, I could not agree more. From what I've learned in the last three companies I worked for that used agile, agile means that an ungodly amount of time is spent in meetings and constant, meaningless record-keeping. God, I hate agile. It gets in the way of doing good, timely work.
We use Agile for the *development* process which is distinct from the *design* process. That is, we do architecture up front, including DB design, and - surprise - we even build the server platforms too!
Don't ever leave your job unless this is becomes no longer true. So many people think agile is free tick to skip design and when wonder why agile isn't saving them from creating a pile of crap.