
Why Isn’t Agile Working? - kiyanwang
https://hackernoon.com/why-isnt-agile-working-d7127af1c552
======
hacker_9
Couldn't disagree more with this article, is this even written by a
programmer? Agile takes into account the very real 'semantic cost' when
translating from user requirements to actual code.

Code is so specific and brittle compared to the lovely fuzzy English language
that we think and write in, that we can never get the requirements just right.
The biggest problem is integration of ideas into an existing system. Yeah ok
you want to extend the login screen to support one extra field? That's great
but after a couple of days work, it turns out that 2 years ago Joe Bloggs
added some complex verification algorithm no one understands to a stored
procedure, oh which contains about 30 other input fields, and so is going to
take an extra week to untangle. The procedure is also used in 20 other places
too and there's no unit tests covering any of the functionality.

Agile gives the programmer a voice in the process, and once they update the
tasks and time estimates, the feature's priority can be re-evaluated. Treating
development as a one shot process is just doomed to fail and more stressful
for everyone involved.

~~~
zimpenfish
> Agile gives the programmer a voice in the process

In theory, perhaps, but there are many places (everywhere I've worked) where
the programmer voice is subjugated to project managers, product owners, and
pretty much everyone else.

> once they update the tasks and time estimates, the feature's priority can be
> re-evaluated

Never worked anywhere that developer task and time estimates were considered
as "truth" rather than something for everyone else to override or ignore based
on external constraints.

~~~
matthewmacleod
_Never worked anywhere that developer task and time estimates were considered
as "truth" rather than something for everyone else to override or ignore based
on external constraints._

In that case – and I've said this often – the problem is with wider
organisational culture and 'agile' or otherwise will not help with that.

I work in an environment where those estimates are just bluntly accepted,
because they're the considered opinion of a team of professionals, and they're
never overridden. If they are too high to meet some other business or
marketing constraint, then we can start looking at ways to reduce the scope,
extend the deadline, or incur some temporary technical debt.

I can't imagine having my estimates 'overridden' by anybody else and would not
continue to work in an company where my actual, professional opinion about my
own work was routinely ignored.

~~~
pdimitar
Count yourself lucky.

Or, like my wife, you are one of these people that are proud in a kingly yet
humble manner -- and never allow anyone to step on them ever since early
childhood. They seem to have a presence/aura that strongly discourages all
dictators from trying to dominate them.

------
Traubenfuchs
My current job is my first truly agile software development position. I have
never spent this much time in worthless meetings ever before. I also never saw
a team with a lower "velocity" before.

Estimating story points for tasks when we know there is only one who has the
skills to do it, direct conversions between time and story points. Countless
hours spent in splitting and combining "stories" to make them agile sized
bites. Estimation meetings that take half a day, where for every story only
20% of all the people who sit there can contribute.

I feel like this is all a big fat joke.

~~~
matthewmacleod
_My current job is my first truly agile software development position._

That's the problem there – the job you describe is not on a 'truly agile'
team. It sounds like almost exactly the opposite – a focus on process, rather
than 'whatever works'.

I work on a definitely 'truly agile' team – one estimation and planning
meeting per two-week sprint, for a team of three developers, lasting about an
hour. And it's great!

~~~
skookum
Your response, as do most such Agile defenses, suffers from the No True
Scotsman fallacy.

The problem is that if, when faced with example after example of something
labelled 'Agile' not working, one discounts each as not 'truly Agile', then
once one subtracts all those examples of Agile not working from the Agile
literature there's nothing concrete left to prescribe other than "keep trying
stuff until you find something that works for you."

~~~
zzalpha
That's a misuse of the fallacy.

There are some basic practices that are required for an organization to adhere
to an agile process. Transparency, accountability, introspection... it really
is basic stuff. And either they're doing them, or they're not.

If they're violating the definition of the process, _they 're not implementing
the process_.

If someone got into a car accident and didn't have a license, and I said
"Yeah, but they aren't a qualified driver", you wouldn't invoke the No True
Scotsman fallacy, would you?

~~~
skookum
> Transparency, accountability

These are concepts, not practices. And 'introspection', while arguably being a
practice, is really, really not basic stuff. Introspection with actionable
outcome is about as basic a practice as "finding inner peace" is.

> If they're violating the definition of the process, they're not implementing
> the process.

As seen even in just the comments on this submission, if someone follows the
definition of the process as laid out in the literature, they are dismissed as
being too process-focused and not truly Agile. If someone doesn't exactly
follow the definition of the process as laid out in the literature, they are
dismissed as not following the rules of Agile.

~~~
zzalpha
_if someone follows the definition of the process as laid out in the
literature,_

Agile has no "process as laid out in the literature".

I'm not even sure where this idea comes from.

The Agile manifesto is extremely basic. It contains a few core principles, and
everything else is elaboration on them.

This organization is violating even those very basic tenants.

It's possible that, over and above the manifesto they're trying to implement
Scrum or Kanban or some other process, and heck, they may be failing to adhere
to those processes as well

But if they're not at a bare minimum attempting to live and breathe the values
encapsulated in the manifesto, they are _by definition_ not executing an Agile
process, since the manifesto _defines_ what "Agile" is.

~~~
skookum
There is plenty of literature. None of it necessarily agrees with the rest,
but Agile proponents over the past 15+ years have produced a copious body of
literature. If you disown all of that literature, then all you are left with
is some pseudo-religious principles, tenets and values, which is not useful
for someone trying to improve a development org. It also make evaluation of
its effectiveness impossible as there's no agreement on what's being
evaluated.

Living and breathing values and principles entails putting something in to
practice which means you need to put a stake in the ground as to "how",
instead of just repeating platitudes. If you can't find three people who all
agree on what "living and breathing the Agile values" means, then you can't
practice Agile at team scale.

------
binaryapparatus
Agile in almost any form is there because we, as a programmers, allowed HR
'professionals' to imagine what would it be to run our job. They have no idea
what our job is but they certainly make sure to be needed even if they are
not.

In parallel universe they are on the same space ship with telephone
sanitizers, hairdressers, jingle writers and accountants.

And before anybody tells me how rude I am I want to clarify I have been
extremely nice and understanding.

Agile is in almost any form just waste of time. Wannabe mangers or HR
professionals are parasitic foreign body in almost any IT related profession.
But they talk better than we do.

~~~
asfdsfggtfd
Agile can be used in such a way that it gets management off the developers
backs and empowers the developers to take their own decisions about how to
plan their work and their time and to control how feature requests end up in
their personal to do list (i.e. the feature request has to wait until the next
sprint).

Things that help are:

1\. Having a project manager with at least several other projects to manage
(discourages micromanagement).

2\. The project manager should also be good at defending the dev team from
distractions by triaging incoming requests into urgent bug fixes vs. waits
until the next sprint planning meeting.

3\. Having a product owner who does not act as a manager but as a consultant
on a day-to-day basis (the dev team has to however appreciate that the
producer owner is the person they are developing the software for). Ideally
the product owner should be available but with some other work to be getting
on with.

4\. Having a professional development team that are more focused on delivering
a product than building a CV/blog.

~~~
watwut
The worst thing about agile is zero autonomy and zero ability to make
decisions and be accountable/responsible for them. You never even get the
feeling that you achieved or at least did something. And managers were not the
biggest problem. Fellow developers with strong micromanaging tendencies were.

------
ealexhudson
For me, agile is about responding to change quickly: reducing the waste in the
development cycle by not building stuff that isn't needed. That's an important
step, but it has very little to say about the way in which you build the stuff
that is valuable: it doesn't dictate architecture, approach, standards, or any
thing else (except that onerous / long-winded processes conflict with the
agile approach). Agile is great for developing things where you're not totally
sure what the end result is.

Specifically, for me, agile doesn't make the development _process_ faster, it
just encourages you to adapt more quickly and may (should) speed up delivery.
If you want to make the _process_ faster, you have to look to other solutions
(which are pretty orthogonal to agile).

~~~
jasonmaydie
It's funny because everyone seems to go with their own ideas on what Agile is.
I know companies who do agile and to them it's moving fast, loose
requirements, etc. That is what it means to be "agile".

For others, it's that slow grinding process of sprint planning, task
estimation, pointless scrums and using estimation as some kind of metric for
performance.

Then I took an agile course from the scrum alliance and the instructor only
cared about Agile as a way of building "high performance teams". E.g get a
group of people together, stay together, let them manage their time and they
way they work to get the best usage out of them.

I've done all 3, to me agile fails because nobody really knows what it is
other than they are doing "Agile"

~~~
zimpenfish
> nobody really knows what it is other than they are doing "Agile"

And as soon as you say "Agile isn't working", you'll get a flurry of responses
saying "You're clearly not doing it RIGHT".

------
alkonaut
If you argue agile isn't working, you must have some hypothesis of both what
it is and what it would look like if it worked. I fail to see that in this
article.

There is also the other problem with complaining agile dosn't work - it's that
there are no clear candidates for what does work.

To me, agile is mostly about measurement. If you have a process that is
exactly as slow as what you did before you "went agile" but now you KNOW how
slow you are, and you have realistic deadlines, know beforehand when you will
miss them and so on - then agile mostly works for you.

~~~
tempodox
Plus, the author gives zero sources for the statements and numbers they
present. We just kind of have to believe them - or not.

~~~
pdimitar
This is not a PhD thesis, so your comment is meaningless. It's an opinion /
rant. What sources would you accept?

Additionally: don't believe him, what's the problem with that. Just don't.

------
matthewmacleod
It's a good article, though the headline seems likely to produce a rash of
comments that perhaps agree without reading :)

The point is, agile development isn't magic and doesn't mean that more work
will automatically get done. It doesn't work if it's imposed top-down, it
doesn't work if the team are fighting it, and it doesn't work for every
product.

It's a tool, like any other, that helps the team to respond quickly and
incorporate feedback frequently, with the goal of making sure that the
products produced are effective and fit-for-purpose. The work still has to be
done, and if anything there is _more overhead_. But that can be a valuable
tradeoff if it reduces cost elsewhere.

Being on a team that does agile properly is _amazing_ , and it really is a
shame that it's become so widely derided as a result of ridiculous consultants
and the associated mess.

------
another35
Agile is nothing more than a methodology that can help a dedicated team to
have a little more structure and transparency in the development process. Any
team can easily do a weekly 30 minutes meeting to update on progress and
issues. Also, a product owner can chop up epics into manageable user stories
that can be done within 1 or 2 weeks (call that a sprint). IMAO there is not
much more to it.

The real problem is that whole subculture of 6 figure Agile managers, Scrum-
masters etc.. that preach their little thing as if it were a religion that
leads to maximum productivity and dollars. But in the end it is only about
their dollars. Most of those people cannot code, cannot design, have no
vision, no skills whatsoever to build a product as what the team is actually
doing. They sell themselves way more important than they actually are. I don't
need a DRY coach or manager who helps me avoiding to repeat certain parts of
the code. It's a very simple concept, don't need any coach for that, same
counts for Agile.

In the company where I currently work they have now fully adopted Agile.
Result? We hired for over a million dollars a year on Agile managers, Scrum
masters, coaches etc.. We do meetings all the time, very structured indeed! My
productivity as a developer dropped over 50% (and not only mine). But I don't
mention it to these awesome Agile managers, as soon as they know I'm not a
proponent my days in the company are counted.

~~~
pdimitar
I sympathize with you. Time for another job, buddy. I am not saying this
lightly, I fled three such companies and it hurt every time but always turned
out to be the right decision in retrospect.

------
raverbashing
Whenever agile "doesn't work" is because higher ups keep expecting the same
(useless) artifacts and ways of working to be present. Including the biggest
one of all: a fixed shipping date without compromising on features

It's like filling up a Formula 1 cars with bricks and asking why it doesn't go
fast (an hyperbole, but the point stands)

~~~
tempodox
That's why I lay on the floor with laughter when I read the “Changing your
management culture” point at the end. That particular event is literally the
last thing to occur, ever.

~~~
pdimitar
Agreed. It's more likely that the entire technical staff will be replaced
before even one manager changes the way they do things.

Actually, I have been seeing things like that almost happening several times
(firing 5 out of 7 programmers in a team, or firing the entire sysadmin/devops
staff -- 9 people -- overnight).

------
deanCommie
Because it was taken over by cargo cults like SCRUM who desperately try to
turn it into a "process" forgetting the very first line of the Agile
manifesto: "people over process".

Agile is a philosophy not a process. The process will differ company to
company, and should derive by working backwards from the goal you want to
achieve: "We want to solve the right problems for our customers".

What that ends up looking like, what you ship, what you DON'T ship, and how
you do/don't ship it will matter entirely on your customer, your product, your
company, and your specific team.

------
jinushaun
I think the software industry is doomed to forever argue about the definition
of agile…

From my experience, people's negative experience with agile is usually because
Agile is often adopted top-down as _dogma_ with highly paid consultants and
strict rules, instead of bottom-up as just another _tool_ to do your job.

------
Flenser
> Unmanaged Complexity

This comes back to the XP practice[1] of simple design[2] or "code that can
change" which Fred George says has 4 properties:

    
    
      1. Works  
      2. Communicates  
      3. No Duplicate Code  
      4. Least classes and methods  
    

see GOTO 2015 • The Secret Assumption of Agile • Fred George [3][4]

[1] [https://ronjeffries.com/xprog/what-is-extreme-
programming/ci...](https://ronjeffries.com/xprog/what-is-extreme-
programming/circles.jpg)

[2] [https://ronjeffries.com/xprog/what-is-extreme-
programming/#s...](https://ronjeffries.com/xprog/what-is-extreme-
programming/#simple)

[3]
[https://www.youtube.com/watch?v=l1Efy4RB_kw](https://www.youtube.com/watch?v=l1Efy4RB_kw)

[4] [https://gotocon.com/dl/goto-
amsterdam-2015/slides/FredGeorge...](https://gotocon.com/dl/goto-
amsterdam-2015/slides/FredGeorge_TheSecretAssumptionOfAgile.pdf)

------
ordinaryperson
Reminds me of Winston Churchill's description of democracy being the "worst
form of government, except for all those oth­er forms that have been tried
from time to time" \-- agile is the worst, except for all other methods.

In reality, any system can be bad if you obsess on process over results.

A product manager once told me that I was past the code freeze date of his
6-month (heavyweight/waterfall) release cycle so I'd have to wait 8
months...to get a single file changed. When a VP overruled him and forced the
issue this guy called me up to angrily complain how much "extra work" this
would be for him and his release process (and I was just passing along the
request on behalf of the business). Buddy, if your software release process
doesn't allow you to change a single file in < 10 months, you're doing
something wrong.

That's not to say Agile is a cure-all. I've worked at co.'s that insist on
daily standup meetings so they can say they're "Agile", even if they have no
practical value and are a time-suck.

I've seen mid-level executives obsess over the terminology -- t-shirt sizes,
stories, kanban, scrum, sprints -- mainly to sound impressive dropping jargon
in front of their superiors, even if no actual progress is being made.

Or they say they're "Agile" as an excuse to play "Etch-a-Sketch" with
requirements, changing every few months because they're "iterating."

That being said, I'll take Agile over Waterfall any day. There's just too many
unknown unknowns in writing a specific type of application for the first time
to gameplan everything out in mockups successfully.

I think the bigger problem is mid-level bureaucracy at too many companies, and
that would exist with or without Agile, IMHO.

~~~
pdimitar
Bureaucracy is exactly the problem. Namely those people that are horrified of
being fired so they invent a process labyrinth only they can navigate so they
can have job security.

------
bitL
Sure it doesn't work anymore, humans have innate ability to corrupt any
outstanding ideas and agile is now finished. Post-agile was already formulated
like 5 years ago. The only source of progress in humanity/tech is a few folks
that work on radically new and effective ideas the "corruptors" can't yet
understand, giving them time to do something of importance. Once these
"corruptors" catch up, it's over for that given area. Agile is also very
flexible, so anyone can put its sticker on a BS du jour and stay safely within
bozoland, never achieving anything and preventing others from accomplishing
something as well.

~~~
pdimitar
Most accurate comment in the entire thread. Thank you!

Indeed, agile and its brother XP are pretty awesome concepts and ideas but
have been heavily corrupted by well-paid "motivation experts" and "efficiency
consultants".

Business loves making money on the back of people who don't understand a new
concept well enough. I, like you, am sure that won't ever change.

~~~
jrs235
> Most accurate comment in the entire thread. Thank you!

I don't know, there is another comment[1] that might be competing for that
title.

Both comments are gold though!

[1]
[https://news.ycombinator.com/item?id=15413277](https://news.ycombinator.com/item?id=15413277)

------
jimjimjim
Agile is the large cargo culting the small.

Plus it completely ignores the real world. Ie the release date is usually set
as early as the rfp response/pre_sales stage and requirements are usually
legally signed off.

~~~
pdimitar
Yep. I find it pretty comical when an externally hired "Scrum expert" is
trying to motivate the team and make them work faster (somehow) while he/she
full well knows the shipping date of the final product is non-negotiable.

It's a circus and I have no idea why is it played. 90% of all devs I ever
worked with see this bullshit a mile away and laugh about it in coffee breaks.
In _every single place_ I worked.

------
he0001
Agile isn't working, mostly because people focus on the processes. The thing
they forget is the tech. If it takes days or weeks to verify that your code
works how agile can you be? Or it's impossible to develop anything new because
there are so many bugs. Or your tools are worthless and doesn't help you in
development.

Also they keep forgetting that if your system is developed with waterfall or
no development structure it just won't support an agile way of developing.
It's Conway's law...

------
staticelf
Agile is just a model, it doesn't reflect the real world at all.

It all depends on the people working. If you have bad people that doesn't do
shit it doesn't matter what development model you use because the output will
be shit nonetheless.

You can have a waterfall based team that produces a lot of good stuff in short
amounts of time and you can have an agile team that does the same. The model
doesn't really change anything.

~~~
keithnz
its not a model, it's a manifesto... and often what get's done as "agile"
doesn't conform to the manifesto :)

~~~
staticelf
Call it whatever you want, what I wrote is still true :)

~~~
keithnz
Sort of, the point of Agile is if it is bad, then you know much sooner than
with waterfall.

But if everything is so bad no matter what you do, then it's not really
anything to do with how to do software development, it's a whole different
problem.

------
swagtricker
"There’s no accountability. All I get is excuses."

Clearly they didn't change everything. Given that statement, they failed to
change the CEO's understanding of his role to becoming a servant leader vs.
'managing' a bunch of peons. If he's still walking around trying to tack
accountability on anyone but himself at that point, he's the source of the
problem and needs to fire himself.

~~~
pdimitar
I know right? Funny how managers NEVER ask themselves if they might be the
problem.

------
dragonwriter
> Agile is worthless unless it serves as a catalyst for continuous
> improvement.

Agile _is_ continuous adaptation of methods to the particular circumstances of
the team (both it's tasks, and it's composition in terms of individuals.)
That's _all_ Agile is.

The problem is that concrete fixed methodologies that are applied in the same
way in widely divergent organizations under the oversight of gun-for-hire
“master project managers” and other consultants, _the exact phenomenon Agile
emerged as a reaction against_ , are now being sold with “Agile” attached to
them as a hollow, meaningless buzzword.

The Agile movement is in part to blame, because while the Manifesto has a
great statement of values, there is no concrete operationalization of them
embraced by the movement that emphasizes adaptation of process. (Which is one
way in which the Lean community is a somewhat better forum for similar values,
since it emphasizes more high-level metamethodology around evaluating and
adapting methods, making it somewhat more resistant to being converted into a
label for fixed process.)

------
snarfy
> Which brings me to Agile. Agile is worthless unless it serves as a catalyst
> for continuous improvement. Scrum and SAFe are worthless unless they serve
> as a catalyst for continuous improvement.

Go back and read the Manifesto. Agile is not a process. Scrum is and maybe
that's not working, but don't rip on Agile. It's four sentences.

------
jpswade
We've found that agile is really only part of the puzzle. As your business
evolves, development has to evolve too.

If you’ve ever looked into DevOps, you’ve no doubt come across this
“evolution” type image, with an ape type figure on the left, labelled
“Waterfall” and on the right, you’ve got an android labelled “Continuous
Operations”. Along this evolutionary journey, you’ve got agile, lean,
continuous integration, continuous delivery and continuous deployment.

Agile is just part of the journey, not the destination.

~~~
EliRivers
The most successful software I ever worked on was entirely waterfall. You do
need extraordinarily competent customers to make it work, though. I see very
few customers good enough for it.

------
Flenser
> Unplanned Work

I recently found this on how to deal with unplanned time when planning
sprints: [https://www.mountaingoatsoftware.com/blog/sprint-planning-
fo...](https://www.mountaingoatsoftware.com/blog/sprint-planning-for-agile-
teams-that-have-lots-of-interruptions)

It's not something I've seen discussed much elsewhere. Is there any other
advice on this out there?

------
mixedbit
It would be great to survey a large selection of software projects and see if
Agile has positive or negative impact on the success.

My current view (not backed by any numbers) is that the majority of widely
used software started as an spontaneous initiative by a small group of
developers or even a single developer that didn't use any formal methodology.

~~~
matthewmacleod
Worth noting those that 'Agile' is not a formal methodology and are most
likely a set of principles that are already followed by the sort of projects
you are thinking of.

------
keithnz
agile is a manifesto, not a process :)

I started with Extreme Programming in 99, and watched the march to Agile tree
hugging, hippy, non programming, consulting gold mine weirdness.

I barely know what people mean when they say "agile" now. I think anything
that is some variation of scrum planning is considered agile

------
ironic_ali
I think the comments so far and their almost complete disparity in opinion
from one another, is why agile mostly doesn't deliver its promise.

------
bryanlarsen
Agile is like democracy and capitalism. They all are really bad, they're just
better than the alternatives.

------
smegel
Agile wasn't supposed to solve big problems of software development, like how
efficiency scales down as you add more developers or why it's hard to predict
how long it will take to deliver X.

Agile is about understanding why these difficulties exist in the first place
by realizing the human aspects of software development, and provide an
alternate model for software delivery that is based on a pragmatic
understanding of the complexity of humans and of software.

It's more about realistic expectation calibration and compassionate project
management than turning developers into highly predictable and efficient
machines, which sounds a lot more like the folly of waterfall development with
fixed goalposts set years in advance.

The problem is all the wrong people have jumped on Agile and are trying to use
it to "solve" a perceived problem rather than using it to better understand
the human condition and taking a more pragmatic and compassionate approach -
yes with accepting "we dont know" is a valid answer to a lot of questions.

The core point of Agile has been lost, because the people now riding it to
death never understood it in the first place.

~~~
_pmf_
Agile is the self-fulfilling truism that small, focused teams with a
cooperative customer can create good software. If you create software in a
contractually or regulatory heavyweight setting and are "doing agile", you're
fooling yourself[0].

But people like cargo cults, so we should let them have their fun.

[0] For additional fun, we've had projects with 200 page of nonnegotiable
specification that the customer wanted "to be done agile" (but any deviation
from specification had contractual penalties attached).

------
foo101
Related: Agile is Dead (Long Live Agility):
[https://pragdave.me/blog/2014/03/04/time-to-kill-
agile.html](https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html)

From the blog post:

> And, unfortunately, I think time has proven me right. The word “agile” has
> been subverted to the point where it is effectively meaningless, and what
> passes for an agile community seems to be largely an arena for consultants
> and vendors to hawk services and products.

> So I think it is time to retire the word “Agile.”

> I don’t think anyone could object to a ban on the word when it is used as a
> noun. That’s just plain wrong. “Do Agile Right” and “Agile for Dummies” are
> just two of the innumerable attacks on the English language featuring the
> word. They are meaningless. Agile is not a noun, it’s an adjective, and it
> must qualify something else. “Do Agile Right” is like saying “Do Orange
> Right.”

~~~
slowmovintarget
I've been cringing at nearly every comment in this thread using the word as a
noun.

90% of the capital A processes I've seen are actually the degenerate cases of
Scrum where the company has simply encoded crunch-time into a standard
practice.

------
gaius
Because Agile is a vehicle for selling books, consulting, training and
speaking engagements. It was never intended to actually be used for producing
real, working software in a commercial setting.

Those who can do, those who can't invent methodologies.

~~~
tempodox
> ...those who can't invent methodologies.

Or they follow methodologies invented by others because they can't manage to
get their own mess under control.

------
oraguy
I worked at Oracle for a few years in their database development group
(internally known as "RDBMS"). You would be surprised to know that they follow
a strictly waterfall process to perform database development. The results are
horrible.

Process:

\- Let us say a release is planned for January 2018. Projects are decided
around June 2017. By the way, In Oracle RDBMS, a project essentially means
anything more than 5 lines of code change.

\- Each developer is assigned a project.

\- The developer is given a deadline to write a design spec by August 2017.
Developer spends 3 months in writing a design spec. A lot of bike-shedding
occurs for those 3 months on mundane topics like whether a certain timeout
should be 0.5 seconds or 1 second.

\- Then the developer is given another deadline, say September 2017, to write
a functional spec. More bike-shedding.

\- Then the developer is given yet another deadline, say October 2017, to
write a test spec. More bike-shedding.

\- 5 months have passed and not a single line of code has been written. But 3
large documents with about 10000 words in total and another 10000 words of
bike-shedding has been written.

\- Finally, the developer is given another deadline, say November 2017, to
complete writing the code with tests.

Results:

\- Developer writes 10 lines of code and checks in their code by November
2017. Project completed!

\- Everything looks fine for a few days.

\- About a million or so tests run over the next few weeks. 1000s of tests are
found to be broken. So much for 5 months of spec reviews! (Note: This happens
for every such project, about 20 or so projects in a year.)

\- The bugs are distributed to various developers. It takes them another 12
months to figure why each test broke, how tightly every layer and corner of
the code is coupled with each other, and how they are solving the biggest
puzzles of their lives: How to fix one thing without breaking 10 more things?!

\- The original design, functional and test specs go out of the window. This
is really bad time. Management is unhappy. Larry is unhappy! We got to fix
those tests, no matter what it takes to fix them. Radical decisions are made
as developers discover clever tricks to fix one part of the code while somehow
finding a way to keep the other part of the code happy.

\- 12 months have passed. It is November 2018 now! (Remember, the project was
scheduled to be released 11 months ago!) It looks like everything is fixed.
The whole 10 line project is somehow held together by tests. Nothing appears
to be broken. But nobody is really sure.

I am glad there are other saner companies where people understand that
waterfall model development is flawed and embrace agility. Having done
waterfall for a few years, agile development is a breath of fresh air where I
can spend more time writing code than writing documents, where I can evolve
the code based on actual user feedback rather than feedback from bike-shedding
by people who have not contributed a single line of code to the software.

