
Your developers aren’t slow - davidkellis
https://sprint.ly/blog/your-developers-arent-slow/
======
edw519
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

~~~
logfromblammo
\- reinventing the wheel because a perfectly serviceable existing solution
cannot be licensed

I can't stand hearing that there's no room in the budget to pay a flat $500 to
license a 3rd-party grid control (for example) only to have a $90k/yr salaried
developer spend 20 or more hours recreating barely a tenth of its features.
It's even worse when the license is free (as in speech), but it still can't be
used, because the code hasn't been blessed by the security department, or
because management simply has a prejudicial bias against the terms of the
LGPL.

~~~
stouset
On the flip side, as one of those guys in the security department, it
aggravates me to no end when developers can't understand why we won't allow
them to open up direct production database access to some unheard-of SaaS
startup that's been in existence for a total of a month.

~~~
logfromblammo
While you present a reasonable example of why certain things have to be
cleared before implementing them, most of the time you are used as an excuse
to issue a knee-jerk denial of some suggestion, without even bothering to
consult with you first. And people at other companies are not necessarily as
competent or diligent as you are about doing your job.

Usually, the argument goes like this: \- We cannot use X until it has been
cleared by legal and/or security. \- Legal and/or security do not have the
resources available to clear X for our use within a time span that would allow
X to be useful. \- As a result, we won't even ask them to try. \- Therefore,
screw you, nerd.

Alternately: \- We don't have room in the budget to license X. \- The budget
won't change until after the end of the project. \- We can't justify altering
the budget to accommodate licensing X unless it would be useful for an ongoing
project. \- You won't be allowed to comment on upcoming projects until after
the budget is fixed. \- Therefore, screw you, nerd.

Or in the worst case: \- Here is a detailed proposal to use invented-elsewhere
thing X in our product Y, with gobs of research and references, and oodles of
possible pros and cons. \- We don't understand what you are talking about. \-
So we're going to fixate on some tiny, mostly-irrelevant detail, and then
blather about it until you go away. \- Therefore, screw you, nerd.

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

~~~
typicalrunt
> "Writing good specs is important" \- it's also really really hard.

Yes, this is a very good point. Unfortunately it's also a point that many non-
software developers miss. Writing software is hard. Very hard. We, as an
industry, should be pointing that out more.

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

I'll submit that there's no way to know whether you are doing agile properly
or improperly, unless you move to another company.

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

This smacks of elitism and it is what makes non-developer scoff at us.
Developers are not gods, we're not even the smartest people.

We are simply the people that have to crystallize the requirements into a
computer that only understands logic. Non-tech stakeholders can completely
describe business requirements and also be made to understand the how their
requirements fit into the logic of a computer. Non-technical people are not
stupid, they just have different interests.

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

The spec is the output of the conversation.

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

And this is the most important thing said.

The trick with adhering to your statement is to define the parties involved in
each step. Minimize those parties and then implement each step in order as
fast as possible without sacrificing quality.

Remove the word "Agile" and the concept of software development, and what
you've just described is how work has been completed for thousands of years. I
fail to see how Agile comes into play.

~~~
dansingerman

      > This smacks of elitism and it is what makes non-developer scoff at us. Developers are not gods, we're not even the smartest people.
    

I don't mean to imply that developers can do this because they are cleverer.
Merely that developers have a mindset to understanding software systems that
business people often lack.

    
    
      > The spec is the output of the conversation
    

As I've said in another comment I don't think there should be a spec (in the
traditional sense at all). There should be a story, a conversation, and
acceptance criteria (ideally defined in code)

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

~~~
tommyd
Your experience is definitely unfortunate - stories/features being fully
tested before being considered done, and therefore potentially shippable, is a
key part of a successful Agile process. Without it, you are missing out on a
lot of the possible benefits of the process, and I have seen first-hand the
difference having QA engineers, even not particularly strong ones, integrated
into the sprint can make to product quality.

A good first step to take would be to get your team together and work to
define a Definition of Done, which should include both unit and
integration/E2E testing (manual and/or automated) being complete - any stories
not meeting these criteria cannot be considered as "done" and you can't count
the points for them in the sprint.

Of course, initially this will probably cause lots of failed sprints and will
decrease your velocity, but you have to see this as a positive, in that this
raises visibility of the problems, and once you can identify the specific
issues you're having and take the steps you need to resolve them (whether
that's a lack of QA resource, or poor testing culture among developers, or
whatever), you'll know when you say something is "done", it actually is done,
rather than hiding a load of extra testing work that isn't complete.

On the requirements front, again defining a Definition of Ready can help -
these are the criteria stories need to meet before you will estimate or start
working on them. This should include things like requirements being clear,
designs/UX being complete (if appropriate) and the story being testable and of
a suitably small size for you to estimate with a reasonable degree of
confidence.

Once you start pushing back on estimating stories because they don't meet
these requirements and educating your product owners what they can do to
improve the situation (for example, breaking stories down into smaller chunks,
or defining requirements more clearly), you'll hopefully find the situation
improves.

Of course, none of this is a substitute for conversations and working with the
product team to help them understand what does and doesn't work for you, but
I've personally helped make big differences to a team's quality and
productivity by taking small steps such as these, in addition to educating the
team and business on what "agile" is (without all the BS that some people will
try and sell you!) and why this is important to us as developers and therefore
to the wider organisation.

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

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

------
bowlich
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
remove the PM.

~~~
thisone
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
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.

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

------
coreymaass
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
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...](https://soundcloud.com/business-of-
coding/business-of-coding-michael-sopp)

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

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

------
datashovel
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)

------
coldcode
"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
Waterfall is all up front. Agile is up front at the task level. Normally when
commited to a sprint it doesn't change.

~~~
dragonwriter
> 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.

------
ExpiredLink
> \- Unclear requirements

> \- Changing requirements

> \- Context switching

That's Agile Programming!

------
conradfr
What incentive do your developers have to ship faster ?

~~~
nostrademons
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?

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

------
michaelochurch
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
Mike, you're one of my favourite commenters on HN. But this is one of your
concepts that I've never been able to wrap my head around. Specifically:

>....business-driven software engineering. It does not work.

My interpretation "business-driven software engineering" (and please correct
me if I'm wrong) is one where business determines the requirements of the
software. But if business doesn't drive those requirements, who will? You've
repeatedly shown how terrible the typical dev is at business, and most devs
would seemingly cozy up to their IDE rather than navigate the mess that is
determining requirements. So who's gonna do it? Besides, which dev doesn't
hate a fuzzy spec?

Additionally, or perhaps more fundamentally, a business hires devs to the ends
of furthering their, well, business objectives. What, exactly, is so wrong
with business setting the agenda of what gets built?

I ask because of a lesson I learned early (and painfully) in my career as a
sysadmin. Technology exists for the business - Not the other way around.
Unless, of course, you're a tech firm, where tech itself is your business. And
even then, a business has to make economic sense, and as a programmer, I think
I'm allowed to say we typically make poor economic choices. McLeod 'Clueless',
if you will.

~~~
michaelochurch
_What, exactly, is so wrong with business setting the agenda of what gets
built?_

I don't think that it's good when the business (usually, this means _the
executives_ ) do it unilaterally. Obviously, it's not good for engineers to
build with no concern whatsoever as to whether they're building something
useful. It needs to be a collaboration focused around letting each side do
what it's good at.

I'd like to believe that _enough_ of us have sufficient business sense that we
don't need the Agile-style waterfall (no, that's not a contradiction) in which
requirements flow from business into "product" into technology. Not all of us
make sound economic choices, but I think that a large part of that comes from
the fact that most companies promote people with any business sense "out of
IT".

As one who's trying to look forward for us as technologists, I guess I'd say
that we need to take some responsibility for learning business and politics.
The head-in-sand strategy is bad for us individually, but also bad for us as a
group.

