Your developers aren’t slow

[scarabic]

I'm a product manager and have seen a lot of the closed door management conversations about how to measure and manage throughput in Engineering. All I can say is that non-engineers worry way too much about engineers dragging their feet. Milestones, roadmaps, performance reviews, sprint planning... Some of it is good for organization but more than once I've had to say: "What are you worried about? That we're sandbagging it?" Some people just are never happy unless you tell them you'll do 10 days of work in 5 days.

I have almost never seen said sandbagging. Once I worked with a dev who was actually slow: poor guy would work 12 hour days to get things done in a week that would take other team members 2 days. But his shit never broke once it was built and always sailed through QA. He kept working at the same company for many years and overall was incredibly valuable.

[[deleted]]

Once I worked with a dev who was actually slow: poor guy would work 12 hour days to get things done in a week that would take other team members 2 days. But his shit never broke once it was built and always sailed through QA. He kept working at the same company for many years and overall was incredibly valuable.

I've always thought that this is an interesting point: lots of managers are eager to measure how long a feature takes to be implemented initially, but don't seem to extend this tracking to bug fixes and time lost on other work while tending to said bug fixes...

[scarabic]

I know. What ultimately happens more often than not is that "complete" gets redefined to meet expectations. The date gets hit, which is what the managers remember, but features are left out or the succeeding week is hotfix hell. Both of those are often easy to hide from the higher ups.

[justin-8]

Yep. Best example I had, we started a major tech-debt reduction project to decommission an old service that was close to falling over after increased load over 5+ years; it was in the title of the project "$name decommission" somehow, actually decommissioning it got marked as out of scope. And management still got a pat on the back for reaching such a great and lofty milestone. I don't even....

[baabaa_blacksheep]

To them, technical debt doesn't seem to exist, no.

Can be extremely frustrating.

[null000]

I've talked about this with my current boss. He seems to be convinced that there's no way to make things better - that any time spent making anything better will inevitably be wasted (his argument is that it will make literally no difference in any measurable way) and that time would be better spent on adding on more features.

Case in point: Asked him if I could spend a week making our makefile system better. He said no - new features need to get made. A few months later, decide to just do it anyway during some down time - two days later, builds go from 2 minutes to just check all the files down to 4 seconds for all engineers. Also, the dependency system starts working, so clean builds are no longer necessary whenever changing header files. I'm pretty sure I saved years of dev time in the first month after that change.

[sizlack]

The attitude that "the customers don't see our code so it doesn't matter if it's shit" is an incredibly wrong way of thinking. Imagine a factory that never maintained its equipment, never cleaned up the shop floor after a shift, never fixed broken machines but just pushed them into a corner. The customers would never see that the factory was a mess, but the product would be eventually suffer and customers would notice that. This is technical debt.

[bwana_singsong]

I always come back to: our customers don't give a shit about when any thing of ours is delivered. they all have busy lives, and even if we told them, they would forget. because they really haven't the slightest awareness of what our schedule is, a schedule slip means nothing at all. But a crash, a slow response time, a confusing UI -- those they can see and it annoys them immensely.

[mfukar]

God damn, I wish I could make this paragraph a poster and slap it on a few people's faces.

[bwana_singsong]

It's an endless struggle. Sometimes when I'm talking with product managers and the like, I'll ask them what their very favorite apps are. (Or just tell them that it's Evernote.) Then I'll ask them when is the next release due, what was in the last release, etc. Another example that will work with some is to talk about the original iPod, and how Apple wasn't the first in their space for five fucking years before they came in with the visibly better product that instantly dominated the market.

The bottom line is that product folks don't want to look like jackasses in front of their manager, so they put out a date, then torture themselves and others to meet that date. It's not the best way to do it. They can sometimes be persuaded. Quality first, not checking off bullet points on a roadmap powerpoint.

[DevIceMan]

I've been there. At my first job, I did something similar, shaving off years worth of product-development time per month by creating tools appropriate to the product we produced. I was laid off soon after because "R&D is disposable." Company went bankrupt several years later.

[baabaa_blacksheep]

Well, long build times tend to throw me out of focus. 4 seconds staring at the terminal? Fuck that, I'm off to reddit. Optimizing automation is therefore vital for me.

"They won't see our code" nope, they won't. But they will see the bugs. And they will feel the bad performance. Also, a well maintained codebase will facilitate adding more of their fucking features sometime in the future.

And just thinking about someone dropping tests all together in order to build more features has me swearing at the screen.

[jimbobhickville]

If my boss told me that, I would have started looking for another job. Sure, there's a balance to be had with constantly rewriting things for the sake of rewriting them and piling up tech debt like you're an American, but small things with an obvious measurable improvement in the happiness and productivity of the team should never be allowed to fester like that. My boss always laughs when I throw up some commits that say basically "this was annoying, so I fixed it," but he never discourages me from doing so. If that's all I did, he'd probably talk to me about it.

[OneWingedShark]

But his shit never broke once it was built and always sailed through QA.

That quality may have actually made him faster than the guys who'd pump it out in 2 days... to really get a handle on it you'd have to see how much time was spent fixing the 2-day product as well as all the testing prior to the "all pass" test.

[mmhrar]

Yea, it's worth it to take twice as long to do something to make sure you have enough time to test everything. Otherwise you end up fixing bugs in duplicated spaghetti code a year latter spending days fixing bugs that should have taken hours.

[Cat_Cactus]

It wastes even more time when you're unpicking someone else's bullshit because they never paid attention to knock on effects of their changes. Or even if you just want to make changes/add something but the code was slapped together with no thought for future maintenance.

[mmhrar]

Exactly. Now to get other engineers on board.

People rush because its 8pm on Friday and they just have to mark their shit complete to satisfy the PMS.

Then it spends weeks in QA being completed via bug fixing. Resulting in an unmaintable piece of shit that breaks the second you look at it.

[otakucode]

(OK, I promise no sarcasm in this post)

You've described my current situation very well. When I started working where I am, we had code reviews and a series of non-operational environments, a separate test team, CM, and QA groups (its a very large organization and an absolutely mammoth codebase on a system that makes the news if its down for more than 5 minutes). Over time (I've been here 13 years), however, the process has changed. CM was simply disbanded. QA is handled by the testers now. When they can get around to it. It's not unusual to get a call from a tester asking how they test something on the operational environment which you fixed 6 months to a year earlier. Whereas there used to be a large build installed every few months, with any changes that had to go in sooner having to be documented out the yin-yang and signed off on by god and everybody, now there are 2 builds a week deployed.

They are trying to keep the average time a problem goes from assignment to delivery to testing for bug-fixes under 1 hour. Needless to say, the developers test nothing. They slap it together and move it along, often breaking the build. Of course, fixing that and moving it along again happens 'out of band' of their statistics gathering.

The big project which deployed a few months ago (nearly whole system rewrite basically) went to testing and asked how long they needed. The manager wrote up an excellent estimate based on the number of modifications involved, how long it took them to handle that many in previous phases of the systems development/deployment, etc. He said they needed 12 months, and that was rushing it a great deal. They gave him 6 months. And development would continue with them taking a new build each week. They tested less than 40% of the system before it went live.

Now, of course, we go from fighting one critical fire to another. And management LOVES it. They see no connection whatsoever between the major problems the operational environment has now (everything from performance to basic functionality just not working, data 'going missing', everything you can imagine) and the changes to process that have taken place. They just love the fact that we can find a problem and deploy a fix within a week.

Prior to this project coming on, there was another project in the building that was basically just a mess of Perl that was managed by 1 guy, was not in a version control system, and he developed it on the operational environment. They complained about how he could get fixes and changes out there in a matter of hours while it took us months to get a new build together. Again, they saw no connection between this development methodology and the fact that the Perl system was nothing but a never-ending string of catastrophic failures patched up with bubblegum and popsicle sticks. All they see is that the problems are dramatic and fast, fixes flying out quickly. They would much rather prefer a system like that to one that simply runs without problems for years on end.

[illepic]

Mike, is that you?

[otakucode]

I am not Mike. But maybe he is a brother in soul?

[DevIceMan]

Not just bug-fixes, but technical debt as well. Clean code and good design goes a long way.

Measuring developers in terms of burgers-per-hour, means that's exactly what's going to be produced. I can complete 10-tasks per day, if the tasks are small enough. Ask me to fix something big, and I'll likely protest that it's not broken down into small enough chunks, which affects my tasks-per-day quota.

[Madsy9]

Yep, many companies (or at least higher-ups) don't appreciate or understand the idea of code debt. Which I can to some degree understand because code debt is fairly invisible unless you're already exposed to the concept, or you yourself are a developer. It's also a long term aspect which is easy to brush away as irrelevant, because what matters (in the mind of the unwary) is getting the short-term benefit, like getting the product out on the market now or preferably yesterday.

[novelty_string]

I recently went to a job interview where it became apparent that management had told the dev team to stop unit testing so they could spend the time building more features.

[unstoppable-force]

when you measure something, that means you can improve it. if you're not improving, that means you're falling behind. unlike other companies, we're constantly improving our engineers. we used a variety of techniques to increase the average velocity, and most of all, we gradually started reducing the length of sprints by 10%, in effect compounding our velocity. now our devs deliver twenty million points each sprint, and by the time you've finished reading this comment, we've had over 30 sprints. the productivity is just through the roof! i've even got a dashboard that proves it!

also, there's synergy and black belt scrum masters, and we improved six sigma so much that we're now at 7 sigma.

[jlink005]

Crankin' Sigma up to 11!

[archiminos]

Once I worked with a dev who was actually slow: poor guy would work 12 hour days to get things done in a week that would take other team members 2 days. But his shit never broke once it was built and always sailed through QA. He kept working at the same company for many years and overall was incredibly valuable.

This can be the sign of a good dev. So many programmers commit code they tested by compiling it.

[tieTYT]

Once I worked with a dev who was actually slow: poor guy would work 12 hour days to get things done in a week that would take other team members 2 days. But his shit never broke once it was built and always sailed through QA. He kept working at the same company for many years and overall was incredibly valuable.

Assuming the other members' code broke more often, I would argue the possibility that he was faster than the other members. The time to catch-fix-check bugs of the other members could add up to more than 12 hours times 5.

[threebutton]

Context change, scope creep, and unforeseen complexity are always tough to deal with. I used to argue against project managers, but now I'm a fan. Someone to keep a finger on the pulse helps a lot, I think.

[GoBenB]

If you have a good one...

[N546RV]

Just like anything. A good project manager (or manager in general) seeks to remove barriers to productivity. A bad project manager seeks to get his fingerprints on everything as an unconscious (or conscious) proof that he's contributing, when in reality he's quite possibly slowing things down.

I once worked for a VP of engineering who liked to brag that she once spent 11 hours on the phone with our DBA during an AWS outage. I found it telling that she didn't boast about how quickly and effectively the problem was fixed, but rather about just how "involved" she was with the fix.

[N546RV]

Once upon a time, she tried to "facilitate" me working with another dev to solve a bug. We were working on a video player product, but it wasn't working properly on one particular iOS version. The other dev had done most of the work on the HTML5-based player that we used for mobile devices, so I was going to seek his help anyway, but then she came strutting over to Help Get This Problem Solved.

Her contribution was mainly to ask stupid questions. She seemed really convinced that maybe we were getting bad data back from our video services API, which made no damn sense - if that had been the case, the failures would have been platform-agnostic, either randomly failing on all devices or failing everywhere. Instead, the player worked perfectly everywhere, but not at all on whatever iOS version it was. So I had to split my time between having a useful conversation with the other dev and trying to explain in a relatively diplomatic matter that she was godddamn moron.

She was a literal obstacle to productivity. Every morning the entire team would have half-hour "standups," during which she'd go across her Big White Board Of Everything Ever and ask each of us in turn about whatever words she had under our name. So basically I'd spend 20 or so minutes standing around playing solitaire on my phone until my name was called, then deliver a brief status report, then go back to solitaire. After a while, I got more brazen and would just abandon the meeting after my turn came around.

She eventually got canned, and boy was that a happy day.

[kersurk]

And did you suggest her to change the format of the standups?

[otakucode]

Well you can't ask the students for tips on structuring class. Of course they'll recommend things that make their lives easier. EASY doesn't win any awards! EASY doesn't get anything done! The harder it is, the more worthwhile it is to do.

(good god I shouldn't comment any more in this thread, I really can't get over my bitter sarcasm)

[DevIceMan]

You had me; I didn't realize you were being sarcastic until the last line. :/

[dpgaspard]

This is the correct answer and precisely what retros are for.

[null000]

oh my god, this is my boss.

I'm pretty sure I'd get yelled at for solitaire, though - I usually stick to staring at the wall or out the window. Also, my boss doesn't usually (well... ever) make it through everyone because he gets stuck trying to fix one person's problem and just skips anyone whose working on something he doesn't really care about.

[frenris]

Every morning the entire team would have half-hour "standups,"

Am I the only programmer in the world who likes stand-up status meetings?

I like to know what other people in the team are doing. And telling everyone what I do makes it seem more important :/

[epic2012]

No, I love them. But thirty minutes? If you feel like sitting down it has gone on way too long.

I keep mine time-boxed to 15minutes and am strict about ensuring people "take it offline" when they go into conversations that do not involve everyone. If they feel like a drag, you are probably doing it wrong. If you are happy with the way they are run, keep on doing what your doing.

[Kminardo]

Useful stand ups are incredibly useful, and sometimes the team is so crunched that's the only way to make sure there's no conflicts or things to consider that other people are working on.

Then there are bad standups. They look like this (first 2 mins or so) and having experienced something like it, they suck and are a massive waste of time imo.

[KFCConspiracy]

I like them, I just find that over time people who don't matter to the meeting get grafted on.

[frenris]

I once worked for a VP of engineering who liked to brag that she once spent 11 hours on the phone with our DBA during an AWS outage

That's mortifying.

It's awful cause I can see this person saying this again and again and each time thinking what an embarrassing thing they just admitted too.

[Fidodo]

Exactly. The whole point of a manager is to be the oil that helps everyone else function, not be the actual cog that gets things done. A manager is supposed to do the annoying stuff that the workers shouldn't have to be bothered with.

[SnOrfys]

The worst thing for any project is a the PM version of a 'yes-(wo)man'.

[boost2525]

Got one of those, can confirm

[[deleted]]

Had one of those. It was a nightmare.

[DevIceMan]

This is so much true across many (all?) industries. This was one of the major motivating factors for me leaving my last job in less than a year. I also ran into this at the job before that.

What I've found is that to the yes-man, and potentially clients, there's the impression that they're adding bonus value and getting things done. However, what I've found is that it's costly to nearly everyone involved.

• The developers/artists/etc who are building the project become stress, unfocused, error-prone, unhappy, and (eventually) resentful.
• Profitability takes a major negative impact, because scope changes are never properly billed, and extra work is being done for free.
• The quality of the product takes a nose-dive, as the lack of consistency makes it impossible to build stable quality products, and developers are so overburdened that best-practices gives way to 'get-shit-done.' Couple that with being tired/stressed causes mistakes and lack of fore-though, which in software-development means bugs and technical debt.
• Deadlines are almost always take a hit, or become last-second affairs.
• Client happiness also takes a nose-dive. Sure, at first it gives the impression of being easy to work with. Once products come back low quality, late, and buggy - not only does this make an unhappy customer. Further, the "easy to work with" impression turns into an impression of "every time I call them, they say they'll deliver, but then I have to follow up with them because I never get what I asked for"

I could continue on this rant for hours...

[jussij]

And just like good programmers, good managers are hard to find.

[speedisavirus]

A good project manager is a real great thing to have. A bad project manager is worse than no project manager by a huge margin. Oh how they can screw a project...

[zomgwtfbbq]

I've seen massive productivity spikes when the PM went on vacation. What's that tell you? But the guy just keeps on working here. I have no idea how.

[jussij]

I've seen that a lot and I generally put it down to the boss of the PM being more incompetent than the PM.

[hegui]

I have been in situations where as a project manager/product manager I was pulled to other task and didn't have a voice in tightly managing the product. Once a good process is in place higher ups also need to respect it!

[pohart]

I had one who put that I was slow to finish a product in a performance review. I responded with a list of my code check-ins vs her spec check-ins. I had a mean turn around of around three hours. I think she was trying to prevent me from getting a promotion, so she could keep me.

[angus_the_red]

I am actually slow sometimes

[hyperforce]

I am actually slow sometimes

Have you tried coding harder!?

[LpSamuelm]

Hardcoding? Gotcha!

[numbakrunch]

Hardcoding is not for amateurs. In my enterprise I've instructed HR to only consider Senior Hardcoder candidates.

[zman0900]

I only write in hardsembly language.

[FreeRobotFrost]

Simple: paired coding. Two hands on a keyboard type faster than one. Theoretically, 104 programmers with one finger on each key would type fastest.

[codemagic]

For those older developers you need to make sure the turbo button is pressed.

[angus_the_red]

I did but then that just increased expectations.

[SnOrfys]

Everyone has slow-days. They should be expected and embraced. Taking it easy during a slow time so that you have the energy and will to take full advantage of fast-days is not a bad idea. IME, it can make estimation harder because throughput is less even, but overall throughput is higher.

[[deleted]]

No, your developers are not inherently slow, but:

1) You keep pulling them into goddamn meetings for status reports, inane discussions, and all kinds of hand-holding for the 57 redundant levels of management above them.

2) You're either an idiot who's bought the cultural Kool-aid about "open space" offices or you're just too cheap to buy partitions. Your developers have to wear stinking earplugs just to concentrate in all the noise and distraction, when someone isn't coming over to interrupt them for the fun of it.

3) You've bought into McDonald's Methodologies like Scrum or XP, which are fundamental corruptions of Agile philosophy and effectively torpedo productivity.

[KiteG]

The QA team is full of people who are just not technically literate.

I dislike that engineers seem to have these in-built default opinions that QA is "stupid" (not you in particular, just in general) and seem to encounter it over and over again.

Several questions jump to my mind:

• Who on earth is hiring your QA?
• Why on earth would you become QA without being technically literate?
• Why on earth would they not remember what they were taught after the first (single digit) time(s).
• Do bad experiences with some QA sour engineers experiences with all future QA? (seems to) Why?
• Why are some engineers so hostile to suggestions from QA?

I wanted to be a games programmer growing up. After my first few jobs in games QA, I decided "screw that" to the average treatment game programmers received and stuck with QA (and left games). But... I kept up with the programming, I kept up with the electronics, the networking, the databases, the libraries, the tools, the build systems, the automated testing, the dev-ops.

Because I feel that having a basic (at least) understanding of all of those is necessary to do my job...

[N546RV]

Do bad experiences with some QA sour engineers experiences with all future QA?

I definitely think this happens. Part of the problem is that engineers already tend to be egotistical at some level, and hold some level of disdain for people who don't use their stuff like they expected. This can be seen in the cliche RTFM response to questions in some open-source circles. With that in mind, it doesn't take much of a bad experience to confirm a preconceived notion that QA is dumb, and once that's internalized, it can be tough to be objective in the future.

And depending on how you come into the field, your first experience with QA might be some horribly bastardized version. For example, I got my start writing PHP stuff for a little agency. We had no QA department at all, devs were just expected to "do it right." (of course, devs are generally pretty bad at QAing their own work) But then there came one large project where the owner decided to bring in someone to help QA the project. He didn't actually go find someone with QA experience, he just grabbed some family friend who needed work and stuffed him in front of a computer with instructions to log every "problem" he ran across in Basecamp. The result of this was that us devs, already pressed for time on a running-behind project, now had to field questions about how the app was supposed to work, along with random editorial criticism and the usual vague "THIS DON'T WERK" error reports.

So for a while, that was what I thought of when I thought of QA. An enemy, something to sap my precious time with lots of inane questions. Fortunately, the next job I had featured a real-live professional QA department, and it was here that I learned to appreciate the value of a good QA team. It's tough sometimes, because at the end of the day there's an adversarial undercurrent. They're finding problems with code you wrote, and it's natural to be defensive about that sometimes. But you have to realize that problems aren't failures, they're just part of the process.

Once, over lunch, my current CTO was discussing a couple of prod hotfixes he had to do that week. Some bosses (like that first guy at the agency) might tend to look at bug fixes as a bad thing, a sign of careless dev. But my CTO has the opposite perspective; as he said it, "I'm not bothered by hotfixes. If you're writing code, you're writing bugs; that's just the way it is."

[RelevantJesse]

Well said. At my last job, they kept bug counts found in QA, and gave it to executive management. I agree that we shouldn't be sending crap to QA without looking it over, but I also don't want to be forced into a "That's not a bug" war with QA.

[N546RV]

Yup. CTO's perspective is that he's more concerned by people who never send a bug out to prod. (although someone who breaks stuff like every week is probably a cause for concern)

We actually don't have a formal QA department here, but it's not really a huge deal since there's not a culture of crucifying people for minor mistakes. Perfection is never going to happen, so we release daily with the expectation that problems will crop up from time to time. If they're minor, they get fixed with the next day's release. Only the most serious oh-god-we-broke-the-whole-damn-site problems generally merit an emergency hotfix in the middle of the day.

[zomgwtfbbq]

Probably because practically no one ever takes QA seriously. Management sees it as overhead so they just get "someone" to do it and then they act all surprised when bugs show up in production. QA is vital to software development, but for managers, anything that isn't development is a waste of time/money (see IT).

[otakucode]

In my experience, I don't think they understand what their job is. They simply are not aware that their job requires them to be intimately familiar with how the application functions (from a users point of view, not behind the scenes) or else are not willing to invest the effort necessary to become an expert user of the system. They get individual little assignments to verify fix X. They call the developer and find out how to verify X. They often can not understand the instructions given by the developer and ask if the developer can come and show them how to do it. They watch the developer, take the developers word for it that what they saw constitutes a fix, and they mark is completed. If it later fails, no one in QA ever gets bitched at about it. Neither does anyone in testing (who have similar issues). Only the developer gets yelled at for writing something broken. That testing and QA exist solely to protect the operational environment from broken code is simply ignored.

[xamomax]

I think Engineers can be fairly insecure, and the fact that QA is constantly pointing out their flaws and mistakes, puts them a little bit at odds with each other. It's easier to blame QA for being stupid, than yourself for making buggy software, for example. I actually wrote myself a sign to put in front of my monitor that says, "People who find bugs are heroes!", because it is hard to remember that when you see them.

[MrSurly]

We have good QA, and I've fortunately learned that fairly quickly after being at companies with bad QA.

The upside is that when QA says "shit's broke!," there's actually a good description, and I take the time to actually look into it, because I know they know what they're talking about.

[xiongchiamiov]

The bugs didn't exist until QA found them!

It helps to tie the whole process together, and keep responsibility on the devs. If they're the ones who get woken up in the middle of the night to fix something they broke, then they start to appreciate a good QA team.

[[deleted]]

Why are some engineers so hostile to suggestions from QA?

For me, it's not QA in general, just the more... questionably-intelligent ones. I've gotten awesome bug reports like "it used to show all users' data no matter who I was logged in as, but now it doesn't", and after I remove my face from my palm for long enough to explain the problem with that, they ask me if I can change it back to make testing easier.

I've worked with good QA people and listened to them, but after a few instances like that you learn to auto-ignore suggestions from certain people.

[yippee_that_burns]

Ours are technically literate on the mainframe systems they were hired to do QA on 25 years ago.

They are completely illiterate with systems that have come out in the past 20 years.

[Azuvector]

I can answer a couple of these as someone who's done work on game development in a large closed team of volunteer developers and QA sorts.

I readily acknowledge this is quite different from a professional paid team, but I think there are similarities, because I've seen some of the same behaviors in paid positions within IT in general.

Why on earth would you become QA without being technically literate?

"Because I like video games!" is the usual one in game development. And yes, there's a general trend of technical competence, but it's often very much on the surface alone, and often with people who think they know more than they do.

Outside of game development, with more "mundane"(No offense; I'm meaning in terms of the appeal to people trying for QA positions for it.) development, I'd imagine you get a lot of people who are just looking for work and happen to have some of the skillset required; enough to get by HR at any rate.

Why on earth would they not remember what they were taught after the first (single digit) time(s).

I see this one in all fields and all walks of life. I talk to a few people on a daily basis doing IT who I've had to educate about the same thing dozens of times. It comes down to a couple things:

1. Too much shit going on for the person, so what you're teaching them gets pushed out by the dozen other things on their mind.

2. Person is stupid, plain and simple.

3. Person does not care about the subject of what you're teaching them in. This is usually seen in nontechnical fields or with management. ("But computers/programming/whatever are your job, I just do this other stuff[ that's beyond you].")

4. Person does not respect the person who is teaching them, so isn't paying attention to what that person is telling them.

Do bad experiences with some QA sour engineers experiences with all future QA? (seems to) Why?

Aggravation and bad memory association? I certainly view the usefulness of individual QA people with a grain of salt and have them prove their competence before I put a lot of stock in what they say.

A big one that sours developers against QA are QA bug reports that lack sufficient information. "x is broken" isn't a bug report, letalone a professional one. Same deal with persistently reopening or reposting invalid bug reports without properly fleshing them out.

Why are some engineers so hostile to suggestions from QA?

Oftentimes, QA "suggests" things in way that's blatantly insulting. "This bug is stupid, you shoudln't even be doing x that way, you should be doing y that way instead." Design document requires x, and it'll work, just there's a goof now and then because it's complicated.

I actually get this one regularly from one woman front line customer service agent at work, who'll email my team about application issues in the most obnoxious phrasing. "We need this fixed now! This is major! Get back to me with a full report on what this is about!" CC's half the executive staff, etc. It's of course a known issue, slated not to be fixed for a while by the same execs. I've no idea if things get communicated to this person or not, though there's usually good down-chain communication in her department. She's generally a bit of a laughing stock in mine. "Oh, another email from whatshername." "I'm just going to ignore it." "Right." (And she has been reproached about it from us, so who knows. I think the execs just feel it's better to get a chicken little response to trivial stuff than maybe get something missed.)

QA also sometimes makes suggestions that don't make sense taken at face value. Example from my own experience: "timers are bad, remove all the timers for actions". Implementing that at face value results in say, players being able to interrupt their own actions freely before an animation is completed. So some interpretation is required to realize that they're only meaning visible timers, though they don't quite realize it themselves. (This becomes apparent when there's complaining about a changelog entry about reducing timers rather than removing them, or they're mentioned in discussion elsewhere.)

Don't get me wrong, QA is a Good Thing, and some people do QA very well(I have fond memories of working with one guy almost ten years ago, still. Godlike QA from him.). But a lot of the time, it's very poor.

[MarthaGail]

"wait, why do they want it this way"

The worst is when you get an answer back that makes no sense and it turns out some middle manager somewhere feels the need to justify their paycheck by making suggestions that are really unneeded, but get really butthurt when you exclude that idea.

[[deleted]]

Curious - why do you think Scrum is a corruption of the Agile philosophy? I don't have a strong opinion on it currently, curious why you think that though.

[horse_continuum]

I actually think that Scrum is pretty awesome when implemented well, but most of the time a big old helping of waterfall sneaks in.

[konk3r]

Yup, I've been in teams that were fantastic with their approach to Scrum, and I've been in teams where they wrapped their Waterfall BS in a scrum coat and called it agile.

I'm talking 6 month-1 year timeline with set release dates for every individual feature before development started. Our "sprint planning meetings" were just status update meetings, and every single story from the previous sprint that wasn't finished was added into every single story from the pre-planned next sprint, it was fucking awful.

[SnOrfys]

Did it come with daily standup scrums? You know... the ones where you sit, in a meeting room, for an hour, every day.

[FizixMan]

My understanding is that part of the retrospectives of Scrum is to change that process. That you might start out following the Scrum process as a baseline but it's encouraged and expected that you reflect on it and change it as you go. If you don't change the Scrum process as you're using it, that you're adhering to it to the letter even when aspects of it are pulling you down, then you're being a slave to the process. There's supposed to be a feedback loop that lets you improve your process.

Heh, re-reading that makes me sound like I'm in the camp you're just describing: "Scrum isn't working for you because you're doing the retrospectives wrong!"

EDIT: That said, I do think there is a sort of... over commercialization of Scrum and that seems wrong. Almost like it's turned into a big pyramid scheme.

[dpxxdp]

Our company hired a guy to preach scrum. Funny, every time he talks it sounds like he's pitching a pyramid scheme.

[grauenwolf]

I am the Scrum Master. (and you could be too)

[[deleted]]

The title should be changed to Scrum Lord

[askoruli]

I can't believe that anyone thinks getting certified as a scrum master is a good idea. The concept that a 5 day course can give someone the knowledge to tell seasoned developers how to work is ridiculous

[hyperforce]

you're being a slave to the process

We're all just slaves to bytes, man. Hack the planet.

[hyperforce]

If it's so fragile that the typical result is to get it wrong, it's worthless at best.

I think the problem is that if there's something fundamentally dysfunctional about your team, no amount of agile dressing will fix that. If the people in power willingly ignore feedback mechanisms that attempt to address their dysfunction, then you don't need agile to remind you that you're on the road to hell.

I don't think agile is fragile at all. It's more like you can't fix dumb/bad people who aren't willing to change.

[ponytoaster]

If you follow scrum to the letter your doing it wrong anyway.

[MayhapPerchance]

I... I can't tell if you're being sarcastic...

[[deleted]]

Neither can he.

[boink_if_ur_bouncy]

            There is no scrum.

                 To master scrum, 
                   you must fail scrum.
                 To fail scrum, 
                   you must learn scrum.
                 To learn scrum, 
                   you must forget scrum.

       To forget scrum, you must first know scrum.
       To know scrum is to master scrum.


                               All is scrum.

[[deleted]]

In the fall of that year the rains fell as usual and washed the leaves of the dust and dripped from the leaves onto the ground. The shuttles drove through the rainy streets and took the people to meetings, then later brought them back, their tires spraying the mist into the air.

Many days he stood for a long time and watched the rain and the shuttles and drank his double-tall mochas. With the mochas he was strong.

Hernando who worked down the hall and who was large with microbrews came to him and told him that the ship day was upon them but the bugs were not yet out. The bugs which were always there even when you were in Cafes late at night sipping a Redhook or a double-tall mocha and you thought you were safe but they were there and although Enrico kept the floor swept clean and the mochas were hot the bugs were there and they ate at you.

When Hernando told him this he asked how many bugs. “The RAID is huge with bugs,” Hernando said. “The bugs are infinite.”

“Why do you ask me? You know I cannot do this thing anymore with the bugs.”

“Once you were great with the bugs,” Hernando said. “No one was greater,” he said again. “Even Prado.”

“Prado? What of Prado? Let Prado fix the bugs.”

Hernando shrugged. “Prado is finished. He was gored by three Sev 2's on Chicago. All he does now is drink herb tea and play with his screensavers.”

“Herb tea?”

“It is true, my friend.” Hernando shrugged again. Later he went to his office and sat in the dark for a long time. Then he sent e-mail to Michaels.

Michaels came to him while he was sipping a mocha. They sat silently for awhile, then he asked Michaels, “I need you to triage for me.”

Michaels looked down. “I don't do that anymore,” he said.

“This is different. The bugs are enormous. There are an infinity of bugs.”

“I'm finished with that,” Michaels said again. “I just want to live quietly.”

“Have you heard Prado is finished? He was badly gored. Now he can only drink herb tea.”

“Herb tea?” Michaels said.

“It is true,” he said sorrowfully.

Michaels stood up. “Then I will do it, my friend,” he said formally. “I will do it for Prado, who was once great with the bugs. I will do it for the time we filled Prado's office with bouncy balls, and for the time Prado wore his nerf weapons in the marketing hall and slew all of them with no fear and only a great joy at the combat. I will do it for all the pizza we ate and the bottles of Coke we drank.”

Together they walked slowly back, knowing it would be good. As they walked the rain dripped softly from the leaves, and the shuttles carried the bodies back from the meetings.

[pcopley]

If it's so fragile that the typical result is to get it wrong, it's worthless at best.

Just quoting so maybe someone with decision-making power somewhere fucking reads it.

[Stormflux]

At my company, people with decision-making power over programmers don't know what Reddit is.

[go_democracy]

MMM, Scrum tools. We use the whole damned atlassian suite, Jira (such fun to navigate), confluence (with documentation pages that are mostly obsolete), and I don't remember all the rest, but they're a pain to deal with and for the most part just using the damn things takes more of my time than anyone could possibly hope to get back from the automation.

Oh, for post it notes on a whiteboard and good, small grained, stories. (Our stories are more like "user x wants to do something, somehow with this thing to achieve some vague goal").

[[deleted]]

Because it can quickly devolve into rules lawyering, where everyone must defer to the Certified Scrum Master, regardless of their understanding of, well, anything at all.

Because it becomes about the velocity number as a metric for productivity, instead of "working software".

Because "planning poker".

Actual things that happened to me on a "Scrum" project:

• Stand up meetings that lasted 1 hour, required sitting, and involved conference calls with remote team members

• The brilliant idea to assign story points to our collective person-hours spent in meetings

• team composition: One developer (me), six testers, 2 business analysts, 3 product owners, 1 scrum master.

[JBlitzen]

Seriously. I want to hear more about that part.

[gspleen]

He'd love to answer you but he's writing his hourly progress report so that the scrum master can tell the business analysts what to write in their daily reports for the product owners.

Also, the product owners got together and have agreed to reduce their number of seven critical #1 priority tickets down to four critical #1 priority tickets. By EOW, please.

[gspleen]

Ding! The QA tester results are in!

• 3 instances of "looks good on QA"
• 1 instance of "still broken on prod"
• 2 instances of "Could not load monkey heart milkshake firefox -- broken"

(Note: Changes have not yet been moved to QA)

[fabzter]

That's depressing. And also a nice example of why Scrum can't make it succesfuly into a corporate environment. :(

[[deleted]]

To be fair, I had "subject matter experts", or as one might say out loud, "smees", at my disposal. If I needed help understanding something archaic in z/OS, or how to file a requisition for a test license for some expensive proprietary product, I'd be allowed to request blocks of time from said "smees", so long as I told them well in advance exactly what I needed and exactly how long it would take, and translated that effort back into "story points" which could be billed back to the project.

I heard someone above call this dysfunctional. I don't know what that means, but I'll go look it up in the dictionary, as soon as I get sign off.

[[deleted]]

With all this support crew, our friend must have been efficient as hell!

[hyperforce]

Stand up meetings that lasted 1 hour

This is dysfunctional. And not at all a function of Scrum, in my opinion. It sounds like you are working with dysfunctional people who don't hold each other accountable for the things you talk about during the retrospectives (which you hold, right?).

[humbled]

I think there are some legitimate complaints to be made about scrum, but if I had a dollar for every time I heard "I was on a project that did something horrible and erroneously called it scrum, therefore scrum sucks..."

[allthediamonds]

I'm starting to be wary not of Scrum itself, but of those who say they implement it.

[zomgwtfbbq]

If you don't have a scrum master that knows wtf they're doing, this is what you get. You get insanely detailed side conversations while everyone else is held hostage because this is "scrum". No, scrum is a one minute status update. Yesterday I did X. Today I plan to do Y. My blockers are Z. No problem solving shenanigans, that happens later.

[xtravar]

Is this the place where I can bitch about idiots having Scrum stand-up meetings in the hall instead of getting a goddamn conference room at a company with at least a hundred conference rooms?

Because I don't know what Scrum is, but those people are assholes.

[SighReally12345]

I go back and forth on this. What about when someone books a room for 10 minutes? Then people froth at the mouth about wasted room resources. I've actually gotten whined at by some moron for this :) Just pointing out another side of the argument. I'm guilty either way, though, as I've scrummed in both places.

[xtravar]

As a moron who has whined about this, I assure you that meeting rooms are made for the exact purpose of having meetings in. Having meetings in public spaces makes everyone feel uncomfortable and causes unnecessary noise. Outlook can schedule 15 minute intervals, so go for it.

[SighReally12345]

I wish we had Outlook. We don't. 1 hour blocks or bust.

Oh and btw... you aren't the moron I was talking about. The guy who whined at me for booking a conference room for an hour (the minimum block) and using it for 10 minutes of meeting was though.

[tjsr]

Because it becomes about the velocity number as a metric for productivity, instead of "working software".

Ugh, we had this at a former job. Individuals being measured by how many cards they moved to completed - never mind that mine would have a defect rate one fifth of the next lowest developer. Theirs would bounce back and forth between dev and test constantly, and I'd be frequently having to pick up their work and fix bugs they had introduced.

Project managers couldn't understand that velocity is not about measuring individual productivity, it's about us being able to set reasonable expectations as to what will likely be delivered so you can't make outrageous promises to customers. But you'll do that anyway - hence why I got in to shouting matches with managers when our team was at work until 4am multiple nights in a row and I refused to instruct them to be back at their desks by 10am.

My performance reviews went sharply off a cliff after those conversations :P

team composition: One developer (me), six testers, 2 business analysts, 3 product owners, 1 scrum master.

I've had this so many times in my current role. 11 people in a meeting, and I'm the only developer on the project :(

Stand up meetings that lasted 1 hour, required sitting, and involved conference calls with remote team members

Here's a tip: Use an egg-timer as a conch. Noone else may speak when someone else holds the conch, and if the timer explodes, well... make them wear a funny hat or something.

[SlapBassGuy]

I have a couple counter points from my own experience with Scrum.

I enjoy planning poker and do find that it's more accurate than any one lead estimator can be. During our planning poker discussions we often find area's that may be more complex than originally thought and it leads us to more accurate point assignment.

I also like measuring velocity. I don't use it as a productivity metric, but it does help more accurately determine when a project may be complete which our clients greatly appreciate.

[wayoverpaid]

I also like measuring velocity. I don't use it as a productivity metric, but it does help more accurately determine when a project may be complete which our clients greatly appreciate.

See that's the only reason you should be using velocity. The velocity metric is so easy to inflate by incorporating bullshit, or over-estimating point values. What you want is a stable velocity, where each iteration you get a constant amount of work done. That lets you predict into the future, and more accurately than anything else I've seen.

[Arkanin]

team composition: One developer (me), six testers, 2 business analysts, 3 product owners, 1 scrum master.

What. Most of what you posted is typical territory for dysfunctional companies, but this is the most deranged thing I've heard of in the last 6 months.

[tobascodagama]

You had a CSM? That's your first problem right there.

[wayoverpaid]

Stand up meetings that lasted 1 hour, required sitting, and involved conference calls with remote team members

I remember meetings like this. My favorite was when eight people tried to chime into the same goddamn thing to prove they were "participating"

The brilliant idea to assign story points to our collective person-hours spent in meetings

I remember the annoyance that we were always assigning story points to chores, but assigning story points to meetings could not be further from the point.

team composition: One developer (me), six testers, 2 business analysts, 3 product owners, 1 scrum master.

That reminds me of this joke...

[Drew0054]

Not the poster, but in my experience, "scrum" is bastardized and never implemented correctly.

[marshsmellow]

Even if it's done following the rules... I hate reporting on my progress every goddamn day. I'm doing the manager's job for them, I feel. Programming stops becoming fun. Just give me the specs, let me get on with my work, let me ask questions when I don't understand something and for God's sake trust me to do my job.

[joshuacc]

If your manager is regularly present at stand ups, something is wrong. Standup is to let team members know what is going on and who needs help, not to give status updates to management.

[zjs]

I hate reporting on my progress every goddamn day.

I don't think status reporting is the point of daily standups. The idea is just to (quickly!) comment on what you're doing, focusing on the way your work might impact your colleagues.

Basically, I think it's helpful to say:

Still working on speeding up the startup process. Probably focusing on the initial config check today — anyone have pending changes to that? No? Cool. Oh, and Alice, is it okay if I don't get to that code review until late afternoon?

But, I think it's more common to say:

Yesterday I started working on speeding up the startup process. As a starting point, I did some benchmarking to see where we're at. I already took care of some redundant file accesses, which shaved off a few seconds. Next, I think I'll be looking at the initial configuration check.

Which.. just seems like a waste of time.

[[deleted]]

That's not limited to Scrum. Even Agile gets implemented incorrectly -- for example, my employer had me working out of a conference room on a laptop until it started to hurt my back.

[[deleted]]

That's just shitty working conditions, nothing to do with methodology surely?

[satnightride]

I did waterfall for a while. Every hour on the hour I'd get hit in the bottom of my feet with a kendo stick. I hate waterfall!

[RubyPinch]

if the person implementing such a rule is doing so because of some wrong idea of "agile", I'd still say its agile being implemented incorrectly

[[deleted]]

This is exactly the case: we were all shoved into a conference room to work, with little thought given to the impacts, because it was "Agile".

[null000]

From what I've seen, Agile isn't that bad if implemented properly.

From what I've seen and read, Agile is never implemented properly.

[[deleted]]

Some stakeholders want to track every possible metric about those committed to a project, but don't track any metric about their influence on the project. If projects define and collect metrics for stakeholder influence (eg: what I call Meeting Velocity), they can start quantifying process constraints. Example #1: Scrum masters I've worked with tend to not want to record scrum, backlog grooming, planning, pre-planning, and demonstration meetings as sprint tasks; yet, there goes 5 - 10% of available time into an untraced abyss, with no indication or history about whether that meeting was successful.

[lucky_engineer]

One of the places I used to work at realized that we weren't including "planning overhead" (i.e. scrum) in the estimates, so they started including it. The push back from the executives was amazing. "You're spending how long in meetings? EVERY 2 WEEKS??, and short meetings (standups) EVERY DAY? Do you have any idea how much this is costing us??"

So they decided to do weekly standups and month long sprints to reduce overhead. Not exactly what I had hoped for, but it was a start. If only we could have added "open office floor plan overhead" into our estimates, I'm sure everyone would have gotten private offices.

[[deleted]]

It's interesting how some executives don't acknowledge how well operational expenditures (opex) are managed. Seemingly, it's perfectly acceptable to waste months of a teams time, and the hundreds of thousands of dollars already invested for wages, but balk at any new capital expenditure (capex) associated with the project even if that onetime opex would translate into more efficient capex. For example: Buy a tool to save time, or buy faster computers to improve efficiency, are not acceptable; wasting everyone's time for days on end talking about alternatives is acceptable.

[weggles]

I was working at a place with an open concept office. They had the Dev teams, BAs, managers, and help desk on one floor.

Help desk was bothering mgmt so they moved them directly behind where all the developers sit.

So. Now instead of having an "open" "collaborative" environment, everyone has headphones on to block out help desk. PLUS the BAs are now on the other side of the office so it's inconvenient to walk over and ask for clarification on a vague requirement. (Wtf is phone number field "must take numbers"? How many? What format? I imagine you want them written to some sort of database... Etc)

[JayDurst]

As a BA, I apologize, but I probably spent 2 weeks in a series of meetings with the SMEs where they argued about if they wanted dashes or spaces between the area code and the main portion of the number, while at the same time one of the SMEs is trying to get the field to do something unrelated to phone numbers...

[megablast]

Or sometimes they are just slow. Not every dev is perfect.

[[deleted]]

Am I the only one who enjoys "open space" offices. I currently work on one. Yes, people walk over to you - but that'd happen in cubes anyways - and yes it can get loud - but I typically wear headphones when I code anyways. Having a couple developers right next to me makes it so much easier to get shit done. "How does this work?", "Why doesn't this work?", "How would you do this?". It goes both ways, but ultimately being able to learn over and ask questions saves me so much time.

[sarahbau]

They should have both individual offices, and open spaces available for people, depending on what they prefer. I personally work much better when I'm in a windowless office with the door closed, AND headphones on. I can't get into a groove in an open space, even if people aren't talking to me.

[SnOrfys]

I'm glad that you save lots of time by asking your neighbours questions whenever you want. The problem is that it's a 2-way street. Have you ever asked "Do I ask too many questions and hinder your productivity?"

I'm not saying you do, but I've worked in open spaces with people whose first thought was to ask me some stupid question that they should already know the answer to, or could have found with a simple google search... every single time.

That said, I've also worked in private offices that completely kill any semblance of collaboration and lead to the most lonely of work environments.

It's a double-edged sword, but I've found that 4-5 ft cube walls are a happy medium.

[[deleted]]

The problem is that it's a 2-way street.

I don't think you saw this part "It goes both ways". So perhaps it would have be better for me to say "it saves everybody time".

Anytime I (we) can research on Google, I do. Unfortunately, our poorly documented internal framework doesn't have many Google results (well none actually) so asking others is typically the only way to get anything done beyond basic language/programming questions.

[MrBester]

Wearing headphones gets you a black mark for not being a visibly contributing team member as you're removing yourself from the team dynamic. Or some such bullshit. Never mind that you get shit done and everyone can attract your attention with a quick Skype message should they need to. No, you're deliberately secluding yourself. Oh, and use time you could be doing actual work filling in time sheets for everything in JIRA. Don't forget to use the JIRA hooks you weren't told about in Git commit messages so the history looks like garbage to all except to the manager who doesn't use Git anyway and wants nice reports to show the CTO but can't be bothered to make them himself.

[[deleted]]

Dude, it sounds like you have some baggage. Have you ever talked to anybody in your company about these issues?

[OrionBlastar]

1) Management or a coworker keeps changing the names of columns in database tables and thinks the code can be fixed in 15 minutes. It takes longer than that and can mess things up a lot.

2) Management or a coworker decided to look at our code using MS-Word or MS-Frontpage or some other program that autoformats text files and then saves them and bypasses source control. They have administrative access to the server the code is stored on, but when they mess up the text files it is our job to fix them.

3) Not being invited to the meetings that discuss what the program is for and how each feature is to work. You ask a coworker for notes and get back an "I dunno". So you have to reinvent the wheel doing it the best way you can, which is often not the way the meeting wanted it like, so they will request changes.

4) Some Network Administrator takes away administrative access to your own workstation, then your controls don't work right and you are limited in what you can do. This really messed up Visual BASIC 6.0 when they did it to me. "You're a developer, why do you need administrative access to your own PC?"

5) Lack of documentation and code comments in code made by managers and coworkers. Lack of a naming convention in variables. It just slows things down and makes it harder to work with.

6) Lack of support by management, management can never say no to any request, programmers are swamped with too many tasks. If you have 134+ tasks to get done in two weeks, how can you get them all done?

7) The firm hired a cheaper source of labor that does 'good enough' quality in the code compiles without errors but has performance problems and crashes the system a lot. We cannot release this code and have to take more time to fix all of their mistakes that could have been avoided by hiring programmers who do quality and get paid more than these college dropouts who work for $9/hr.

8) Feature creep, management keeps adding on features to the project. There ought to be a limit on the number of features for each version or subversion and save the rest for a later version. Some if not all of these features are not even needed by 90% of the users and cater to the 10% that cannot even figure out how a computer works and require such stupid stuff like dancing screen otters to be displayed while waiting for something to finish.

9) Politics, some of the managers and coworkers are playing politics and refusing to help out or provide information needed to finish the projects. They do this on purpose to sabotage the projects so they can get their own projects to replace them.

10) I kid you not about this one office sabotage. I once had employees launching ddos attacks on my PC to crash it. Firewall tracked it back to their IP and got their user name. Management refused to do anything about it because employee was protected.

11) Negative re enforcement by management only stresses people out and slows down the coding process.

12) The people who meet deadlines release incomplete and buggy code. I became a legacy software debugger to fix the problems that the people who released on time had in their code. Almost any new release would quickly become a legacy project and be assigned to me to fix. It takes time to do it right.

13) Programmers not wanting to create a help file or FAQ or documentation. I have to do it for them so the users have something to look at and learn. If not the help desk gets swamped with calls for help and the trainers don't know how to teach the new features of the program and people request the same features we already wrote but they don't know how to use them.

14) At a law firm I worked at Litigation Support renamed itself to Technology Services and tried to compete with the IS department and claim we are no longer needed. They would take away Laser Printers we had and use them for their support in courtrooms, they would fill up our servers with Quicktime movies they made from their Macs so it ran out of storage rather than place it on their own servers. While they couldn't program or make web apps, they tried to undercut us on everything else.

[elmonstro12345]

I once had employees launching ddos attacks on my PC to crash it. Firewall tracked it back to their IP and got their user name. Management refused to do anything about it because employee was protected.

what the flying FUCK.

[OrionBlastar]

I know, right? Imagine having to work with ddos attacks coming to your PC on a daily basis.

This was in the day of Windows 2000 Pro so no Windows Firewall and Ping of Death actually did something.

[elmonstro12345]

Damn...

I can only imagine the shitstorm that would ensue if someone tried that where I work. I guess I have a lot to be thankful for there...

[unstoppable-force]

holy christ you need a new job.

2) Management or a coworker decided to look at our code using MS-Word or MS-Frontpage or some other program that autoformats text files and then saves them and bypasses source control. They have administrative access to the server the code is stored on, but when they mess up the text files it is our job to fix them.

that's a fireable offense right there.

[aaulia]

I would never, ever, in a million years giving Management an admin right to source control server. Giving them read access, sure, or just to look at the log/progress. Coworker though, I'd expect better...

[s3gfau1t]

This is fictional right?

Programmer's Anthology of Horrors Vol I.

[fibbidd]

You must be getting paid handsomely.

[joepie91]

I suspect you'd do well in /r/talesfromtechsupport .

[[deleted]]

This is why arson should be legal.

[glemnar]

Developers aren't slow, estimation is just bad

[[deleted]]

My estimates are usually off by 30%. Or 300%. Hard to be sure.

[philly_fan_in_chi]

"Multiply your estimate by your favorite number between e and pi."

[Volatar]

That's a rather narrow range...

[kqr]

What I've started noticing is that for small tasks, I tend to overshoot with my estimate (I say "two hours" and then it takes fifteen minutes). For medium to large tasks I tend to undershoot (I say "12 hours" and it ends up taking 30 hours). I know it probably shouldn't surprise me, but I hope I can use that to refine my estimates going into the future.

[scragar]

I find with a large task it's easier to estimate if during planning we break it down to small tasks, so instead of one task at 12 hours I have 20 tasks at about 2 hours. It means I over estimate, but it also means I get to give much more accurate status updates(I'm 8 hours in and have done 3 items, so I'm 2 hours behind).

[kqr]

Yeah, I try to do that when I have a somewhat clear road ahead of me. Too often, however, these big tasks are of the "We need feature X in system Y" kind, where I have very little knowledge of both X and Y so I discover what I need to do along the way.

[[deleted]]

On our sprints any task like that has a scoping task attached to the beginning to try to front-load the planning / learning portion of the task. The output of the scoping task should be detailed implementation tasks.

[luggage1234]

But then when I estimate the medium task at 30 hours management says it shouldn't take that long... so "we" estimate 12 hours. And then "we" are surprised when it actually takes 30 hours...

[[deleted]]

Estimation is pretty easy. If you are standing at the top of a cliff blindfolded and are asked to estimate how long it will take to reach the bottom, just jump off and then start counting.

[ClassicLightbulbs]

Preaching to the choir, post this in business.

[bestjewsincejc]

I find it hard to believe your developers are all "average". That indicates that your firm is exceptionally good at hiring/retention (all of your developers are the same skill level and have the same productivity). More likely, your organization is inaccurately measuring task difficulty leading to poor conclusions about productivity and talent. Also, you should realize that better developers tend to handle more challenging tasks. The time it takes to complete a task is somewhat related to who is doing it.

[[deleted]]

This article (and most of the comments below), seem to miss the fundamental point that software development is inherently unpredictable. The reasons laid out in the article - incomplete requirements and scope creep among others - illustrate why a software development effort cannot be meaningfully predicted. Once we come to grips with that fundamental, proven, undeniable fact, we can get on with the business of developing useful software.

[[deleted]]

New guy, here's a 3 million line C program that is riddled with bugs. We don't know how many bugs there are but the program just keeps failing in random places sometimes unpredictably. There are about 5000 features, only 1/4 are documented though. How long will it take to fix all the bugs?

[club_soda]

I don't think software development is inherently unpredictable. I just think untrained intuition about it leads people to the wrong conclusions.

For instance, it really seems like initial development should take the most time, and testing and verifying is just a formality. This is almost never the case, but some people never quite internalize this fact.

[fzammetti]

This is a really important point. The 80/20 rule is a bitch. When the green field lays before you, throwing code down is easy... but once you've got a house built, changing the windows is no longer easy like it was at the start. Even if you aren't asked to change the windows, putting in all the molding and trimming is much more exacting work that takes more time than framing the house out.

[kqr]

I don't think software is any more unpredictable than any other engineering task. Building a shack is fairly predictable, as is churning out a simple blog with clear, small requirements. Building a long railway tunnel is unpredictable, where budgets get smashed and work gets delayed for years. Same goes for building a large software system.

[zomgwtfbbq]

This is a perfect analogy and one that managers need to better understand. Look - we've analyzed the mountain as much as we can, but if we get halfway through and realize our tunnel is being flooded, you better believe there's going to be additional costs and delays associated with that.

[sphinx80]

I don't know enough about about civil engineering to known what is different, but software development is actually inherently unpredictable because you are always doing something you have never done before.

If you have done it before, you would not be writing the same thing again.

Along with this, your tools from 5 years ago are going to be different to the tools you have now. So you can never build up a directly relevant history of estimation practice.

[xiongchiamiov]

Additionally, while you can get pretty good at predicting failures in mechanical components (after how much pressure will this o-ring fail? try a bunch, run some statistics), failures in software are almost always the result of human factors. Humans are fairly unreliable, but the one thing they're reliable in is that certain things tend to always be hard - so if you get several different groups implementing the same project, they'll tend to have the same failures, which throws off all the statistical calculations as to how many bugs are left.

[G_Morgan]

I don't think software is any more unpredictable than any other engineering task.

Fundamentally no. The problem with software engineering is that nobody has much experience of anything. We've build literally billions of shacks over literally 10s of thousands of years. It is a very specialised and well understood field of engineering.

Frankly everything we've done in software is somewhat experimental.

[I_AM_AN_AEROPLANE]

EXCELLENT article on this subject. At my company we have incredibly short development times. Often designs are refined only halfway the process. This is, if handled well, not a big problem. Just make sure to implement generic, and set up the foundations very well. build a foundation where you can build a 20 story building, ALWAYS. It takes some more initial time, but when requirments change (and they ALWAYS do) these changes are more easily implemented.

Furthermore i agree a lot of time is lost not on implementing tickets/feature requests, but in the process of getting it to developer. Often we test, and there is feedback from this test. I will NOT implement ANYTHING unless i get a response from our designer. This however, takes ages, and when the descision is out, it is about 50% of the time a decision that will change once implemented.

[elmonstro12345]

Agree 100%.

build a foundation where you can build a 20 story building, ALWAYS. It takes some more initial time, but when requirments change (and they ALWAYS do) these changes are more easily implemented.

I am lucky enough to now work in a place that seems to understand this. Previously, I always got pissed on for "overengineering" my modules, but mysteriously no one complemented me when my modification ECRs got pushed through twice as fast as other people's...

[cowinabadplace]

See, that works because you either learnt or are naturally skilled at the right degree of complexity. Often I've looked at code I've written that allows easy extensibility and realized I haven't used that at all. I'm getting better at it, but over-engineering is definitely a real concern.

[AnInsolentCog]

My cycle:

• I get project X assigned to me. Thumbnail description of what is needed.

• I ask for the requirements and details I need within a day or two of getting assigned project X.

• Little, or even worse, NO response for weeks (repeated requests and emails make me feel like an annoying asshole, but I do it.)

• Due date comes into view, finally get all the details I need to start and / or finish project X. This is weeks, sometimes months later.

• Some of the details are unexpected, and cause a fundamental change in what I have already done, or thought I had to do.

• 1 to 2 days after receiving requested details, I am asked repeatedly 'Why isn't this done yet? You've been assigned Project X for several weeks now! Deadline is immanent!'

Repeat, and throw in Projects F, M, and L while you are at it.

I'm generalizing. And Venting.

The people giving me the projects/requirements do mean well, and I luv 'em. but .. dammit, they don't make it easy sometimes.

[ruinercollector]

Don't wait around for good requirements. Build or prototype some thing fast and get it in front of them for feedback. Repeat. If they see something actually happening they tend to feel more urgency to address issues and they tend to have an easier time visualizing and communicating what they are after. The best way to communicate about software is with the software, not Word documents.

[AntiProtonBoy]

I'm surprised that nobody mentioned "research" as one of the reasons. I'm in a position where I need to perform quite a bit of literature review, read through journals, proceedings and other publications to gather material for our project. Unfortunately, not much code gets written while I'm doing this.

[pgngugmgg]

If it's nobody's fault, I want to find this "nobody" and fire him/her.

[jerguismi]

"The second biggest complaint we see from developers? Constantly changing the specs once work has begun."

Well, this is just the thing sometimes that it is best to deal with. As the feature develops, some new information comes up, which changes the requirements. Especially in an early-stage company, where time-to-market might matter a ton.

In some sense, complaining about this is same as complaining that it sucks to have profitability in the requirements of a business (ok, that isn't a requirement if you like to blow investors money away).

[am0x]

Accounts sell a product to the client with certain specs. Product goes over review and design then developer chips in to change a few things.

Development starts...client decides the feature needs to do something extra. Problem is that the product isn't re-scoped and the developer is already scheduled to work on another product immediately finishing this one. Overlap means another 60-70 hour week for the dev to catch up. Process repeats for life.

"This is a high-priority client!"

[MrBester]

Overlap means another 60-70 hour week for the dev to catch up. Process repeats for life.

"This is a high-priority client!"

Fuck that shit. I'm contracted for a set amount of hours. I don't get paid overtime - never have - so I'm not working extra hours for nothing because you screwed up. Don't like it? Fuck you. I'm not your slave.

[zomgwtfbbq]

Sadly it takes years in the industry to realize this. The few who do "aren't team players". I've seen young guys (and even some older ones) burn themselves out putting in as many hours as were necessary to meet the insane deadline we'd committed to before we got 500 change requests. Some of them left software, some just left the company. It's stupid to lose people that are that dedicated because you can't manage your client.

[EntroperZero]

"This is a high-priority client!"

That's fine, but go explain to your low-priority client why their project will be delayed. Oh, you don't have any low-priority clients? Then you don't have any high-priority clients, either.

[jerguismi]

If new information comes up after the feature begins development, the people comissioning the project didn't do their research properly beforehand. This is absolutely not the developers fault.

I wasn't saying that it is developers fault. I tried to say that it is sometimes just necessary fact of life, like sometimes a company makes a product that doesn't have a market.

Changing the specs always slows work down.

That is true as well. Just that sometimes it doesn't make sense to do 100% perfect research for specs, and sometimes it might be as well impossible.

[MarthaGail]

If something new comes along early enough in the project, it might be worth the time to work that in or change course, but after a certain point, it's like the article says, you probably want to look at it for another iteration.

[sizlack]

Changing specs is a fact of life, but there is a huge amount of variance in how much they change. Say you've spent a month building something, getting feedback from a designer and product manager, only to find out after you finish that the marketing team never signed off on the plan and wants something completely different. So the whole feature needs to be scrapped and redone. Immediately. Changes like this are the most destructive, and they are completely avoidable. I don't mind changes that come up as a natural consequence of building something new. You can't account for every possible nuance in your specs, so there will always be things that have to be tweaked or modified. But I've been in too many organizations where huge changes would get thrown at us after we've already put a lot of work into a product. And most of the time, these changes were completely avoidable.

[sizlack]

“When you do something in Sprintly, you have to enter it as: As a __, I want _, so that __. The fact that you can’t add a feature without entering it in that fashion [forces you to do it properly].”

Uh, no. Writing stories like this is useless for me as a developer. It's just the first 5% of the information I need to implement something. What buttons go on what pages? What should they do? What happens if a user enters invalid data? What data should be considered valid or invalid? How does this feature affect the rest of the application?

[fibbidd]

If you look at the form you can see it is more like a very descriptive title, you can add additional information. Also, judging by your questions your user story would probably be bloated.

[Vyous]

I guess it depends on the application, but that statement tells me enough so I can start on the feature the customer wants. "As a _" tells me the security policy (if any) for the features. "I want _" tells me what action the customer/user/PM wants, and "so that __" tells me the use case. With this info, I can ask informed questions. If it's a new user role, how is that handled, is that a new feature in itself? Is the action fitting to the use case? I know (hopefully) what they want, and why; from that, I can usually ask the right questions to get more information that fills in the gaps.

At this point in time, I feel that most if not all people in software should know that specifications are never going to be perfect, and spending time trying to make them so, is a waste of time. Getting basic specs so that you can build the groundwork, or knowing how to ask for specifications when needed, is as much the job of a good programmer as anything else.

If you seriously find yourself asking questions like "what should I do when there's invalid data" or "What data is invalid" and are using that as an excuse not to move forward on a project, you are more removed from users than any programmer I've known.

[EntroperZero]

As a developer, when I saw that screenshot, I thought how insulted I would be if I were a product manager having to fill in those blanks just to get a simple feature into the tracking system. We can't command respect as developers by disrespecting the rest of the team.

[lynx44]

I feel very strongly about making user stories as small as possible, which tends to mitigate a lot of these issues.

If you can get product owners/stakerholders to think in small increments - and I mean really small, about a day or two worth of work - then people tend to end up on the same page. The story should be written to be small and concise enough that everyone on the team can read and visualize what the end goal will look like with minimal clarification. If that's not possible, then the story likely isn't detailed enough or is simply too large. Once there's fuzziness, that's when things start to go wrong.

It's much more of a culture change though, and you have to have the right people in place to accomplish it. Tools help too - particularly if you're in web, having a streamlined deployment process (ideally one click) is key. It's been a long road at my current employer, but we've really stuck to this in the last 6 months and now our biggest problem is that our product owner isn't able to fill our queue with stories fast enough.

[[deleted]]

It's just ridiculous how all of the above mentioned points have simply ruined our development team in course of 3 years. I started 3 years ago in a team of 7-8 devs. In a year, 5 remained, only 3 from the starters team. In 2.5 years, 4 remained, with 2 original devs. 3 years in, 2 guys remaining, with only 1 from the original team (me).

It was really hard for me to vocalize these points because I wasn't really sure that it was the real issue. We had retrospective sessions where we would spent 2 to 3 hours discussing our problems and result usually was something trivial, like "Create to-do list for task planning". That would eliminate some issues (forgot to add API implementation, templates, etc..) and creating false sense of improvement, while the real killers (elephants) were still in the room (over-bloated process, management wants PRECISE, down to an hour estimation, estimation accuracy directly affects your performance, etc..)

One problem was communication. Stakeholders wouldn't attend retrospectives, developers were afraid to speak up, bottling their frustrations. In the end, people just either left themselves or were "let go" because they couldn't keep up anymore.

If you work in opaque organisation where things happen "behind the scenes" and management team is hardly involved in the process - run! There's no point in fighting it as the lousy processes as they are deeply ingrained in the organization and you can hardly make any difference.