9 ms·

Your developers aren’t slow

176 points by davidkellis 12y ago

tzaman 12y ago
We learned this the hard way. After months of development we really didn't use (or know) any tools for proper development so we just wrote code in the most disorganized manner possible, which resulted in shipping far apart with poorly written code. After hiring a consultant on the matter, to introduce dailys, user stories, agile and whatnot,... well the world changed for us. Significantly. For the better, of course.
- greenbee 12y ago
  I think yours is a different scenario? The article suggests that developers trying to match business concerns with technical implementation disproportionately takes up time, as each feature was not spec-ed out and described properly in a technical manner. Accumulating technical debt would be a delay purely on the engineering side. The engineering team is not always to blame, though.
  - tzaman 12y ago
    Nope, not much different - There were two developers in the team (me + another dev) and my co-founder, who's a business (non-technical) co-founder. So it was between me and him where the specs and activities were not properly defined (it was my responsibility, and I didn't know any better) so we'd always have these long debates on what to do, and what's worse, these debates usually occured in the middle of other activities, so everyone was working on a lot of things at the same time, which resulted in work not being done on time, or even at all.
coreymaass 12y ago
Accurate reporting is great, after "accurate" guestimations. As a 15-year developer, I still get it wrong. Careful planning before you start is so crucial. And my boss knows to take whatever I say, double it, and then add a day. We're finally all on the same page :-) I love the Mad Libs-style form in sprintly, btw.
- mijustin 12y ago
  Joe Stump told a story on his podcast about this: the VP of Engineering would always tell the business side, “Everything always takes 60 days.” He had a high confidence that most tasks take 60 days. Here's the link to the audio: https://soundcloud.com/business-of-coding/business-of-coding-michael-sopp https://soundcloud.com/business-of-coding/business-of-coding...
serve_yay 12y ago
Oooh boy do I hate that style of user story. In my experience it just seemed to degenerate into "as a business owner, I want developers to make this feature so that our product can have this feature".
- cobrophy 12y ago
  That might follow the pattern but it breaks a bunch of typical user story rules. It's easy to blame the format, but it sounds like the product owner needs to be educated on the process.
cobrophy 12y ago
I don't think specs are ever going to be perfect. Simply because the people typically writing specs (project managers, user experience designers, business analysts etc.) view the requirements through a different lens than a developer. In my experience the best solution is for them simply to be available to the developers to answer questions that arise in a timely manner.
dansingerman 12y ago
"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.
- greyskull 12y ago
  I've found the hardest part is "build good software". Granted, I'm new, only going off of experiences in four internships. e.g. Now, this company is building a tablet application, except the director is serious about UX and hired actual UX people. But things are constantly changing, on a weekly basis; we'll build out some complex interaction feature, then then have it scrapped a few weeks later. And the codebase has suffered greatly.
  - dansingerman 12y ago
    If things are changing because requirements are changing, rather than because complexity of requirements is being uncovered, then that is a hard issue to solve. But it also reflects the real world. Building good software is hard.
- mijustin 12y ago
  Yes! I think this section of the post could definitely be expanded on: It’s important to have developer buy-in. Their passion for a feature can be a huge driver for velocity. This is why I also appreciate PM tools that incorporate discussion threads: that back-and-forth communication really helps clarify what you're building. I also like using the 5 whys after the initial spec has been written: "Why are we building this feature?"
- 12y ago
conradfr 12y ago
What incentive do your developers have to ship faster ?
- spacefight 12y ago
  Exit earlier?
- nostrademons 12y ago
  Feel more accomplished? Smarter? Have more unhassled free time to spend with their families? Get it over with so they don't have the "oh my god we're going to die" feeling hanging over them 24/7?
- bsg75 12y ago
  If "faster" equates to lower quality, bugs, more post-release thrash - simply to meet a contrived / marketing deadline - then none ;)
DigitalSea 12y ago
Wholeheartedly true. Vague requirements are definitely the bane of my existence, just this last week I had a massive story I was working on which I implemented only to be told that I misunderstood the story at hand. After pointing out the confusion with the task, product admitted they got the requirements wrong. Don't get me wrong, I like the story format of detailing requirements, in most cases it definitely helps (although I know many developers who dislike the story format), but it is not without its issues. The weak leak is always the product owner writing the wrong stories within a task. In my opinion the biggest contributor to tech debt is NOT lack of stories in tasks or poorly written ones leading to vague requirements (although it doesn't help), it is unrealistic timelines and failing to factor in testing. When people are pushed to achieve a long list of things in a short amount of time, they take shortcuts to get them done which appeases the product owners but leaves some landmines in the codebase waiting to be stepped on. The biggest issue with Agile in my opinion is lack of time devoted to testing. It works on a cycle of "You estimated we can get this much done within this much time" I have never been in a planning meeting that even mentioned testing as part of the normal development cycle, it is always an afterthought when the other big ticket items are done and time is running out. Time for writing tests and testing should be instantly baked into the Agile process (maybe it is and my experience has been unfortunate), this will significantly reduce tech debt. I think the issue with testing and technical debt in my experience has been the fact the places I have worked in like to call themselves Agile, they have the daily standups that always descend into debates and meetings, they have the planning poker events and we do sprints, however they don't fully adhere to the rules of Agile. When you start slipping in extra tasks that were not estimated on or were just added and slip them into the current sprint, that is not Agile. When you start changing deadlines and priorities midway through a sprint, that is not Agile. I think this is a problem that is more prevalent than people realise. There are misconceptions as to what proper Agile is.
- joesmo 12y ago
  Same here with vague requirements. Interesting enough, between requirements that are a couple of sentences that I pull out from a conversation or a 30 page requirements document, the vagueness is often a problem in both. In the former case, there just isn't enough information and it's clear that the feature just hasn't been thought out. In the latter case, the information is too detailed and there isn't enough room for interpretation of small, mainly insignificant (from a product perspective) details, on the developer's part. Either way, it ends up with a lot of wasted effort and a lot more time being spent on a project than necessary. Almost always, this is avoidable if the spec writers put in more effort in tackling the problem, understanding the system, and understanding what is and isn't possible.
rday 12y ago
I've found that, when building applications for clients, they never know what they really want. I try to explain that writing an application is just like formally documenting your business process. If you don't have the process, then you don't have an application to write.
protonfish 12y ago
I have seen huge improvements in quality and productivity by using stories plus wireframes. The first thing a UI dev does is create a quick mockup for feedback from the end user (specified in the story in the blank after "As a ____" Unfortunately implementing this can be a political struggle because it takes a lot of the decisions away from the business and the project manager and hands them to the developers and users.
- ajuc 12y ago
  My boss in previous company forced analysts to write bug reports and feature requests in the form: "how it works now, how it should work". This took at most a month and made life for everybody a lot better.
bowlich 12y ago
Context switching can be the worst. Particularly when it's caused by "hurry up and wait" brought on by clients. PM: Client wants feature X and they need it now! Developer: Great, I can get started today, but first I'll need clarification on X, Y and Z. PM: I'll e-mail the client... Then hours turn into days, days into weeks. By the time they get back, I've completely forgotten what it was we were going to do on the project or why I needed to know X, Y and Z.
- rmetzler 12y ago
  remove the PM.
  - thisone 12y ago
    You've never had clients that take that long to get back to you about something that is actually important to them? That's pretty lucky.
    - ohyes 12y ago
      I learned to send follow up emails to remind them I was waiting on their input. If I don't hear back in a reasonable amount of time it's an email.
TrinnyLopez 12y ago
Why do they call them "Stories" in this article? Is it because of Agile? They are called "Change Requests". Put on your big boy pants and replace "Stories" with "Changes" and it makes much more sense.
- 33W 12y ago
  In my experience of building new things, rather than modifying existing ones, "Changes" would make less sense, as there is little or nothing to change.
ExpiredLink 12y ago
> - Unclear requirements > - Changing requirements > - Context switching That's Agile Programming!
michaelochurch 12y ago
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.
edw519 12y ago
Nice start, OP (especially with unclear specs, my personal pet peeve), but you've only hit upon the tip of the iceberg. Just a few other things I call "work prevention" that make good developers appear to be slow: - unclear specs - context switching - peer review (both giving & receiving) - code review - status meetings - waiting for others to show up at meetings - others not prepared for meetings (no agenda, etc.) - unnecessary but enforced standards (stupid, pointless) - programs locked by other devs (get in line) - pre-existing technical debt (must be fixed before amended) - framework can't handle it - works but won't scale - can't recreate bug - platform issue (server, DBMS, etc.) - environmental issues (test server out of date) - waiting for server resources (testing) - waiting for regression tester - waiting for user acceptance testing - specs changing during user acceptance testing - uncontrolled deployment "freezes" (month-end, release schedule) - noisy office - meetings when emails would have sufficed - phone calls when emails would have sufficed - text messages when emails would have sufficed - continually changing priorities - delays in offshore communications - lack of training (technology) - lack of training (business subject matter) - too much training (HR bullshit) - not enough donuts
- humanrebar 12y ago
  - nonexistent or substandard tools ...including old compilers and otherwise a lack of support for the compilers, debuggers, editors, analyzers, profilers, etc. that will enable a developer to focus on business problems instead of technology stack problems.
  - ultimape 12y ago
    After a long enough period of time, this can solidify as the more frustrated developers leave and all you have left are developers who are happy slogging through inefficient processes. Anthropology of corporate cultures is fascinating: http://www.daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner http://www.daedtech.com/how-developers-stop-learning-rise-of...
- humanrebar 12y ago
  - waiting for regression tester Or worse, a lack of regression testing requiring substantial software archaeology in order to be confident enough to make a change to legacy code. Similarly: - substandard documentation
coldcode 12y ago
"The second biggest complaint we see from developers? Constantly changing the specs once work has begun." Of course this is called being agile. If everything has to be known before you start work how is this different than waterfall? People don't know what they want or need until they see it. So you have to find some way to let me see it which means writing something based on incomplete information.
- UK-AL 12y ago
  Waterfall is all up front. Agile is up front at the task level. Normally when commited to a sprint it doesn't change.
  - dragonwriter 12y ago
    > Waterfall is all up front. Agile is up front at the task level. Agile isn't a methodology, its a meta-methodology (a set of principles for selecting and dynamically adapting the methodology in use.) If waterfall is the process that produces good results for the set of people you have working on the problems you are addressing, then waterfall is Agile. What you say is about sprints is accurate about Scrum, but while an Agile shop might use (and especially start with as a baseline) Scrum, Scrum is not the same thing as Agile. There's a good reason to argue that not committing to requirements at some point so that work can proceed directed at a fixed target is suboptimal in the general case, but arguing whether its Agile or not -- and even moreso describing Agile as definitively being up front at some specific level, is confusing metamethodology with methodology and reducing Agile to a fixed methodology, of which it is very much the antithesis.
- fragmede 12y ago
  That might be more agile, but it's not Agile.
ilaksh 12y ago
To me the root cause is generally a lack of resources in terms of time and money. Contributing to that is the general inability for people to grasp the complexity of software development. After implementing the requirements, it is found that they did not reflect the actual desired system. Then there are technical issues that were unforeseen. Rather than accepting these technical issues as additional costs, they are blamed on the developer, "if they knew what they were doing, there would have just done it already". Incorrectly or poorly communicated requirements are also blamed on the developer. To me the root cause is generally a lack of resources in terms of time and money. Contributing to that is the general inability for people to grasp the complexity of software development. Personally, I have never had a client or budget that I could say was really reasonable throughout. I believe this unicorn may exist somewhere. Certainly I haven't been finding my clients in the most auspicious places.
datashovel 12y ago
Here are a few of the resources I have used in the past to help explain to non-technical folks some of what a developer needs to deal with when involved in a large project. 1) Ward Cunningham explains "technical debt": https://www.youtube.com/watch?v=pqeJFYwnkjE https://www.youtube.com/watch?v=pqeJFYwnkjE 2) comic strip - "How Projects Really Work": http://www.projectcartoon.com/cartoon/2 http://www.projectcartoon.com/cartoon/2
slavik81 12y ago
> it also appears that teams have a hard time transitioning from “done” to “tested and ready to be deployed” (look at Completed to Accepted above). How can it be done if you don't know if it works? It's troubling that it takes a long time to go from 'done' to 'ready to be deployed', when they sound like the same thing. I mean, really it's just terminology, but it suggests that there's a lot of tasks that are not being considered as 'real work' that are actually quite time-consuming in practice. It can be useful to look over what work was actually done historically so that perception of a task matches reality.

176 points by davidkellis 12y ago

We learned this the hard way. After months of development we really didn't use (or know) any tools for proper development so we just wrote code in the most disorganized manner possible, which resulted in shipping far apart with poorly written code. After hiring a consultant on the matter, to introduce dailys, user stories, agile and whatnot,... well the world changed for us. Significantly. For the better, of course.

greenbee 12y ago
I think yours is a different scenario? The article suggests that developers trying to match business concerns with technical implementation disproportionately takes up time, as each feature was not spec-ed out and described properly in a technical manner. Accumulating technical debt would be a delay purely on the engineering side. The engineering team is not always to blame, though.
- tzaman 12y ago
  Nope, not much different - There were two developers in the team (me + another dev) and my co-founder, who's a business (non-technical) co-founder. So it was between me and him where the specs and activities were not properly defined (it was my responsibility, and I didn't know any better) so we'd always have these long debates on what to do, and what's worse, these debates usually occured in the middle of other activities, so everyone was working on a lot of things at the same time, which resulted in work not being done on time, or even at all.

coreymaass 12y ago

Accurate reporting is great, after "accurate" guestimations. As a 15-year developer, I still get it wrong. Careful planning before you start is so crucial. And my boss knows to take whatever I say, double it, and then add a day. We're finally all on the same page :-) I love the Mad Libs-style form in sprintly, btw.

mijustin 12y ago
Joe Stump told a story on his podcast about this: the VP of Engineering would always tell the business side, “Everything always takes 60 days.” He had a high confidence that most tasks take 60 days. Here's the link to the audio: https://soundcloud.com/business-of-coding/business-of-coding-michael-sopp https://soundcloud.com/business-of-coding/business-of-coding...

serve_yay 12y ago

Oooh boy do I hate that style of user story. In my experience it just seemed to degenerate into "as a business owner, I want developers to make this feature so that our product can have this feature".

cobrophy 12y ago
That might follow the pattern but it breaks a bunch of typical user story rules. It's easy to blame the format, but it sounds like the product owner needs to be educated on the process.

cobrophy 12y ago

I don't think specs are ever going to be perfect. Simply because the people typically writing specs (project managers, user experience designers, business analysts etc.) view the requirements through a different lens than a developer. In my experience the best solution is for them simply to be available to the developers to answer questions that arise in a timely manner.

dansingerman 12y ago

"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.

greyskull 12y ago
I've found the hardest part is "build good software". Granted, I'm new, only going off of experiences in four internships. e.g. Now, this company is building a tablet application, except the director is serious about UX and hired actual UX people. But things are constantly changing, on a weekly basis; we'll build out some complex interaction feature, then then have it scrapped a few weeks later. And the codebase has suffered greatly.
- dansingerman 12y ago
  If things are changing because requirements are changing, rather than because complexity of requirements is being uncovered, then that is a hard issue to solve. But it also reflects the real world. Building good software is hard.
mijustin 12y ago
Yes! I think this section of the post could definitely be expanded on: It’s important to have developer buy-in. Their passion for a feature can be a huge driver for velocity. This is why I also appreciate PM tools that incorporate discussion threads: that back-and-forth communication really helps clarify what you're building. I also like using the 5 whys after the initial spec has been written: "Why are we building this feature?"
12y ago

conradfr 12y ago

What incentive do your developers have to ship faster ?

spacefight 12y ago
Exit earlier?
nostrademons 12y ago
Feel more accomplished? Smarter? Have more unhassled free time to spend with their families? Get it over with so they don't have the "oh my god we're going to die" feeling hanging over them 24/7?
bsg75 12y ago
If "faster" equates to lower quality, bugs, more post-release thrash - simply to meet a contrived / marketing deadline - then none ;)

DigitalSea 12y ago

Wholeheartedly true. Vague requirements are definitely the bane of my existence, just this last week I had a massive story I was working on which I implemented only to be told that I misunderstood the story at hand. After pointing out the confusion with the task, product admitted they got the requirements wrong. Don't get me wrong, I like the story format of detailing requirements, in most cases it definitely helps (although I know many developers who dislike the story format), but it is not without its issues. The weak leak is always the product owner writing the wrong stories within a task. In my opinion the biggest contributor to tech debt is NOT lack of stories in tasks or poorly written ones leading to vague requirements (although it doesn't help), it is unrealistic timelines and failing to factor in testing. When people are pushed to achieve a long list of things in a short amount of time, they take shortcuts to get them done which appeases the product owners but leaves some landmines in the codebase waiting to be stepped on. The biggest issue with Agile in my opinion is lack of time devoted to testing. It works on a cycle of "You estimated we can get this much done within this much time" I have never been in a planning meeting that even mentioned testing as part of the normal development cycle, it is always an afterthought when the other big ticket items are done and time is running out. Time for writing tests and testing should be instantly baked into the Agile process (maybe it is and my experience has been unfortunate), this will significantly reduce tech debt. I think the issue with testing and technical debt in my experience has been the fact the places I have worked in like to call themselves Agile, they have the daily standups that always descend into debates and meetings, they have the planning poker events and we do sprints, however they don't fully adhere to the rules of Agile. When you start slipping in extra tasks that were not estimated on or were just added and slip them into the current sprint, that is not Agile. When you start changing deadlines and priorities midway through a sprint, that is not Agile. I think this is a problem that is more prevalent than people realise. There are misconceptions as to what proper Agile is.

joesmo 12y ago
Same here with vague requirements. Interesting enough, between requirements that are a couple of sentences that I pull out from a conversation or a 30 page requirements document, the vagueness is often a problem in both. In the former case, there just isn't enough information and it's clear that the feature just hasn't been thought out. In the latter case, the information is too detailed and there isn't enough room for interpretation of small, mainly insignificant (from a product perspective) details, on the developer's part. Either way, it ends up with a lot of wasted effort and a lot more time being spent on a project than necessary. Almost always, this is avoidable if the spec writers put in more effort in tackling the problem, understanding the system, and understanding what is and isn't possible.

rday 12y ago

I've found that, when building applications for clients, they never know what they really want. I try to explain that writing an application is just like formally documenting your business process. If you don't have the process, then you don't have an application to write.

protonfish 12y ago

I have seen huge improvements in quality and productivity by using stories plus wireframes. The first thing a UI dev does is create a quick mockup for feedback from the end user (specified in the story in the blank after "As a ____" Unfortunately implementing this can be a political struggle because it takes a lot of the decisions away from the business and the project manager and hands them to the developers and users.

ajuc 12y ago
My boss in previous company forced analysts to write bug reports and feature requests in the form: "how it works now, how it should work". This took at most a month and made life for everybody a lot better.

bowlich 12y ago

Context switching can be the worst. Particularly when it's caused by "hurry up and wait" brought on by clients. PM: Client wants feature X and they need it now! Developer: Great, I can get started today, but first I'll need clarification on X, Y and Z. PM: I'll e-mail the client... Then hours turn into days, days into weeks. By the time they get back, I've completely forgotten what it was we were going to do on the project or why I needed to know X, Y and Z.

rmetzler 12y ago
remove the PM.
- thisone 12y ago
  You've never had clients that take that long to get back to you about something that is actually important to them? That's pretty lucky.
  - ohyes 12y ago
    I learned to send follow up emails to remind them I was waiting on their input. If I don't hear back in a reasonable amount of time it's an email.

TrinnyLopez 12y ago

Why do they call them "Stories" in this article? Is it because of Agile? They are called "Change Requests". Put on your big boy pants and replace "Stories" with "Changes" and it makes much more sense.

33W 12y ago
In my experience of building new things, rather than modifying existing ones, "Changes" would make less sense, as there is little or nothing to change.

ExpiredLink 12y ago

> - Unclear requirements > - Changing requirements > - Context switching That's Agile Programming!

michaelochurch 12y ago

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.

edw519 12y ago

Nice start, OP (especially with unclear specs, my personal pet peeve), but you've only hit upon the tip of the iceberg. Just a few other things I call "work prevention" that make good developers appear to be slow: - unclear specs - context switching - peer review (both giving & receiving) - code review - status meetings - waiting for others to show up at meetings - others not prepared for meetings (no agenda, etc.) - unnecessary but enforced standards (stupid, pointless) - programs locked by other devs (get in line) - pre-existing technical debt (must be fixed before amended) - framework can't handle it - works but won't scale - can't recreate bug - platform issue (server, DBMS, etc.) - environmental issues (test server out of date) - waiting for server resources (testing) - waiting for regression tester - waiting for user acceptance testing - specs changing during user acceptance testing - uncontrolled deployment "freezes" (month-end, release schedule) - noisy office - meetings when emails would have sufficed - phone calls when emails would have sufficed - text messages when emails would have sufficed - continually changing priorities - delays in offshore communications - lack of training (technology) - lack of training (business subject matter) - too much training (HR bullshit) - not enough donuts

humanrebar 12y ago
- nonexistent or substandard tools ...including old compilers and otherwise a lack of support for the compilers, debuggers, editors, analyzers, profilers, etc. that will enable a developer to focus on business problems instead of technology stack problems.
- ultimape 12y ago
  After a long enough period of time, this can solidify as the more frustrated developers leave and all you have left are developers who are happy slogging through inefficient processes. Anthropology of corporate cultures is fascinating: http://www.daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner http://www.daedtech.com/how-developers-stop-learning-rise-of...
humanrebar 12y ago
- waiting for regression tester Or worse, a lack of regression testing requiring substantial software archaeology in order to be confident enough to make a change to legacy code. Similarly: - substandard documentation

coldcode 12y ago

"The second biggest complaint we see from developers? Constantly changing the specs once work has begun." Of course this is called being agile. If everything has to be known before you start work how is this different than waterfall? People don't know what they want or need until they see it. So you have to find some way to let me see it which means writing something based on incomplete information.

UK-AL 12y ago
Waterfall is all up front. Agile is up front at the task level. Normally when commited to a sprint it doesn't change.
- dragonwriter 12y ago
  > Waterfall is all up front. Agile is up front at the task level. Agile isn't a methodology, its a meta-methodology (a set of principles for selecting and dynamically adapting the methodology in use.) If waterfall is the process that produces good results for the set of people you have working on the problems you are addressing, then waterfall is Agile. What you say is about sprints is accurate about Scrum, but while an Agile shop might use (and especially start with as a baseline) Scrum, Scrum is not the same thing as Agile. There's a good reason to argue that not committing to requirements at some point so that work can proceed directed at a fixed target is suboptimal in the general case, but arguing whether its Agile or not -- and even moreso describing Agile as definitively being up front at some specific level, is confusing metamethodology with methodology and reducing Agile to a fixed methodology, of which it is very much the antithesis.
fragmede 12y ago
That might be more agile, but it's not Agile.

ilaksh 12y ago

To me the root cause is generally a lack of resources in terms of time and money. Contributing to that is the general inability for people to grasp the complexity of software development. After implementing the requirements, it is found that they did not reflect the actual desired system. Then there are technical issues that were unforeseen. Rather than accepting these technical issues as additional costs, they are blamed on the developer, "if they knew what they were doing, there would have just done it already". Incorrectly or poorly communicated requirements are also blamed on the developer. To me the root cause is generally a lack of resources in terms of time and money. Contributing to that is the general inability for people to grasp the complexity of software development. Personally, I have never had a client or budget that I could say was really reasonable throughout. I believe this unicorn may exist somewhere. Certainly I haven't been finding my clients in the most auspicious places.

datashovel 12y ago

Here are a few of the resources I have used in the past to help explain to non-technical folks some of what a developer needs to deal with when involved in a large project. 1) Ward Cunningham explains "technical debt": https://www.youtube.com/watch?v=pqeJFYwnkjE https://www.youtube.com/watch?v=pqeJFYwnkjE 2) comic strip - "How Projects Really Work": http://www.projectcartoon.com/cartoon/2 http://www.projectcartoon.com/cartoon/2

slavik81 12y ago

> it also appears that teams have a hard time transitioning from “done” to “tested and ready to be deployed” (look at Completed to Accepted above). How can it be done if you don't know if it works? It's troubling that it takes a long time to go from 'done' to 'ready to be deployed', when they sound like the same thing. I mean, really it's just terminology, but it suggests that there's a lot of tasks that are not being considered as 'real work' that are actually quite time-consuming in practice. It can be useful to look over what work was actually done historically so that perception of a task matches reality.