3 ms·

Fail. All of this shows the same problem that "Agile" in general has: it's an attempt to patch closed-allocation, business-driven software engineering. It does

Fail. All of this shows the same problem that "Agile" in general has: it's an attempt to patch closed-allocation, business-driven software engineering. It does not work. Maybe it turns the 0.5x developers into 0.75x players, but it alienates the shit out of the top talent. Fuck user stories. Fuck letting the passengers fly the plane. Fuck "sprints" or "iterations" or whatever nonsense you're calling these artificial time periods. Just let the people who can build great things, and who want to do so, go at it. I agree with some of what's being said here, but not the direction it's heading. Business-driven engineering is a dead end and it can't be patched by hiring consultants to tell people how to play planning poker. If you want to build great technology in-house, you can only do it as an engineer-driven firm. The real lesson from all this is that you should never let people work on more than one thing at once. Make sure they know what it is. Neat idea. Fails horribly in practice. Why? The problem with "one thing only" management is that the matter of who chooses each person's "one thing" gets horribly political, and fast. "One thing only" works only if the workers get to choose their one thing, which brings us to open allocation, which leaves me questioning whether we need all of this process that the engineers wouldn't impose on themselves... Also, "one thing only" tends to create dead time and throughput issues, (a) due to communication issues and blockages, and (b) because people who'd rather have a different "one thing" will often do other stuff anyway. It also tends to lead to a high burnout rate when people can't voluntarily switch between at least two tasks.

oz 12y ago
Mike, you're one of my favourite commenters on HN. But this is one of your concepts that I've never been able to wrap my head around. Specifically: >....business-driven software engineering. It does not work. My interpretation "business-driven software engineering" (and please correct me if I'm wrong) is one where business determines the requirements of the software. But if business doesn't drive those requirements, who will? You've repeatedly shown how terrible the typical dev is at business, and most devs would seemingly cozy up to their IDE rather than navigate the mess that is determining requirements. So who's gonna do it? Besides, which dev doesn't hate a fuzzy spec? Additionally, or perhaps more fundamentally, a business hires devs to the ends of furthering their, well, business objectives. What, exactly, is so wrong with business setting the agenda of what gets built? I ask because of a lesson I learned early (and painfully) in my career as a sysadmin. Technology exists for the business - Not the other way around. Unless, of course, you're a tech firm, where tech itself is your business. And even then, a business has to make economic sense, and as a programmer, I think I'm allowed to say we typically make poor economic choices. McLeod 'Clueless', if you will.
- michaelochurch 12y ago
  What, exactly, is so wrong with business setting the agenda of what gets built? I don't think that it's good when the business (usually, this means the executives) do it unilaterally. Obviously, it's not good for engineers to build with no concern whatsoever as to whether they're building something useful. It needs to be a collaboration focused around letting each side do what it's good at. I'd like to believe that enough of us have sufficient business sense that we don't need the Agile-style waterfall (no, that's not a contradiction) in which requirements flow from business into "product" into technology. Not all of us make sound economic choices, but I think that a large part of that comes from the fact that most companies promote people with any business sense "out of IT". As one who's trying to look forward for us as technologists, I guess I'd say that we need to take some responsibility for learning business and politics. The head-in-sand strategy is bad for us individually, but also bad for us as a group.
nostrademons 12y ago
There is a middle ground. Good managers will usually have a list of 2-3 things that you could be working on, and then the employee can pick one thing to work on amongst that list.

oz 12y ago

Mike, you're one of my favourite commenters on HN. But this is one of your concepts that I've never been able to wrap my head around. Specifically: >....business-driven software engineering. It does not work. My interpretation "business-driven software engineering" (and please correct me if I'm wrong) is one where business determines the requirements of the software. But if business doesn't drive those requirements, who will? You've repeatedly shown how terrible the typical dev is at business, and most devs would seemingly cozy up to their IDE rather than navigate the mess that is determining requirements. So who's gonna do it? Besides, which dev doesn't hate a fuzzy spec? Additionally, or perhaps more fundamentally, a business hires devs to the ends of furthering their, well, business objectives. What, exactly, is so wrong with business setting the agenda of what gets built? I ask because of a lesson I learned early (and painfully) in my career as a sysadmin. Technology exists for the business - Not the other way around. Unless, of course, you're a tech firm, where tech itself is your business. And even then, a business has to make economic sense, and as a programmer, I think I'm allowed to say we typically make poor economic choices. McLeod 'Clueless', if you will.

michaelochurch 12y ago
What, exactly, is so wrong with business setting the agenda of what gets built? I don't think that it's good when the business (usually, this means the executives) do it unilaterally. Obviously, it's not good for engineers to build with no concern whatsoever as to whether they're building something useful. It needs to be a collaboration focused around letting each side do what it's good at. I'd like to believe that enough of us have sufficient business sense that we don't need the Agile-style waterfall (no, that's not a contradiction) in which requirements flow from business into "product" into technology. Not all of us make sound economic choices, but I think that a large part of that comes from the fact that most companies promote people with any business sense "out of IT". As one who's trying to look forward for us as technologists, I guess I'd say that we need to take some responsibility for learning business and politics. The head-in-sand strategy is bad for us individually, but also bad for us as a group.

nostrademons 12y ago

There is a middle ground. Good managers will usually have a list of 2-3 things that you could be working on, and then the employee can pick one thing to work on amongst that list.