My instant review of Twitter's new business plan - <AUTHOR> http://www.scripting.com/stories/2010/05/25/myInstantReviewOfTwittersN.html <comment><USER2> Twitter is clearly not going to ask for a cut of ads not displayed on Twitter proper. To claim otherwise is a disingenuous scare tactic.

Fred Wilson's responds to the same effect in the comment thread as well:

 _the whole "we reserve the right to request a share of ad revenue" is designed to prevent people from going around the new rules. the rules themselves are pretty clear "only twitter can put promoted tweets in search results and timelines"_

Seriously, I can't remember the last time I read a scripting.com post on HN that wasn't useless. I especially like the part in this post where Dave Winer plugs his invention of RSS for the millionth time, and states that Feedburner should have given him some money for monetizing RSS.

<comment><USER3> And exactly what would they have done with a percentage of Feedburner's revenue anyways? Endowed the RSS Foundation? It's a spec, not a business.

</comment></comment><comment><USER4> The question is, where to move next? Google Buzz?

There is identi.ca/status.net, but I think there were some issues. It should have synced with Twitter more (let me read my Twitter followers).

Personally I am still hoping for a world where everybody can host and own their own stuff, even if it seems unlikely at the moment.

<comment><USER5> Have been wondering the same thing myself, and opened up an identi.ca account to see what it's like. Nobody I know uses it yet but there are a good number of Free Software and Android oriented users.

</comment></comment><comment><USER6> If your product changes from a tool to an avenue for consumption, the users who gave it life will leave for another. This has happened so many times, you would think it would be written down in a playbook or engraved on plaques at businesses.

</comment><comment><USER7> It seems Dave wants Twitter to go out of business, sure it's not the perfect open platform but with 200 employees and costly infrastructure to run they can't really afford to give others the opportunity to one up their revenue model with very little outlay themselves.

</comment><comment><USER8> Ooh - notice that Dave has switched from a fluid width layout to a fixed width one in the last couple of days? That's an interesting move. My instant review is that the fluid width layout was better ;-)

<comment><USER9> For the iPad:

[http://www.scripting.com/stories/2010/05/23/makingStoriesBea...](http://www.scripting.com/stories/2010/05/23/makingStoriesBeautifulDay2.html)

<comment><USER8> That's interesting, but I use the iPad a lot too and the fluid layout worked fine on it too, since it just spans to the max width.

Maybe he was trying to focus on portrait and fit into 768 pixels without the iPad kicking in its portrait scaling, but there are other ways of doing that that don't mean you have to squash your site into 768 pixels width and annoy desktop users.</comment></comment></comment>


GCC 4.8 release - <AUTHOR> http://gcc.gnu.org/gcc-4.8/changes.html

<comment><USER2> Oh well, this release page has been up for months! Please consider changing the title to "GCC 4.8 upcoming changes" or something like that. I got confused that 4.8 was released today!

Like already pointed out, 4.8 is _not_ yet released!

<comment><USER3> It seems what happened today is:

      The GCC 4.8 branch has been created and a first release candidate
      is being prepared right now.  The branch is closed for now.

<http://gcc.gnu.org/ml/gcc/2013-03/msg00124.html>

<comment><USER4> "As of this time no releases of GCC 4.8 have yet been made" (<http://gcc.gnu.org/gcc-4.8/>).

<comment><USER3> For that matter: "Last modified 2013-02-08."

</comment></comment></comment></comment><comment><USER5> Actually only the release candidate of GNU GCC 4.8 is released. The final release is expected in about a week or so: <http://gcc.gnu.org/ml/gcc/2013-03/msg00127.html>

</comment><comment><USER6> _GCC now uses C++ as its implementation language._

It looks like C++ is getting some traction. BIND has also made the switch to C++ (and Python).

<comment><USER7> Isn't it just the subset compatible with C for now?

<comment><USER8> That's what it was for a couple of years, but now they've flipped the switch to where a C++03 compiler will actually be required.

Note this is drastically different from a requirement to use advanced C++, coders can still use the subset of "C style" C++ if that's easier for them.

</comment></comment></comment><comment><USER9> The new AVR enhancements are interesting. They added Embedded C fixed-point arithmetic. I wonder how often Arduino folks will use this.

</comment><comment><USER10> They had me at -Og.

<comment><USER11> The -fsanitize=address and -fsanitize=thread sound like a very useful feature too, a nice complement to valgrind and -fmudflap.

</comment></comment><comment><USER12> Nice! Could someone plz explain to me what it's not technically easy to have the ASan profiler also on windows? In other words, do you prefer other OSes for development due to tools like ASan?

Thanks

</comment><comment><USER13> Especially with the C++ change, GCC seems to be on the verge of crashing in under its own weight. I have the feeling that clang or something else, something simpler, will eventually prevail.

<comment><USER14> Clang and LLVM are written in C++...

<comment><USER15> I can't be sure, but I don't think that was the point of the parent. The comment was with respect to the change, not a criticism of the language.

<comment><USER8> The "change" has been underway for years now, it's not a sudden event by any means. Even now, where a C++ compiler is "required", it's not as if a drastic alteration of the code base has been performed. Given that, all I can read the complaint as, is a criticism of the language chosen.</comment></comment></comment></comment>


Ask HN: Job application - <AUTHOR>

Hello all,
I have been trying to get into job from past 5 months.
After several trails of job applications I want to try this approach:
I am willing to work to any company for 3 months in any technical position like coding, system admin, security, research or ... foo. If you are willing to pay my apartment rent + food [which I promise not be more than 750$ per month], I am ready to start hacking the project! This step will definitely give an exposure to show my technical abilities.
If any manager wants to give a shot please email me at aliengeek4u at gmail dot com. I appreciate for taking some time to read this !!!
Note: I am 99.99..INF% sure I will be an asset to any company which hires me.
ps: All comments or suggestions are welcome :)
pps: Message has been chopped down after patio valuable thoughts! <comment><USER2> Hiya. Your English is pretty good, but non-native. You need to work on having cultural fluency as well as having linguistic fluency. Americans and, in particular, Americans with hiring authority _do not respond well_ to excessive modesty. You should stop saying things like "I have to admit that I am not the smartest person" and "My brain has been dumb for several years."

Saying things like this will make Americans with hiring authority think that either you are being sincere and are stupid (no hire), that you have severe personality issues which will make you difficult to work with (no hire), or that you are culturally inept and will be difficult to work with (no hire). There is a fairly easy way to avoid these difficulties: find a model of culturally correct behavior and act like they do. Your model person would likely a) be confident that they are well-qualified with regards to what they want to be hired to do and b) not brag _excessively_ about their competence. Don't worry about where the exact balancing point between confidence and bragging is -- any attempt to move closer to it will make you more successful at locating employment than you are currently.

Also, getting employed is a matter of selling something (selling your future employers on the notion that they should employ you). Successful sales is more about them and their needs than it is about you and your story. Your relationship with your parents, your home culture, the laptop you bought, etc, do not constitute reasons why a particular company should hire you. You should not talk about them. Instead, you should figure out what the company needs and point to specific, identifiable experiences which demonstrate that you will successfully be able to meet that need.

<comment><AUTHOR> Hey Patrick, thank you very much for your thoughts! All are digested ;)

</comment></comment><comment><USER3> Perhaps it would be beneficial to decide what specifically you most want to do. If your 5 months spent job searching have been you informing employers that you're willing to do anything and everything they don't take you serious because you don't specifically want to do the thing they want to hire someone to do. This is pretty much what Patrick said to some degree. If you know what they want and revolve your resume/cover letter around this, it should help a lot. You don't have to send everyone the same resume.

My other comment is your email address. I hope you're not putting "aliengeek4u" on your resume. It's fine for normal personal use but perhaps you should register a second email in some form of your name.

<comment><AUTHOR> "You don't have to send everyone the same resume" - As of curiosity isn't kinda cheating? Nope, I am using my regular gmail id. Thank you for all your comments.

<comment><USER3> Not cheating, I just mean that it's usually recommended you tailor your resume (especially your objective, if you include this) to highlight your skills and interests relevant to what you're applying for.

</comment></comment></comment><comment><USER4> Further suggestions:

You might want to state where you are currently located. For most companies the costs of relocation outweigh any saving on salary you are offering.

What skills do you have? Have you ever done any coding, system administration, security or research? Do you have a resume online you can point people at (or linkedin)?

 _Note: I am 99.99..INF% sure I will be an asset to any company which hires me._

Write this instead: _I am confident I will be an asset to any company which gives me an opportunity._

<comment><AUTHOR> Hey nick, I tried checking in guidelines section on how to edit the article but unable to find any info.

FYI: I was able to edit for few minutes after posting, but now I don't see that option.

Any suggestions?

<comment><USER4> I don't know, sorry. It probably has a time lock on it.

<comment><AUTHOR> Yep, sounds to me 60min time lock.

</comment></comment></comment></comment><comment><USER5> You should read this: [http://www.aaronboodman.com/2010/10/wherein-i-help-you- get-g...](http://www.aaronboodman.com/2010/10/wherein-i-help-you-get-good- job.html)

<comment><AUTHOR> Thank you for the link.

</comment></comment><comment><AUTHOR> update: I am willing to relocate to any place in USA. No expenses needed for relocation.

skill set: Interested to program in c and python, worked in linux, solaris, aix, and windows environments.

Experience: 3+ years in system admin, 3+ years in coding, 3+ year reading security articles, didn't code anything related to security issues, 4+ year in research.</comment>


Ask HN: Would you buy webapps? - <AUTHOR>

I'm not sure about my position on buying and selling webapps. This comes to mind due to the recent 250k sale of retweet.
What I'm thinking is about the practicality of it all: content sites and blogs are simple: anyone can take over.
But webapps deal with languages, and frameworks, and good or bad code.
What's your stance on buying and selling webapps in the short term? <comment><USER2> I don't see how the fact that it's a web app, content site, or desktop software would matter. You value an asset, taking into consideration the acquisition and maintenance costs. I haven't figured out the $250k for Retweet but I tend to be more ROI-based with my purchases.

As far as good code vs bad code, if you intend on maintaining the site then you probably want to setup a code review via remote desktop where you can review some of the code.

I'm in talks to buy the assets of a company that developed a desktop software program. The software was developed in an archaic language I've never heard of and am not interested in learning, so I was pretty frank that the source has no value to me since my interest is in converting the customers over to my desktop product. Had the code been in something like .Net that could easily be maintained, I'd place a higher value on the asset.

I'm also in the process of selling a custom classified site written in .Net. When I sell the site, I'll be providing the contact information of the contractor developer who created it. The new owner will have the option of continuing with this developer or finding their own developer.

</comment><comment><USER3> I'm not sure how 'qualified' I am to give you an answer, but I do technical due dilligence as a part of my consulting work, and some of that has been evaluating web based applications.

In general the criteria I use are:

      - is the team a part of the acquisition or is it just the code

      - how much of the knowledge about the code is present in
        the heads of the authors and how much of it is
        transferrable

      - is the codebase in a language that you can easily get
        developers for

      - how much time is invested in the code

      - what is the 'backlog' in terms of open critical tickets
        and such

      - what is my estimate on time to re-write the whole thing
        from scratch (some help here from wordcount and gzip)

      - how well will the current implementation scale

All those (and a whole bunch of other, but less relevant) criteria together make up the main ingredients of what goes in to determining what the value is of the code behind a web app.

I hope there is something of use in there for you.

</comment><comment><USER4> As with any business, you'd want to do due diligence. If I couldn't look at the code, I wouldn't buy it. Most web apps could be reproduced without ever looking at the code behind it, so allowing you to do so shouldn't be an issue.

Buying a web app makes sense when:

1) you have a clear path to making more from it than you'd pay for it, in a short enough amount of time that it makes sense to buy the app rather than spend it elsewhere / develop it yourself.

and you:

a) have a relevant advantage that the current owner doesn't, like target market connections, a distribution network, or an app with complementary functionality.

-or-

b) can get an advantage with the app, that you need for something else.</comment>


Inside Evasi0n, The Most Elaborate Jailbreak To Ever Hack Your iPhone - <AUTHOR> http://www.forbes.com/sites/andygreenberg/2013/02/05/inside-evasi0n-the-most-elaborate-jailbreak-to-ever-hack-your-iphone/

<comment><USER2> This is about the old ios6 evasi0n jailbreak, not the recent ios7 evasi0n7 release.

More technical explanations than the linked article can be found in the links section near the bottom of [http://theiphonewiki.com/wiki/Evasi0n](http://theiphonewiki.com/wiki/Evasi0n)</comment>


Cockroaches mysteriously disappearing from Russia & neighboring states - <AUTHOR> http://english.pravda.ru/science/earth/21-04-2008/104964-cockroaches_red_book-0/

<comment><USER2> We have used every kind of poison known to humanity to make cockroaches die. Now, they are dead. So, we blame it on the cell phones.

Logic, we love you.

</comment><comment><USER3> >1\. Food contains too many genetically modified elements. >When these elements got into the cockroaches with food >wastes, insects died off.

They can adapt so quickly to poisons that it seems unlikely.

>2\. Modern plastic constructional materials and fabrics are >unfavorable for living creatures.

So why do we still have them in Europe?

>3\. High frequency mobile communication is to be blamed for >cockroaches' disappearance.

All studies about high frequency showed no effect on humans, but I'll admit you can't conclude anything about cockroaches.

But why do we still have them in Europe?

>4\. The ozone layer disturbance changed their biorhythm.

What?

What about a natural predator?

</comment><comment><USER4> It's Pravda. They aren't exactly worried about sourcing or accuracy. They're hardly better than a tabloid.

</comment><comment><USER5> So long, and thanks for all the poop.

</comment><comment><USER6> > High frequency mobile communication is to be blamed for cockroaches' > disappearance

Is there any study backing this?

<comment><USER4> It's Pravda. They are barely a step above Weekly World News.

</comment></comment><comment><USER7> Last time I was in a student dorm in Saint Petersburg (3 years ago), cockroaches were in great abundance. However, in any remotely hygienic environment I haven't seen them ever in my life.

I suspect, this is mostly due to usage of powerful chemicals.

<comment><USER7> Now that I've googled a bit more, I've found some hilarious versions:

        * Cockroaches are preparing for war, and they need soldiers
        * Cockroaches are actually scouts for some alien civilization, and they already know enough

</comment></comment><comment><USER8> I'll make sure to carry a towel from now on, drink beer and eat peanuts.

</comment><comment><USER9> wait, didn't we actually want to get rid of them?

</comment><comment><USER10> There are cockroaches in Ukraine.</comment>


Self-employment is anything but the dream - <AUTHOR> http://www.theage.com.au/small-business/blogs/work-in-progress/and-the--top-10-employers-are/20101029-175yr.html <comment><USER2> My father (who has always been self-employed) once said "the best thing about being self-employed is that I can choose my own hours. I can work whatever 100 hours a week I want."

<comment><USER3> My father's saying was "I can work 24 hours a day whether I want to or not". He also used to say "If you go to the bank for a loan and you say you are 'self-employed' they hear 'un-employed'"

<comment><USER4> I remember a story about a business owner (in India I think) whose employees could get loans but he could not. They were employed after all.

<comment><USER5> Surely he could have just get himself employed as a director of the company?

<comment><USER6> Been one of those entrepreneurs - Being employed as a director is not seen has employment. My employee just got loan of 2.2 million rupees to buy a vehicle (depreciating asset)and banks are not clearing my loan of 2million to buy a house (asset) when I am paying other 2million. True story.

</comment></comment></comment></comment></comment><comment><USER7> I never got the memo that said I was supposed to work 100hr weeks while self- employed. I don't think I've ever worked more than 40 on any of my startups, and often ramp down to something like zero hours per week for months at a time. Thus far I haven't seen any ill effects.

It's all about building things that bring in income, and fortunately for us software types, value is often completely disconnected from the amount of work it takes to build something. So sure, you can spend 100 hour weeks for years on end building something huge and low margin, or you can spend 20 hour weeks for a few months building something small and high margin.

Getting to make that choice is the nice thing about being self-employed.

</comment><comment><USER8> _That might be why in this week's survey, two-thirds of self-employed people said they're living anything but the dream. A dream employer for them is not their current status of self-employment._

Little data given, but this strikes me as one of those hard to measure things. It's like how surveys show that children don't make people "happier" and yet you'll be hard pressed to find any parent that would give it up.

Similarly, these 2/3 of people self employed could get a traditional job.... but they don't. I guess it depends how the questions are worded. Could things be better? Of course. Would you give it up? Well, presumably they could.

Relevant cartoon: <http://theoatmeal.com/comics/working_home>

Edit: also curious about how many people who do work in the companies in the top list actually list their own companies. Grass is always greener sort of effect. What percentage of Google employees consider Google their "dream job"?

<comment><USER9> _Himilarly, these 2/3 of people self employed could get a traditional job.... but they don't._

This isn't necessarily true. The hacker news world of prep school kids that turn down $200K/yr junior investment banking jobs to work on their Facebook gaming startups sort of warps this perspective. Many, if not most, self employed people are self employed because they would never get hired at a regular job. There was even a time when this was true in Silicon Valley.

<comment><USER10> _The hacker news world of prep school kids that turn down $200K/yr junior investment banking jobs to work on their Facebook gaming startups sort of warps this perspective._

There's something that strikes me as odd about this statement; I didn't realize we were all supposed to be prep school kids with the option of having $200k/yr junior investment banking jobs.

</comment></comment></comment><comment><USER11> Well let's see:

Work steadily for 40+ years with no hope of ever "striking it rich", getting bought out or anything else. Just grind away with (hopefully!) gradual increases every few years.

vs.

Work much more than is reasonable for less than you can afford but if you're lucky and good the sky isn't even the limit.

Self employment may not _be_ the dream but in my mind it's the option that can at least _become_ the dream. I don't see putting in 45 a week until I'm too old to do it anymore, trying to make someone else' dream come true ever being that and I'd be _extremely_ depressed if it were.

</comment><comment><USER12> Self-employment _is_ the dream because there are no _ceilings_ to your growth. People have this notion of self-employment being a wonderland of hammock reading and money easily flowing in. It can be those things but it's about loving what you are doing and not trying to get free from what you are doing.

When you love what you do, a 70 hour work week is nothing - you feel purposeful and valuable. You did it because you have a dedication to a dream or a vision. One that is _yours_ and not someone else's.

<comment><USER13> Agree, I was working 60 hr weeks and earning a nice investment banking salary. I now work every waking hour and earn maybe 1/8th as much. We have to fight for every bit of progress that we make, but I love (almost) every second of it. All types of employment have their trade offs; you have to figure out what you are comfortable with and go with it.

</comment></comment><comment><USER14> Someone once told me the two most overrated things in life are owning your own business and natural child birth.

As a dude, I cannot answer for the latter, but as a business owner oftentimes I would agree with the former.

</comment><comment><USER15> We always miss what we don't have and never see what we already have.</comment>


Dear Agile, I'm Tired of Pretending (2018) - <AUTHOR> https://medium.com/columbus-egg/dear-agile-im-tired-of-pretending-d39ab6a12003 <comment><USER2> I've been developing software for over 20 years, and I still can't estimate how long something will take me when I've never done it before. This uncertainty needs to become more than just a stick to beat developers about the head and shoulders with. Most of the time the PMs understand this, but there have been many projects where they just don't get it. I have suffered great anxiety from being forced to give estimates when the truth is I have no clue. It depends on how easy it is and how many unforeseen issues I encounter. It was so bad that once my husband asked me how long it would be before I was done cooking something, and I practically had a meltdown. That's when I knew it was time to leave that team. Can we stop pretending we can forecast the unknown? (edit typo)

<comment><USER3> No.

Even bad estimates are better than _no_ estimates. If you are having meltdowns your reputation is being tied too closely to your ability to give estimates.

You must never turn estimates into a promise, always remind people they are estimates.

Want to give _fast_ estimates? Here's how:

1) first determine the scale of the task? Is it a year, month, week or day kind of task?

2) Then, it's just 3 of those units. The smallest task takes 3 days. One day to completely fuck up, one day to figure out why, one day to get right. The longest takes 3 years. One year to fuck it all up, one year to learn why, one year to finish it.

I suggest never giving estimates in units smaller than a day. They just become noise. If a task is smaller than dayscale just say the task is too small to provide any meaningful estimate but won't take more than a day.

<comment><USER4> > Even bad estimates are better than no estimates.

No estimate is clearly better. Here's a common story I've seen across multiple companies.

1\. Marketing management asks Engineering management how long it takes to do feature X so they know when to launch the online ad campaign.

2\. Engineering management then asks potentially good coder how long it will take. Coder replies with a time and "it's just an estimate."

3\. Engineering management reports to Marketing that coder's estimate leaving off the most important caveat, and Marketing treats that as the gospel truth.

4\. Coder takes longer than expected because of some bad technical cruft that some other engineer put in because he was potentially rushed or just plain inept.

5\. Marketing is pissed because they now have to withdraw the ad campaign, and starts blaming engineering.

6\. Under increased scrutiny, Engineering gets a bad reputation, who then throws the coder under the bus in front of Marketing and other managers.

7\. This shows up on the coder's annual review who then leaves.

8\. Engineering hires replacement which will have a 3-6 month learning cycle, and potentially writes worse code than the person that just left.

EDIT: The point is that if there's no estimate, management has to deal with the uncertainty that the coder experiences. Hope for the best, plan for the worst.

<comment><USER5> >1\. Marketing management asks Engineering management how long it takes to do feature X so they know when to launch the online ad campaign.

Why can't Marketing just wait until the feature has been built to launch their campaign?

<comment><USER6> Because campaigns have to be planned ahead too - anywhere between a few weeks and a year or so, depending on the size of the project and the company, and often timed to match big trade events.

And there's always the possibility that if you announce too late competitors will eat your lunch.

One way to handle this is to spend some time on a formal estimate. Two to four weeks of R&D to scope a project can help narrow estimates to something approaching realism. You'll still be wrong, but you're less likely to be hopelessly wrong.

Asking someone for an instant opinion is madness. That's not an informed estimate, it's just a guess, and usually worthless.

<comment><USER7> Sounds like marketing needs to be agile

</comment></comment></comment></comment></comment></comment><comment><USER8> Any software development methodology or process is going to come up short if it ignores the fundamental nature of software development, which is: _We do not know what we 're doing until we do._ Any process or methodology that tries to extract _promises_ out of the software development organization about things that are still in the _we do not know what we 're doing_ phase is going to result in disappointment at best and serious harm to the overall effort at worst.

And it turns out that it's not unusual for software developers (and consequently software development organizations) to spend more time in the _we don 't know what we're doing_ phase than the _we do know what we 're doing_ phase. That sucks from a management point of view, but no amount of process is going to make the problem go away. The best you can do is manage the risk. We don't need good processes or methodologies nearly so badly as we just need management enlightenment about how software development actually works.

<comment><USER9> That's the truth, except, I can't tell clients that "I'll know how long it will take when I'm halfway done." The best I can do is look at prior work and multiply by the LarryDarrell Constant of 1.5.

<comment><USER10> > multiply by the LarryDarrell Constant of 1.5.

Funny thing. If you do this organizationally, then you eventually end up making larger and larger estimates. IMO it is better for management to understand the inherent risks associated with engineering estimation and build the padding on their end.

<comment><USER11> Hofstadter's law: It always takes longer than you expect, even if you take into account Hofstadter's law.

</comment></comment></comment></comment><comment><USER12> I was prepared for our weekly "I Hate Agile" post, but this one is actually really great. It's a lot of the arguments I make to Agile haters. The fundamental problem that drives most agile failures isn't in the team's execution, it's in the business' expectations. One side is signed up for incremental delivery, and one side is set up for a fixed scope and deadline and the result is misery. I think this article makes a lot of good points. Scrum isn't the complete answer, but it's a big step in an organizational transformation. I think it's suffered a lot from being oversold.

<comment><USER13> > _One side is signed up for incremental delivery, and one side is set up for > a fixed scope and deadline and the result is misery._

This is a brilliant summary, thank you.

The best 'agile' experiences I've had are situations where the 'clients' are directly involved, often within the same organization. Instead of a hard scope or deadline, there's just a shared interest in producing a valuable product efficiently, and the users are on-hand throughout the process for feedback and reevaluation.

The worst experiences have been waterfall contracts, developed by an internal simulation of agile. The software team does frequent "releases" to business or management, who provide feedback and feature requests, but the actual recipients are uninvolved outside of occasional demos, or contacted only indirectly by non-programmers. The result is almost always thrashing, with time and effort spent pointlessly satisfying the forms of agile even though the real timeline and customer feedback are unyielding.

<comment><USER14> > _waterfall contracts, developed by an internal simulation of agile._

We call this _wagile_

<comment><USER15> We call it scrummerfall.

<comment><USER12> We call it frAgile.

</comment></comment></comment></comment></comment><comment><USER16> _Agile never gave organizations a holistic, viable alternative to Waterfall. Because there's a difference between theory and practice. Product work is more about practice. When we complain about "AINO" (Agile In Name Only), we're not being honest with ourselves._

I agree with most of the article. Specially the keep-learning part.

 _All Agile did was put software development teams unfairly under a microscope._

I believe Agile has been tremendously beneficial for the industry globally, especially in some subtle ways. For example, Agile says you have to communicate a lot, if you want to get software done. Here is the subtlety: if, _today_ , you stop telling the average programmer to communicate, they will stop and go back to silo mode, "naturally". At least some of them. If you think about software at the industry scale, you have to think about a wide population which require processes.

I was once working in a nice little company where, one day, they introduced agile. It was so much beneficial. Before, the bosses thought that talking was simply a lost of productivity. You're a programmer right? So code, don't talk. So we would develop software without talking to each other. After we had daily meetings, scrums things and stuff. Our velocity has sky-rocketed.

You have to realise that before Agile, a fair portion of all software development projects that were started would simply bust and never get shipped. The code is a complete monster or the budget is nuked. When I started in the company I just mentioned, I started working on a codebase that was the worse code I've ever seen in my life. You would touch one line and everything would stop working. It was a condensed piece of spaghetti with hacks on top of hacks on top of hacks. Software architecture? That requires some talking and thinking, forget about that, not permitted.

Now I agree with you, agile is not much useful for a hacker who consistently get software done and understand deeply what's happening.

 _edit: not that I 'm an agile guru or anything. Actually I only know the thing superficially. I show up at the meetings, when I'm ask how hard something is, I answer, then I mess around with my office friends. Still I can appreciate it works much better than any process the bosses can come up with._

<comment><USER17> I was interested in comp sci precisely because I didn't have to talk to people, an area where every interaction is a performance. I want to be alone - what's so wrong with that?

<comment><USER18> There is nothing wrong with that, but careers under capitalism are about _signaling value_. I hope you find a place (or have found a place) where you're appreciated. :)

<comment><USER19> I'm not sure why you're being downvoted but some of the best career advice I've heard is someone saying you should assume when you go to work that you're working under a communist dictatorship. I.E. Toe the party line, make your boss look good, (pretend to) eat up the company propaganda, assume the leader(s) (C-suite) will do whatever they want, when they want, especially giving themselves bonuses regardless of company performance.

It's a weird contrast to normal life, considering a lot of us live in democracies, but once I understood this and started acting accordingly, it helped me handle my work life.

<comment><USER20> I don't know if that's great advice, but its certainly advice that will help get you promotions and salary bumps.

Like anything there's a grey zone here. Understanding the political realities of a business is highly beneficial and will help you move forward with the company and let you know when to pick your battles. But I've watched people who do nothing but this lose the trust of those at their level. And that trust is crucial for agile development. I also personally feel like pushing back on the company when appropriate can indeed provide a lot of value to the organization. "Why are we doing this meeting?" "We need another week for testing" "I'd like to see the roadmap you are planning". Just don't push back all the time.

</comment></comment></comment></comment></comment><comment><USER21> I have a theory that commercially successful software development methodologies are like diets: they have to be almost impossible to follow. This ensures that when you fail to lose weight/achieve bug free software, you blame yourself for not following the rules exactly, rather than the rules for not working.

<comment><USER22> That's probably a very apt metaphor, but there's an upside too: many diets actually do at least temporarily help people in spite of their irrational basis, just because $random_diet causes the dieter to observe and reflect on their eating habits more carefully in general. Even a non-sense diet like "eat only foods colored yellow or red" probably does a lot of people a lot of good, compared to their usual state of being completely unconscious of their awful habits. Same goes for software development practices.

<comment><USER23> I think with this analogy you're presuming that people are exposed to a variety of foods and there is some positive correlation between action and awareness. However, for someone who only ever goes to McDonald's to eat, they'll just switch to french fries and ketchup for your nonsense diet.

</comment></comment></comment><comment><USER24> "Thou shalt not be negative" (HN) - well I'm sorry. Just some example text:

> _both Agile and Waterfall are focused on building. Design is about > validating._

or

> _So…what's the way out? It's a smart focus on clear outcomes, not output, > with roadmapped outcomes replacing planned milestones, with trusted product > teams, not project teams, empowered to vet assumptions and discover the > minimal path to value._

Satire? Enough words to fill a hot air balloon or two. "Smart" focus, "clear" outcomes, "outcomes" vs. "milestones"(?), "trusted" product teams (as opposed to... what?), "empowered" etc.?

Far more interesting than the contents of many links that make it to the HN homepage is discovering the fact that they do so.

<comment><USER12> Honestly that statement is the nail on the head for me. There's a huge distinction between an output and an outcome and a huge distinction between a project plan and a road map.

<comment><USER24> > _between an output and an outcome and a huge distinction between a project > plan and a road map._

I mention neither of those.

I'm not complaining about your reply, I think it shows how those texts are (to be?) used: Just like art. You project your own experiences into it, it's more about getting you to think. So naturally different people are going to react differently and read different things into the same text. That's perfectly alright - you get something out of it (only) if you put something in. If there is nothing to begin with, which may just be lack of experience (new programmer), you'll get less out of it. If you have two decades large project experience in various companies and teams you'll get a lot out of it. Let's attempt to make the best out of it then, out of any text, if we are presented with that opportunity and the headline got us to click on it :-)

<comment><USER25> I think you misread the part you quoted, while GP read it correctly - it's comparing outputs and outcomes, not outcomes and milestones.

<comment><USER24> No I did not.

Let me quote again what I already quoted:

> _with roadmapped outcomes replacing planned milestones_

"outcomes" vs "milestones"

See?

<comment><USER26> > It's a smart focus on clear outcomes, not output

</comment></comment></comment></comment></comment></comment><comment><USER27> You don't hear the name Joel Spolsky much any more, but he was pretty influential in software process thinking in the 90's - not really for being particularly insightful or original, but more because he was one of the first people who thought of writing a blog about software design. One of his early "observations" about software project management was that "you wouldn't buy a pair of jeans without knowing how much they were going to cost, why would you expect your manager to sign off on a software project without knowing how much it was going to cost?" The utter blithering stupidity of this perspective highlights how managers look at software design: the purpose of software methodology is to put a fixed cost on every software project. As long as that's what they're looking for, software methodology is going to continue to be a lost cause.

<comment><USER28> What's stupid in wanting to get an idea of how much a project costs in order to decide if it's a good idea to pursue, let alonr allocate resources?

<comment><USER29> "How long will X take?"

"I don't know, I've never done X before."

"Yeah, yeah. It doesn't have to be perfect analysis, just a rough idea for scheduling. Not written in stone, ha ha."

"Uh, a week?"

"Okay, great, so if I say 8 days you should have it done by then?"

"Yeah, I hope so."

"Great, thanks."

Day 3: actually doing X requires unforeseen Y and Z which will each take a month.

"We need to add Y and Z to the schedule, which will each take a month."

"There's no room for that in the schedule."

"Then I can't do X"

"We've already costed X and committed to it. We've got to do X. We need to make X happen. When can you get back to me with a path to green for X? And also, let's schedule a post-mortem to figure out why we missed on X."

At the post-mortem, PM doesn't show up: "Uh, turns out we missed on X because I estimated it too quickly and the PM committed to those estimates. I didn't know about Y and Z when estimating, and these are things I could have done to detect them as requirements if I had known to do so."

Email from PM: "Hey, could you give me an estimate for X'? Doesn't have to be perfect, ha ha."

<comment><USER28> > "How long will X take?" > > "I don't know, I've never done X before."

I fail to see how your example makes any case on how estimating how many resources a project needs is stupid.

At most your example argues that asking inexperienced and clueless devs to estimate stuff they know nothing about produces highly unreliable information.

The main difference between hacking away at a code base and software engineering is identical to the difference between construction workers and civil engineering. Sure, estimating is hard. Yet of you want reliable estimates you need to check with experienced professionals.

<comment><USER29> I've worked about 10 years at FAANG companies and I'm yet to meet the experienced and expert devs who are good at estimating things. I think your characterization of "inexperienced and clueless" devs is off.

The reason I think my example illustrates a problem is it's moving away from agile. I shouldn't estimate X without understanding it? Okay, I'll take the time to figure out, look around corners, etc. I realize I need Y and Z. I've got to estimate those, to estimate X, so I start working with other teams to figure these things out, and drawing up plans and schedules and who's doing what when to get all this stuff delivered. Now we're basically at the waterfall model where we're planning everything out before doing it.

The other problem is that all the process is genuinely a waste. If we need X then let me work on it rather than do all the planning and scheduling nonsense. The schedule will be wrong anyway. If I have problems, need help, etc with X then I can raise those concerns and management can react in an agile way.

<comment><USER27> > If we need X then let me work on it

If you look through the managers who are weighing in on this thread, you'll notice a common perspective: they don't trust you to actually work on something. That's why I have so little hope for any software methodology - even if it starts from something positive (like XP, which was the precursor to "agile", did), it will be turned into "I know all of my programmers are stealing from me, how can I stop them?"

<comment><USER30> In part because we still measure effort in hours instead of in wear and tear. That guy answering comments on Hacker News is probably trying to recharge, not steal from you.

I learned recently that the crane operators that unload cargo ships at some major ports can't work more than four hours at a time. The movements are too precise and take a great deal of attention. I think you can work two shifts per day but there's a mandated gap of some number of hours between them.

</comment></comment></comment></comment></comment></comment></comment><comment><USER31> The best way I've seen agile described is "designing code in a way that acknowledges change.' I think there's a lot of value in understanding that you may have to go back to the drawing board when designing parts of your program. I have little regard for the entire industry that has risen up around agile, however.

<comment><USER32> That makes complete sense as a good way to go about designing software, but I don't think I have seen anywhere else describe agile in that way.

</comment></comment><comment><USER33> There is a similar problem in the research world; the work must be genuinely novel (and fundamentally unpredictable), but funding organizations such as NSF/NIH/etc. demand a timetable and specific deliverables.

The problem is usually solved in three important ways:

1) making the deliverables as vague as humanly possible

2) promising experiments and not results

3) applying for grants for work that you have _already completed_ , and using the money to work on the next grant's project

The problem of having deadlines that are too far out is mitigated somewhat by the pressure to publish. Publishing has fixed deadlines but somewhat flexible deliverables.

</comment><comment><USER34> Agile is not science-based, it is an ad hoc bag of techniques that seem to have merit. As such you have to be able to reason about what your practices are and you have to relate everything to concrete business goals.

Your goal should never be to become "more agile". You should be looking to improve efficiency, to make sure you are building the right thing, to improve communication so that everyone is on the same page, etc. "Agile" is never going to magically improve anything.

<comment><USER35> "Agile is not science-based, it is an ad hoc bag of techniques that seem to have merit"

Each participant of "Agile" development should have this hung on their work place.

</comment></comment><comment><USER36> Uncle Bob wrote about this in _The Tragedy of Craftsmanship_ ([https://blog.cleancoder.com/uncle- bob/2018/08/28/Craftsmansh...](https://blog.cleancoder.com/uncle- bob/2018/08/28/CraftsmanshipMovement.html)). His perspective is Agile lost its way once the Project Managers stepped in. It seems to me the problem with Agile in practice today is there's too much focus on process and not enough focus on, you know, the actual software being delivered. Add to that a host of less-than-desirable ideas that have taken hold (don't even get me started on _emergent architecture_ ) and you realize modern Agile has become a cesspool.

What to do if you're on an Agile team? There's value in the _Lean Methodology_. Remember, the whole point was to deliver software your customer needs to fulfill their business objectives. Continually assess your Agile practice and see if what you're doing still makes sense for _the project you 're working on right now_ and for the current stage that project is in. This continual assessment with a focus on the end goal of delivering software can go a long way to addressing Agile's modern ills.

<comment><USER37> I had not heard of "emergent architecture" until you implied you hated it, and so I thought I would Google it.

I have no idea what emergent architecture is in the agile context, but the idea of emergence is fascinating to me, and has been ever since I read "Emergence: The Connected Lives of Ants, Brains, Cities, and Software" by Steven Johnson.

We see the idea of emergent design everywhere in nature and society. I'm not suggesting everything can be built and designed "emergently", but certainly some things can be. See the book (and concept of) "the cathedral and the bazaar". The idea of something useful coming into existence without central planning is an enticing one, and so I can see the draw.

<comment><USER38> Thank you for that book recommendation - I just bought it and am looking forward to reading it :)

I also had not heard the term "emergent architecture" in relation to software development. I'm intimately familiar with the concept of emergent order, though, and my grokking it was part of my "political awakening" in my 20s. It led me from being a libertarian-leaning conservative to an anarcho-capitalist. To put it another way, I believe that the system create by independent actors acting in their own self-interest naturally create the most efficient system possible within the constraints of the environment within which they operate.

There's a name for this concept when applied to company management, but I can't recall it at the moment :(. I want to say the word has a Greek root, and it reminded me of "autarchy" ("self organized") but that wasn't what it was called.

<comment><USER37> You'd probably like Milton Friedman's ideas, and I'd be surprised if you've not already come across his work and YouTube lectures.

There is something to be said for small government, but also can go too far: actors acting in their own best interest can obviously cause harm to society or to the larger group as a whole (See "tragedy of the commons").

Related to emergence is rapid iteration, and it's importance to analysing complexity, which is caputured nicely in "Boyd's law". See [https://blog.codinghorror.com/boyds-law-of- iteration/](https://blog.codinghorror.com/boyds-law-of-iteration/), and then see if you can find the referenced paper by Roger Sessions. (Sessions seemed to caputure the essence of "Lean Startup" before it was cool...)

</comment></comment></comment></comment><comment><USER39> _" It's just that everyone does Agile wrong."_

Not everyone. Some are very successful with it. The problem is that everybody wants to copy that success and tries to cargo cult themselves through it without understanding it.

 _" let's stop pretending Agile was some sort of cure all."_

That's certainly good advice. Agile is more of an attitude than a solution, and attitude is not going to solve all your problems. Even if you are as Agile as you can be, you still need to solve your problems. It's just that being Agile might make you more flexible and effective at solving those problems.

And Lean is certainly more comprehensive than Agile. And I don't think they contradict each other. In fact, they're very similar; they're both about empowering the people who are doing the actual work.

 _" management thinks the focus should still be scope and deadlines and efficiency, ignoring that the deadlines are arbitrary and the requested time estimates are a form of waste."_

Then management is not Agile and hasn't properly learned what it is. That is sadly common. Agile is not magically going to solve bad management, but Agile does emphasize keeping management at a distance and empowering developers.

 _" Agile actually tends to mask the core problem, which is a systemic, bidirectional lack of vertical trust."_

Does it mask that? I think it exposes it. Without that trust, Agile cannot work. Agile insists on that trust. I suspect that every case of broken Agile is caused by a lack of trust. Fix the lack of trust (or use a system that works without trust if you absolutely must).

 _" Did you know story points were actually invented to obscure time and help alleviate this problem? That backfired too, didn't it?"_

Yes I did and no it didn't. Every single team I've worked in over the past 6 years knew this and kept repeating it every time someone comes along and tries to match story points to actual hours.

This first half of the article suggests the author has mostly worked in very toxic management cultures.

<comment><USER40> I agree with a lot of what you said.

My last company (before going self-employed) had an agile environment and it was mostly a good system to work in.

I don't recognize the fairly strictly Agile (not AINO) environment I worked in in that article. Not perfect, but it worked and better than a lot of places that had no good methodology.

</comment></comment><comment><USER41> I agree that almost all of the orgs I encountered that were _Doing Agile_ were pretty horrible.

On the other hand, I've also been in orgs that were very successful in developing software in a way that we would recognise as being agile. We just didn't make a big deal out of it. And we didn't do standups (most of the time), or 2 week sprints, or retrospectives. We didn't even pair consistently: we split up on trivial stuff, paired on hard stuff, as needed and available.

In one org we started without TDD, and even without having much in the way of automated tests at all. But when we _discovered_ testing and TDD, boy did we ever embrace it. Not because anyone told us to (mid-to-late 90s, so no Agile Manifesto), but because the difference for us developers was _night and day_.

So _develop software_. Concentrate on what helps you develop software. In my experience, you will probably discover something recognisably agile all by yourself. So when you discover that, help yourself to what helps you. Don't make a big deal out of it.

<comment><USER42> What you are describing is exactly what Agile should be. You have a team of people who care about the craft and they slowly improve processes based on real world feedback and experience. If something doesn't work you drop it and try something else. This happens in environments where people respect each other.

<comment><USER43> Management does not want to hear that software development is a craft. They want it to be a trade, with fungible workers operating in a predictable process with fungible components. The great tragedy of Agile is that it was co-opted as the vehicle of this transformation. It was seized by management, weaponized to other purposes, and then aimed right back at us.

</comment></comment></comment><comment><USER44> Perhaps I've just always been extraordinarily lucky, but I've never heard the developers I work with complain about our Pointing and Development cycle (and I'd like to think I do try my best to 1) proactively ask them for feedback and 2) recognize and squelch any of my own reactionary defensiveness that comes from feedback).

One thing I see a lot in the comments is about time estimates and the amount of pressure that that brings and the rarity in which it works.

In my teams we NEVER talk about time of delivery with Engineering. I've always been trained to think of pointing as an estimate of "complexity" (e.g. 1 point is roughly the complexity associated with a copy change).

Then, by getting a track record of historical points completed in a week, we can transform our way from feature => complexity => time.

<comment><USER45> Complexity only matters if it can be correlated to time.

For example, if you ask someone to transcribe 10,000 pages of text, and you know that they type 60 words per minute, and that there are an average of 300 words per page, then you can estimate that it will take approximately 833 hours to transcribe.

If we followed your method of estimating stories strictly by complexity, however, this is clearly only a one pointer story. After all, there is nothing complex at all about the dull task of rote transcription, and all quantities are known and established.

When people talk about "complexity" in software development, what they are really talking about is how certain they are in their knowledge about all the things they have to touch. The more things they have to touch, and the more things they are unfamiliar with, the more things can unexpectedly go wrong.

Each task should really receive two estimates:

1\. How long do you think this will take?

2\. How certain are you of this estimate, given all the factors you are aware of?

That would be too much work, though, so people condense this into a single point value and hope for the best.

</comment></comment><comment><USER46> Ah, yes, the old "you're not doing it right, so read these 3 books and follow 10 bloggers every day" argument.

<comment><USER40> That was the weirdest part. "How many books do you read? Go read more books."

<comment><USER47> Seriously. Just keep piling more bullshit on top of the bullshit

</comment></comment></comment><comment><USER48> The biggest problem I've found with Agile hasn't necessarily been Agile itself but the lack of buy-in from company leadership. Even when we've had professional Agile trainers come in and tell them that not only must they embrace it for us to be successful, but they themselves must go through the training. They usually waive it off as something they'll get to eventually. Almost immediately we wind up with a bastardized version of Agile that basically doesn't work because the leadership doesn't understand why we "can't just" do something.

</comment><comment><USER49> Agile was dead to me when I finished my PhD and joined a company that paid a Scrum consultant more than they paid me to help us move tickets without knowing what was the project about.

<comment><USER50> You'll probably find that the most highly paid people in most organisations only have a fairly abstract understanding of the work being done. This is nothing to do with agile.

<comment><USER49> I am perfectly fine with paying more for a technical project manager, or a team lead who can help us glue things together and see the big picture. But I am not fine with hiring a consultant who doesn't know anything about our product and thinks that Agile has some magic to deliver products.

</comment></comment></comment><comment><USER51> Agile in practice is a way for Corporate to have its cake and eat it too: get the results and productivity associated with outstanding programmers, using the programming talent they have/can hire, with a minimum of risk exposure. Part of this is the attempt (also seen in other corporate quality efforts like ISO9000) to distill skills into process: to produce a book of rules that, rigidly enforced on relatively unskilled workers, will cause them to perform at the level of highly skilled workers. Hence my repeated quip that "Agile is attempting to emulate a good programmer with an array of average programmers". Unfortunately for Corporate, It Just Doesn't Work That Way.

Now I believe that Agile was started with good intentions, but today it is much more a motte-and-bailey doctrine. The motte being "Agile is the values in the Agile Manifesto". The bailey being "Agile is Scrum and SAFe, and all these meetings, ceremonies, and process are a necessary component of Agile". And I think this is why people fall into no-true-Agile discussions and eventually end up disappointed with something that showed a lot of promise. Agile started off a plea from programmers to Corporate, and it caught Corporate's ear. But once in Corporate's possession, it was deployed to serve Corporate ends only.

</comment><comment><USER52> I love this talk by Dave Thomas, one of the people whose names are on the original Agile Manifesto.

Among other things he speaks about the simplicity of the Manifesto, about the cultish movement and consulting services which rose around it and the cultish, distorted, complex vortex of BS that has formed around a super simple concept.

[https://m.youtube.com/watch?v=a-BOSpxYJ9M](https://m.youtube.com/watch?v=a-BOSpxYJ9M)

</comment><comment><USER53> The longer I stay in this industry, the more anecdotes I accumulate that suggest that software development is not _exclusively_ software development.

Software development is solutions development; but for a large subclass of problems, custom-built software that automates the tedious, predictable, and repetitive parts of the solution has been and always will be a competitive way to solve them. It's synecdoche, a metonymy for "software development [and other assorted disciplines of problem-solving]".

Software is the hammer in the toolbox. Things that look like nails get hammered. The hammer is so useful to organizations that have many nail-like objects sticking up, that handypersons who _only_ have a hammer in their toolbox can still work continuously, and may never need to do anything else but hammer things. This may become common enough that folks who also keep vice grips, screwdrivers, hand saws, duct tape, and penetrating oil in their toolboxes are _forbidden from using those tools_. They were hired for the hammer; they should use the hammer. And what's all this nonsense about non- hammer tools, anyway? We've never needed anything but hammers here, and that's the way we like it.

Agile is about advising organizations with strict rules and style guides for nail-hammering to loosen up and let the hammerers determine how to wield their own hammers, and possibly also choose the length and width of the nails.

Despite the amount I actually get paid, working upstream of the problem far enough to eliminate both the nail and the hammer--possibly using a more appropriate tool--is apparently above my pay grade. Agile never fixed that. It never even suggested that a non-hammer world exists. Even the CTO position might as well be chief hammering officer. The 'T' restricts the domain of authority. An organization that is agile instead of just Agile needs to have someone around that can meaningfully restructure the company itself, such that the assumptions already built in to its organizational hierarchy are not inevitably replicated in the processes of all of its subdivisions. That's why Agile never fixed anything. The CEOs still kept telling their CTOs to take charge of all the hammers and pound something out. Those companies founded to be Agile put different assumptions into their organization. When that changes, going through the motions of Agile won't help them any more.

</comment><comment><USER54> I've been a tech lead for 6 years and Agile has given me a lot of imposter syndrome because I can't seem to make it work for me. The biggest point for our org is to cost work items and realize a consistent throughput for our team on which we can make scheduling predictions.

Unfortunately my tasks tend to be nebulous. They involve investigating very large potential systems and breaking out smaller tasks, many of which won't be fully understood till we're in the trenches. How do I cost the time it takes to learn how Spanner will handle my design and update architecture accordingly? How do I cost "interrupt driven" work like getting buyoff on a given architecture? One of my OKRs was literally "Create a security model for a new foundational technology that is acceptable to all integrators, follows Google Cloud best practices, and can be represented in Kubernetes." How would you break that into (bi)weekly sprints? You don't even know what work you'll have to do until you go to a committee of stakeholders and get told where you have to go back to the drawing board.

<comment><USER55> See, this is about agile going wrong.... back in the early days of XP, a term started popping up "Brain Engaged", meaning that you don't blindly follow perscribed processes. The manifesto tried to capture this in somewhat frilly language. So be agile ( not in the dogmatic process sense of Agile with a capital 'A'). You have to do something like "create a security...blah blah". You don't have to do anything bi weekly, what you need is a way of of doing that where you can get feedback as soon as possible, how do you iterate through possibilities and arrive at a good decision? how do you involve the people who need to be involved in a way that you get good contribution? How do you make it so it is robust, how do you progressively work towards the goal while minimizing risks and failing fast? If nothing else, the core of agile is feedback loops and communication with the various people involved at a rate that people need.

</comment></comment><comment><USER56> "We don't want to follow the agile process..." followed by "why isn't agile working for us?!"

I blame the ambiguous manifesto.

<comment><USER57> The Agile Methodology is to argue about The Agile Methodology.

</comment></comment><comment><USER58> Oh look, it's the weekly "Agile is bad" post. I've successfully worked on two teams (including my current job) where we're a truly agile dev team. We value interactions over processes and tools, collaboration over contracts, and responding to change over following a plan.

Agile is not and has never been a cure-all. Scrum doesn't solve any problems. It's supposed to reveal the problems that exist and make them apparent to anyone looking at the scrumboard. If you don't change your team dynamic and just start looking at a JIRA board every day in 30 minute "standup" meetings, you're not agile. You're just cargo culting.

I'm tired of people blaming "agile" \-- which is mainly about self-organizing teams and adapting quickly to changing circumstances, for what's really a management failure.

</comment><comment><USER59> _But but but, the problem is Waterscrumfall, not Agile as intended in the Manifesto_

Here's the thing. Corporations are hierarchical. Human beings are hierarchical. We're also communal, but start putting us into larger and larger group situations where we're facing competition, stress, and we must engage in concerted effort, and we go into hierarchical mode.

Why does everything tend to go back to waterfall? It's because that's how management likes it, for reasons which go down to basic human nature in the kinds of environments technology companies create. Heck, even the financial markets demand fictional planning and forecasts of the unknowable future. Bosses want to be able to make plans.

One thing which Waterscrumfall has achieved, is that the iterations are much faster. That even fits the "next quarter" mindset of the financial markets.

<comment><USER60> Very well said. If there's a methodology that starts with: these are the people involve, these are their incentives and this is the expected outcome in game theory, then I think we'll be making progress on methodology.

<comment><USER59> Methodologies are pretty good about that in the short term. If Agile were bad at that, then it wouldn't have spread. I think the problem is more Agile in the long term. It's a more general problem faced by longer term software projects.

The answer might be to have shorter term software projects. Make everything more modular, have a standard backplane into which everything can plug into, and enable competing short term projects. I think today's trend is to make corporations into ecosystems, and this change might be able to shape incentives positively.

</comment></comment></comment><comment><USER61> > How does the first line of the Agile Manifesto begin?

It is kinda funny. For me the first line has always been:

> Individuals and interactions over processes and tools

And when I am asked to explain Agile, that is always at the core of my message. Form a team, let them do their work and start learning how they can improve how they do it.

From my perspective, the primary role of a (software development) Project Manager/Scrum Master is to create an environment where the team can optimize itself while not drifting into personal conflicts (create a healthy environment for collaboration and feedback). Everything else, like planning/risk management/change management/stakeholder management/reporting/presenting come afterward.

Those other things are important too (and should not be skipped completely), but if the team doesn't work, most of the other tasks create little value.

</comment><comment><USER62> I don't know any description of Agile better than meaningless buzzword. Buzzwords are not without value. They are a tool for selling a change without describing all the nitty gritty.

"Agile" is a lie that before 2001 nobody at all had ever done iterative software development, and all software process ideas that came after 2001 are by definition "agile."

"Agile", as with any other buzzword, is not for people who actually understand the details of the change; it's for someone who needs a handle onto concepts that would fly over their heads without a buzzword. Lets stop litigating the term, and move on.

</comment><comment><USER63> >Quit with the local optimizations already, and realize trust is the №1 issue.

So how do you trust someone who would outsource your position if they believed it would save money and reduce their work load? Management and employees have an inherently adversarial relationship that is poisonous to trust. I think it can still develop at times, but under our current culture where everyone knows someone whose job was made redundant with little recourse for their employment, you might as well be asking for a coconut to grow in an active lava flow.

</comment><comment><USER64> In my experience, these discussions boil down to anecdotes at twenty paces.

I've seen software development done very poorly and done very well, sailing under a variety of flags. But on an eyeballing there are far more bad experiences than good that get labeled "Agile".

Whether this is because of causal differences or because it's easy to affix any label to anything (and most experiences suck regardless of the label) is hard to tell without a control-group universe were the Agile Manifesto was never written.

If anyone needs me, I'll be counting to twenty.

<comment><USER65> How do you like agile at Pivotal? I'm curious, they have some really strongly heard opinions about how to do agile correctly.

<comment><USER64> Pivotal on the whole does software development as well as I've experienced. When you hit the sweetspot for our core practices it's really impressive. Everything just sort of flows.

Sometimes it goes off the rails. That is in the nature of things. But it goes off the rails as an exception, rather than as a rule.

If there's a key to the magic it's (1) hire for empathy as well as smarts and (2) reflect on what can be done better.

</comment></comment></comment><comment><USER66> In addition to the difficulty in making a meaningful estimate, I'm frustrated by how often management really wants to hear a particular answer and won't settle for anything but that answer. It can go like this:

1\. Developers size development of X and says it will take roughly 12 months.

2\. Management says the rest of the organization is going into system test in 9 months and needs X finished by then. Couldn't there be some way of speeding up the development of X without impacting the rest of the organization?

3\. X's developers say no, not really.

Now management tries one or more of the following:

\-- find someone else to size the work that X's developers will be expected to do

\-- hire some outside "expert" to size X

\-- hire contract programmers that claim to be experts in X that will join the X team

\-- suggest reduced functionality for X

\-- propose some modified "streamlined" component testing for X

\-- promise to provide X's required dependencies ahead of their scheduled completion dates so X's development won't be gated by these requirements

Now jump back to step 1. Repeat until X's team relents and says that maybe, just perhaps they might be able to finish X in 9 months if everything goes perfectly even though the company has never done X before

This is now passed up the management chain and it becomes part of the official overall system's schedule that planning, marketing, sales, finance, etc. is depending on.

Iterating over all of these estimates is a big waste of time. Management has already decided that they want X in the system and will keep pushing until an estimate comes back that they accept.

If X's team is lucky, some other team will fail to make their estimated completion date and X will end up with the 12 months it might take to finish X. Every team in the organization is hoping that it will be a different team that first has to admit that they will not make their date. This causes a kind of game of chicken where every manager is unwilling to be the first to admit that their team is going to miss it date. Consequently, every date in the organization cannot be relied upon. The distributed file system needs the TCP stack to be finished on time, but the TCP stack needs the ethernet device drivers to be finished on time and no one will admit slippage of any dates first.

<comment><USER67> > \-- suggest reduced functionality for X

Limiting the scope in a reasonable matter should reduce dev time, no? Assuming it's a true reduction in scope and not just lipstick on a pig..

<comment><USER66> Yeah, I thought that point might be confusing because I wasn't clear. You're right limiting the scope could reduce dev time and it might often be a welcome suggestion. It doesn't always go that way though and some proposals for modifying the functionality are costly because they can require re- architecting the design even before development starts.

Usually, lightening the ship by throwing functionality overboard in a panic doesn't happen until around half way through a project, but what I was referring to was the sort of impractical proposals that come from non- developers about how to reduce development time.

"Couldn't we remove the ability to customize user icons--everyone in the icon based user view can have the same icon." Okay, why have icons at all if every icon is identical?

"Deadlock, what's that?, do we really have to detect it in the first release?" Hmm...

"Can we leave out distributed shared virtual memory segments?" They weren't included in the original sizing

"Do we have to do persistent client caching?" Well then we will be no better than competing products.

"Does X have to run over both UDP and TCP?" That was originally a requirement. We can go back and examine that in light of other parts of the system depending on X.

</comment></comment></comment><comment><USER68> I personally found that a good methodology: each team member has clear area of ownership/responsibility. John does X, Jane does Y, Ann tests X, Jeff tests Y. Everyone logs their own tasks. We define and work towards a sprint. No elaborate planning, no estimates. The peer pressure is enough to get everyone moving.

Managers often tell me that my process is chaotic. They want more visibility and deterministic completion dates. We adopt Agile process. Now we have long sprint meetings. I think we get less done.

</comment><comment><USER69> One of the most useful segments of the article:

> _So find a good booklist. Follow some good blogs. Here's a start: If you > haven't read Sense & Respond, Lean Enterprise, A Seat at the Table, and > Everyone Is a Change Agent, I suggest you do so pronto. Your leaders too._

I'd add Peopleware to that list.

> _Start reading posts by John Cutler, Melissa Perri, Bob Marshall, Allen > Holub, Laura Klein, Erika Hall, Neil Killick, and branch out from there._

Anyone care to add their own handful of books and bloggers to these recommendations?

</comment><comment><USER70> > let's stop pretending Agile was some sort of cure all

But we won't. That's why snake oil salesmen were so effective: we want to believe in the cure-all. No matter how often you chastise, people'll keep buying it, because they're aspirational. They want there to be greener grass on the other side, and they're willing to try anything to find it.

The business doesn't actually care about Agile at all. It just has heard of the term and realized it has something to do with getting work done better. So leadership will say things like "We're an Agile organization now", not having the faintest idea what that means. A snake oil salesman doesn't need to know how snake oil works; he only needs to know what it promises, and how to sell it.

You can have the perfect software development methodology and people will still do it wrong. But if everyone has the same goal in mind, is highly motivated, and is willing to cross aisles to work with other people to do the best job possible, a methodology will naturally arise. Self-motivating humans can get some crazy shit done. The best working organizations I've ever seen followed no methodology. They just did what was needed to keep a site running well and making money, and it was kind of wonderous.

<comment><USER71> I think this is one of the most realistic responses here.

I think it's in most party's self-interest to keep playing the "agile panacea" game.

1\. Salesman sells something that doesn't exist, pats self on back

2\. Engineers asked to build integration/features on arbitrary timeline

3\. Doesn't happen, everybody unhappy

4\. Scapegoat needed. Says we didn't agile right. Project Manager hired / Deck of Fibonacci cards bought.

5\. Go back to 1

</comment></comment><comment><USER72> I'm currently experiencing this, and especially the whole delivery vs discovery, knows vs unknowns and their impacts on estimations. It's quite interesting, especially how differently you have to handle delivery vs discovery projects.

Basically, my team consists of some devops engineers mostly working on maintaining and extending the config management, and some other technical consultants who deliver and execute projects, ideally fully standardized.

For the standard delivery projects, it's extremely valuable to hammer the scope down into a precisely known constant and track the time spent to implement specific parts, as well as the delays incurred for different reasons. This allows for a strong, deliberate optimization of execution time with a measurable, predictable business impact as well as a reliable estimation of these tasks.

Discovery projects on the other hand? Yeah. We're pretty good at giving a lower bound for the time necessary by tracking similar tasks in a job. Extending a database entity is going to take a roughly similar time each time. Packaging, downloading and extracting binaries isn't going to differ that much in time from the last 3 times we did that. If you can identify a bunch of similar tasks you've done some time ago already, you can give a lower bound - "The tasks we consider familiar will take about 2 weeks".

But after that? Who knows. At that point we're rather estimating by asking: When do you stop feeling silly about it? Do you need a year to do this? A month? Two weeks? A week? A day? So usually we hand our project managers something like "This will take 2 weeks we know, plus 3ish weeks we don't know".

</comment><comment><USER73> I wish the post visited each of the principles. I can't find one I disagree with. It's all in the interpretation and implementation. Agile for me is not a single methodology that you develop. It's about refining and redefining processes that work for you team and org.

Principles behind the Agile Manifesto

We follow these principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity--the art of maximizing the amount of work not done--is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

</comment><comment><USER74> Most of my complaints about agile have centered around estimates. I'm of the opinion that anyone claiming to give accurate estimates for software development is a liar.

But I would like to see an organization that only had the team lead give estimations. This would remove the temptation on individual team members to size too large and fill the time, while also keeping management happy that they're receiving estimates for tasks they requested. Measuring throughput would immediately become a lot more natural since team members wouldn't fall into the trap of "When a measure becomes a target, it ceases to be a good measure."

I was actually just rejected from a job I applied to since I voiced a few small concerns with agile/scrum in the interview. My friend that joined that company recently reported he was doing maybe 10% of the work he and I were doing before he left my team. Even though I aced the technical portion they didn't want to risk hiring me since I asked their willingness to flex the rules of scrum.

</comment><comment><USER75> Organizations have to find their own way of working. It's going to change based on the size of the organization, its goals, and its people. With the exception of 1.5 years in a software company, most of my organizations have been internal IT. What I find is that user areas, who initiate projects with us, often don't have a clear view of what they want but think it's going to help the organization. Our job is to build models quickly so that they can validate an idea. Only after iterating through a few models can they reliably say the benefit/cost of the idea.

A very good engineer within my organization said to me, "Our job is to get something in front of them quickly so they can figure out what they don't want." Our successful projects have been ones in which we kept to this maxim.

I think this is what the author was trying to say but I had a hard time following his writing style.

</comment><comment><USER76> The whole point of Agile is to force the entire organization to recognize the fact that we don't know how long it will take to crate a satisfactory product. That doesn't mean just dev time but also figuring out what you want it to actually do throughout the process.

Instead of thinking you can write a perfect requirements document, then can just design and build it (waterfall) doesn't work.

The idea that you can have any sort of meaningful estimate even when you don't have perfect requirements is insane. Having an estimate with perfect requirements doesn't even work.

The most effectivly analogy I've used lately is: "Take your car to a mechanic and say "My car is making a funny noise, how long will it take to fix?" and see what kind of response you get"

</comment><comment><USER77> In the same way that software is eating the world, software management is eating traditional company management. Software projects are getting more important, sometimes centrally important to the future viability to more and more companies that aren't traditionally software oriented. Software projects are moving up the stack so they touch every part of an organization.

Agile is being blamed for problems that are really organizational, company- wide issues that a software team has to deal with because they now are central to how everything runs. The author's suggest to read more general business/organizational management type books is apropos, because the overall goal is agility of the entire organization, not just the software team.

</comment><comment><USER78> Software development has some fundamental challenges that have been faced since the start, and always will. Understanding them matters. Here are some of the big ones.

1\. Developers need to communicate with each other. A lot. This takes time. The amount of time goes up non-linearly with the size of the team. ( _The Mythical Man-Month_ claims a scaling law of n^2.)

2\. Adding process + documentation of various kinds can turn that from unbounded time spent speaking to a large but bounded written effort.

3\. Nobody is good at predicting schedules.

4\. Good news travels, bad news doesn't (until the last moment).

The traditional solution was to solve #1 with #2, put a lot of effort into schedules for #3, and get blindsided over and over again by #4. The average result was that the average delivered software project took over 2x what was estimated, cost over 2x, and was delivered with under half the promised features. But, no matter how delayed, usually didn't start slipping the promised deadline until about 2 weeks before the first official release deadline. And these were the success stories, since most software projects never really got delivered.

What Agile opened up was the perspective that there were other approaches possible. For example we can solve #1 by having small teams, which makes #2 unnecessary, solve #3 by making projects small enough to not need good prediction, which creates a feedback loop to avoid #4. And that is not the only valid tradeoff.

But this is not a one size fits all. Real world data shows that a team hits peak throughput at 5-8 people, declines, and doesn't get back to the same overall throughput until 20+. (After which it is almost linear, but with much lower individual productivity.) The teams as drawn on the org chart don't matter. The teams as they actually interact, do.

If you understand your options, and understand the tradeoffs, you can figure out how to customize the right solution to the people/organization. If you don't understand the tradeoffs, the best that you can do is blindly copy what worked somewhere else and pray that you got it right. And if it turns out that you didn't, develop superstitions about what you should have done instead.

</comment><comment><USER79> > "So let's get on board with continuous learning, and let's stop pretending > Agile was some sort of cure all."

Did anyone - who has seen shiney new panaceas come and go - believe it was a cure all? What it is, like MVP, is a way to mitigate risk. It doesn't eliminate risk. It can only mitigate it.

Furthermore, it still boils down to team and people. No tool will save a dysfunctional team. The key isn't the tool. The key is the key agreeing on the tool, and sticking to it. That is, tool is not a proxy for deep and solid team work.

</comment><comment> awinter-py IMO focusing more on systems than people in management is a mistake.

To the extent your work isn't repetitive, the only job process can do is set a cadence on communication & decisions. Yes 2-week scrum does this but in my experience it distracts companies from the real goal of management -- attaching subject matter experts to projects, i.e. concentrating time & resources towards a goal.

Process can get rid of bad people and share around your best people, but unless you have an assembly line, beware of any other claim.

</comment><comment><USER80> I think most of the people who wrote the agile manifesto said "Agile" been warped into something they don't agree with. Its supposed to empower teams, not enforced from on high to increase pressure on teams.

Heres's a good one by Dave Thomas. A quote: "Agile is an adjective not a noun". [https://www.youtube.com/watch?v=a-BOSpxYJ9M](https://www.youtube.com/watch?v=a-BOSpxYJ9M)

</comment><comment><USER81> "Agile transformations" are bad, but I still think agile itself is fine. Teams of self-organized, competent developers tend naturally toward agile-like practices. I've seen agile's story-centric model of development help new developers grow by giving them responsibility for specific, testable units of work.

As a lot of people have already said, the problems arise when managers expect agile to give them software on a timeline.

</comment><comment><USER82> So, Agile solved one problem when requirements are less than clear. Small batch sizes improve responsiveness, costing a bit of throughput. Like the old kernel HZ setting. Now you've got 99 problems, and responsiveness ain't one.

Yet folks expect Agile to solve everything for some reason, and forget all the other issues around bags of meat working together. Those continue to need handling and still get out of control at times.

</comment><comment><USER83> It is a balance: We don't know how long something we've never done before is going to take, and at the same time, we often need some time boundaries so we don't go off tangent building some wildly ambitious re-write of the world.

Perhsps the qustion we ask in projects shouldn't be "how long will this take?" but: "How long do you want to spend on this problem?".

</comment><comment><USER84> _" Stop unfairly putting dev under a microscope and letting everyone else hide in a black box. Why aren't we just as concerned with how strategy teams operate? Or how legacy architects are constraints in the system?"_

Are other ladders in an organization not subject to performance review?! Managers? PMs?

<comment><USER85> They usually don't get _anywhere near_ as much scrutiny.

Dev gets performance reviews _plus_ the microscope.

</comment></comment><comment><USER86> I just always double what I think it will take. I've been doing software now for 20 years and I have NEVER seen something come in on time. If I think it will take a month, I say it will take two. This has saved me more than I can count since I pad for the unseen circumstances that will occur.

</comment><comment><USER87> But think of your manager. He cannot stop pretending because that's all he has.

</comment><comment><USER88> It's almost like there is "No Silver Bullet".

[https://en.wikipedia.org/wiki/No_Silver_Bullet](https://en.wikipedia.org/wiki/No_Silver_Bullet)

</comment><comment><USER89> Agile works since 1947 at Toyota: [https://en.m.wikipedia.org/wiki/The_Toyota_Way](https://en.m.wikipedia.org/wiki/The_Toyota_Way)

</comment><comment><USER90> The root cause of the problem is that workplace is inherently undemocratic. While we live in democratic societies, we work in feudal organizations. Unless we fix that, nothing will change.

</comment><comment><USER91> *And while we're at it, we've got to stop treating dev teams like they work in a factory."

Beautiful

</comment><comment><USER92> Great rhetorically, not sure how comprehensible the logic was.

</comment><comment><USER93> _Pardon the interruption ..._

</comment><comment><USER94> "I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it . . . Scrum is a very simple framework within which the "game" of complex product development is played. Scrum exposes every inadequacy or dysfunction within an organization's product and system development practices. The intention of Scrum is to make them transparent so the organization can fix them. Unfortunately, many organizations change Scrum to accommodate the inadequacies or dysfunctions instead of solving them."

This was Ken Schwaber, co-creator of Scrum. _10_ years ago. Ten years after, things did not get a lot better for big corporations that were born with leaders used to waterfall.

I agree with almost everything in this article and I completely agree with what Tootie wrote above: "The fundamental problem that drives most agile failures isn't in the team's execution, it's in the business' expectations. One side is signed up for incremental delivery, and one side is set up for a fixed scope and deadline and the result is misery."

As the article rightly noticed being Agile is not just building faster. It is delivering "value faster". That also means: "do not build what does not need to be built" and every 2 weeks be willing to scratch what you have worked on. Instead in most of the big companies the business people present shiny objects to the leadership and their goals is to build those shiny objects. Nobody wants to say: "We were wrong". The result is a few projects were people worked for 1 year and then the project is abandon. Even if the idea was good, nobody wants to work on little improvements.

It seems that Agile, Scrum, and most of classic agile lingo have a bad connotation for most of the people in these days. Some (over) simplifications that were made to make Agile easier to adopt ended up making things worse.

People in big corporations are used to the "flavor of the month" Most of the people really do not look for a revolutions there. They are just looking to how they can seem smart to impress their bosses and being promoted. That how Scrum got in. And that is why it will never realize its full potential there. They do not want to change how they think and how they do things.

I run a pretty successful team inside a bigger organization. I wanted to use story points. Start from scratch and have the team get a sense for what 1 point is. And my boss really wanted us to use story points. He only had one requirement we had to use this equation 1 story point = 1/2 day of work...

Trying to explain him that one of the reason you use story points in the first place is to stay away from time did not go anywhere. All the other teams were using that equation and we could not be the only team that was not to using it.

Frankly speaking, I think it is hard to work at the "inter-team" level if you cannot use the same unit. That's why in Agile you want truly _autonomous_ teams. But big organization were not organized in that way. So you need to re- organize the company in a different way... but assuming there is the desire, who is going to drive that change? Who is going to take the risk of changing something that work in some way in a way that is not going to work too well for a few months?

In my humble opinion, it is almost impossible to change an existing a waterfall organization and make Agile work inside of it. Only a leader with a lot of trust by everybody in the company and a lot of courage may be able to make it work.

Most of the people that hate Scrum, Kanban or other flavor of Agile had experience with a "Cargo Cult" Agile preached in big companies and usually end up thinking that Agile is sooo screwed up. A big corporation will usually embrace embracing some things that usually really help (ex: standup meetings) and change a ton of other things that will make things worse.

You like the Agile mindset, you are going to be a lot more successful if you start from scratch with new young people or people that really want to commit to make things great.

For a new organization is easy to start with a simple "Agile template" and make sure that the team is really onboard with a continuous improvement mindset. Keeping regular retrospectives will make things evolve quickly in the right way.

</comment><comment><USER95> People get far more done if they spend less time labeling things and thinking there's a new canned technique that's better than what's been done before.</comment>