Why don't software development methodologies work? - <AUTHOR> http://typicalprogrammer.com/why-dont-software-development-methodologies-work/ <comment><USER2> It's fun to watch observations like the following re-discovered again and again. From the NATO Software Engineering Conference in 1968:

 _Ross: The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from._

 _Fraser: One of the problems that is central to the software production process is to identify the nature of progress and to find some way of measuring it. Only one thing seems to be clear just now. It is that program construction is not always a simple progression in which each act of assembly represents a distinct forward step and that the final product can be described simply as the sum of many sub-assemblies._

(Full transcript of the 1968 conference here. [http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PD...](http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF) It's a really fun read!)

<comment><USER3> Imagine you are a large company and there are 10 ideas for things you can build next, and you can't do them all. You gather the people that build such things and ask them, "how much will it cost to make each of these, and how long will it take". Do you think it is an acceptable answer if the builders reply, "I have no idea how much it will cost, I don't know how long it will take, and I don't know what you will have at the end of the process." How should a business handle this problem?

<comment><USER4> > Do you think it is an acceptable answer if the builders reply, "I have no > idea how much it will cost, I don't know how long it will take, and I don't > know what you will have at the end of the process."

If that's the actual answer, then anything else is just obfuscating the truth.

Why should we encourage lying to try to cover for the fundamental lack of knowledge? If you don't know, trying to make up numbers _never_ makes things better.

<comment><USER5> Making up numbers doesn't make things better for you or for delivery of the project. But it makes you liable to the boss, so they can make your head roll if they need to.

A surprising number of people in business think this way: not that they need to make sure of something, but just that they need someone to tell them everything will be OK, and then put the blame on if anyone is unhappy. That someone will naturally be whoever is at the bottom of the totem pole.

<comment><USER6> This remind me that business is pure gamble, and business people is bad gambler. They want to play but do not want to lose and if they lose they want to blame somebody.

Managing ego and heart is harder than managing a project i think.

<comment><USER7> _The Second Law of Consulting: No matter how it looks at first, it 's always a people problem._

Gerald Weinberg

[http://en.wikiquote.org/wiki/Gerald_Weinberg#The_secrets_of_...](http://en.wikiquote.org/wiki/Gerald_Weinberg#The_secrets_of_consulting.2C_1985)

[http://www.codinghorror.com/blog/2008/01/no-matter-what- they...](http://www.codinghorror.com/blog/2008/01/no-matter-what-they-tell- you-its-a-people-problem.html)

<comment><USER7> haha, I love this guy..

 _Asking for efficiency and adaptability in the same program is like asking for a beautiful and modest wife. Although beauty and modesty have been known to occur in the same woman, we 'll probably have to settle for one or the other. At least that's better than neither. _

<comment><USER8> No haha, this is just plain sexist and wrong. One of this wonky generalizations and why we don't have real software engineering yet.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> In my experience, these methodologies are best described as cultish. The form of religion but not the power.

Here's my methodology.

* Figure out what the software does, what the business cares about, and what the users care about.

* Figure out what it kinda sorta needs to be under the covers

* Write prototypes of the technically gnarly bits.

* Flesh out the prototype and start writing integration/functional tests for the system.

* Ensure CI server is live, running integration/functional/unit tests and build documents on push.

* Primary work phase: code review, write tests, write code as you go along. Figure out if features are needed or not. Don't overdesign or underdesign.

* Document subsystems as they stabilize using comments and in-repo text files.

* End of project: everything is tested, documented, and working.

Rinse, repeat.

<comment><USER10> Too pragmatic. Where are the meetings?!

<comment><USER9> Snarky, but frankly, there will be meetings very regularly with people who care & fund the project, as well as meetings within the engineering team to keep everyone abreast of what's going on.

The trick is not to have pointless meetings. Someone should get something out of the meeting besides warm fuzzies and new doodles.

<comment><USER10> > The trick is not to have pointless meetings. Someone should get something > out of the meeting besides warm fuzzies and new doodles.

Agreed. I should have been more specifically snarky.

</comment></comment></comment></comment><comment><USER11> IMO it's all about working with smart, motivated people who can work independently without the raging ego to cross borders to expand their computational Lebensraum. I've run remote projects with old friends over 3-5 years and it's gone spectacularly well.

In contrast, I've been on SCRUMed and Agiled projects where the resulting overhead on those who can already get work done without SCRUM Master Jar Jar's constant interruptions reduces them to people who quit within a few months.

But hey, acqui-hires rock and I can't imagine a better way to drive the talent out of a stable Fortune 500 company in order to take a chance at a startup than by driving them $%!@ing crazy and reducing their productivity to jack diddly. Ah the cycle of life...

That said, I see the use of methodologies where the talent is both junior and mediocre. But the former is better addressed with good mentoring (ha ha just joking - mentoring is for wimps, am I right? am I right?) and the latter by not hiring the mediocre in the first place (which means HR needs to be disrupted stat and since they hold all the cards they won't be - cycle of life again).

<comment><USER12> Assuming I won't be the only one: [http://en.wikipedia.org/wiki/Lebensraum](http://en.wikipedia.org/wiki/Lebensraum)

</comment></comment><comment><USER13> " _Surprisingly, left to themselves programmers don't revert to cowboy coding—they adopt or create methodologies stricter and more filled with ritual than anything I experienced in 1980. In fact programmers today can be much more rigid and religious about their methodologies than they imagine a 1970s-era COBOL shop was. I now routinely get involved with projects developed by one or two people burdened with so much process and 'best practices' that almost nothing of real value is produced._"

Sing it, brother! Can I get an "Amen"?

I know of one project with a technical lead who, to my knowledge, has never done anything _other_ than support the vendor program the project is replacing; the team has developed a process built primarily around avoiding Subversion merges (which is not necessarily a bad thing given that they seem to actively resist learning anything about how to use Subversion) and secondarily around adopting anything anyone has ever described as a "best practice", including inventing a few new ones. So far, I do not know of anything their project actually does, although there is a great deal of it.

Oh, and their scrum meetings seem to involve the scrum master reading a fair amount of text from PowerPoint slides (which have far too much text on them).

[Edit] Apparently, I can. [http://typicalprogrammer.com/why-dont-software- development-m...](http://typicalprogrammer.com/why-dont-software-development- methodologies-work/#comment-4460)

<comment><USER14> I like the Kafkaesque idea of inventing new best practices specifically so you can avoid using them.

</comment></comment><comment><USER15> Because it tries to fix human problems logically. Humans are not very logically creatures. We love to think we are, but most of us are very emotionally driven. Our emotion comes into play when it comes to drive, motivation, hard work, creativity, and organization. Creating software requires motivation, creativity, organization, etc. Our emotion is behind software and we simply try to manage it with software development methodologies, but that's not enough.

How many people are over weight, who know that all you have to do is eat less, work out and then you will get in shape? It's that simple. Yet because of emotions, eating due to emotion, happy eating, sad eating, or poor self image many people don't get in shape. Likewise many students understand that all you have to do to get great grades is to avoid procrastinating, just start studying on time, study hard, study more, do most of the exercises in your text book, use multiple books and you are most likely to pass with high grades, yet lots of students put it off, poor will power, delayed gratification, it's more fun to goof off.

Same things apply to software, a lot of us know exactly what it takes to make good software, to spec it out, to plan a good architecture, to write good test units, to comment and document the code, to organize the process, to avoid over optimization, to avoid changing and adding lots of new features in the middle.

Yet, a lot of us don't do that, we start writing code before we even code before we spec out, because its exciting! Our emotions in play, we don't practice that delayed gratification of holding off and writing specs. We plan to throw away this prototype, but then somehow, it ends up being what everything is built on. We plan to refactor one day, but feature creep never allows for that. We know we ought to comment, but we understand the code now and don't, then 6 months later we are cussing and kicking the wall. Test units are boring, so we write as little of it as possible.

Until we take into account that programmers are humans, with emotions and different level of discipline, motivations and abilities our software development methodologies will keep to fail us for most projects.

Just my opinion.

<comment><USER16> _Because it tries to fix human problems logically. Humans are not very logically creatures. We love to think we are, but most of us are very emotionally driven._

But there is nothing stopping you from incorporating emotion into your logical models.

<comment><USER13> _Temporal and modal logic_ , E. Allen Emerson: [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.92.5...](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.92.5289)

(I've been told that I have been using "yeah, good luck with that" too frequently lately, so I'm trying to branch out into different phrasing.)

</comment></comment></comment><comment><USER17> In my own anecdotal experience I would say the team matters way more than the methodology. I've been on teams that could have been (and were) repeatedly successful on projects that ranged widely from strict agile to strict waterfall. Every single time that team pumped out good quality software reasonably on time.

I've also been on teams that were not successful no matter what methodology they used. The team just wasn't cohesive, didn't have enough talent, and/or had poor leadership.

<comment><USER18> One of the best features of good teams is that they are able to throw away unecessary rituals of their choosen methodologies.

<comment><USER17> I've never been on a team that didn't have some manner of unnecessary ritual put on them by the management or client. I agree with your comment, and I would additionally add that a good team can go with the flow and work well within the context of most silly rituals.

</comment></comment></comment><comment><USER19> A couple of observations. First, we tend to push to maximize potential output. That means demanding more than could actually ever be done. I've come to the conclusion that if you're writing code that meets all requirements, on time and under budget, you're simply not ambitious enough. Pristine, perfect code is a sign of customer laziness.

The software we create today is tremendously more complex than the software we created back when I started in the 1990s. Part of that is standing on the shoulders of giants (and the libraries of giants), but part of that is also process.

The amount of process required for clear, effective communication increases with the number of parties involved. Creating good interfaces between components and the teams responsible for them is really a very difficult problem. If you're working on a three person team, it's easy. If there are 30, it's much harder. If it's 100, you probably can't even know every single person involved, much less avoid stepping on each other, not without a lot of process.

So what process does is increase the potential scope of a problem above what a small team can do (mostly by breaking it down into several interacting subprojects). That's difficult, important work, even if it's outside the realm of the average HN startup's imaginations and experience.

</comment><comment><USER20> An important realization I made a while back was that design methodologies do little to address program correctness, which is almost always the wildcard on deliverables; buggy software means missed deadlines and budget. Some, such as TDD, work to address the rapid building of tools to a particular spec, but often fail to promote static guarantees, especially in languages and environments where such provability is largely impossible. Dynamic languages penchant for monkey (guerrilla) patching further exacerbates the problem.

Solutions to this are tough. My first suggestion would be to use languages which facilitate correctness, although it's usually at the expense of developer availability: the pool of engineers with experience and know-how in true FP is orders of magnitude smaller than more pervasive languages. My second thought is to further embrace math as the building block for non- trivial applications: mathematical proofs have real, quantifiable value in correctness. I find it no surprise that the larger companies have made foundational maths, such as category theory and abstract algebra, the underlying abstraction for their general frameworks. This is even a tougher pitch than the first since most engineers don't recognize what they're doing as math at all - a big part of the problem. So many of us are doing by feel what has already been formally codified in other disciplines.

I'm aware that both require more (not necessarily formal) education than most engineers have pursued and makes it a difficult short-term pitch point for any company, but I think if we're serious about eliminating sources non- determinism from projects, it's important we address them directly.

<comment><USER13> " _I find it no surprise that the larger companies have made foundational maths, such as category theory and abstract algebra, the underlying abstraction for their general frameworks._ "

I would like to learn more; do you have a specific example?

Having worked with real "engineer" engineers, I've found that they have, and value, a considerable amount of mathematical education, but that education is all in continuous mathematics; abstract algebra and formal logic have about the same amount of respect as basket weaving. Unfortunately, continuous math isn't particularly useful for software.

<comment><USER21> As an electrical engineer who briefly flirted with computer engineering, I had 4 semesters of continuous math and 1 semester of discrete math[1]. I also had classes like linear systems and electromagnetics where I had to actually use continuous math heavily.

While I do not think continuous math is particularly useful for general software development, I think it is very valuable for specific problem domains. I have found my Calculus/DiffEq foundation to be very valuable for my work with radar signal processing and NLP code, more so in the former because it was basically translating electrical engineering algorithms, formulas, and concepts into C. It is also important for any type of development that makes heavy use of geometry.

As a side note, I saw some of the bias you describe out of the more "pure" EEs I worked with when I first started. There was a strong bias against software engineers, particularly those who went the CS route, because they didn't understand the math and physics behind the hardware. Admittedly, some were clueless and probably should not have been writing software for multi-million dollar hardware[2]. Most were competent, though, and able to pick up the basics they needed to know when tutored for a bit.

[1] Which was actually titled "Discrete Mathematics", and was just covered basic set theory, combinatorics, and linear algebra. [2] Like the one who added a reset routine that blindly opened power contacts on the UUT without verifying that the power supplies were off first. Fortunately, that was caught before they actually opened with hundreds of amps going through the bus.

<comment><USER13> As you say, continuous math (to my mind, calculus, diffeq, and linear algebra; anything involving reals) is necessary for some problem domains. But accounting is necessary for some problem domains as well. And molecular biology.[1]

But if I get worked up into a good froth, I can make a case that software development _is_ applied formal logic or applied abstract algebra (or both). I don't believe you can do professional software development (in Weinberg's sense) without some serious discrete math, in the same way you can't do signal processing without calculus.

[1] If you've got something that mixes the three, let me know. It's probably something I should stay away from.

<comment><USER21> I must admit to ignorance of Weinberg's books and other writings. My interest is piqued now, though.

That said, based on your second statement nearly all scientific and engineering programming would not qualify as "professional software development". The code I worked on had little to no discrete math or formal logic in it. There was not an integer to be found save loop counters and array indices Do you not consider an (electrical engineer | mechanical engineer | physicist | molecular biologist) who can code and spends the vast majority of their time writing production code like this a professional software developer?

</comment></comment></comment></comment></comment><comment><USER22> Just twisting an old joke: Good software development methodology is like a UFO - everybody has heard of it, nobody has seen it.

Restricting a creative process into some pre-baked confines of thinking doesn't make a sense to me. Some rules are vital thought those should not get too much in the way.

I think only organically growing your rules makes sense and you've got to accept there will be situations where you have to break them or they won't allow you to adjust your strategy. Imagine a huge company that standardized on some well-tested processes/methodologies that served well in the past and were adjusted as it was growing. Staying with the same set of methodologies might kill the company's future if the structure of its workforce changes, technology moves forward, competitor has more efficient methodology for achieving returns etc. Often methodologies are used internally for political gains, pursuing promotions and power and "change agents" don't really care that much about improving efficiency, instead riding the wave of a currently cool methodology as recognized by the upper management.

<comment><USER23> A software methodology can be thought of as a cattle herding dog. The dog's sole purpose is to get the herd from point A to point B generally at the same time and in one piece. The methodology doesn't really matter, the results do. Leadership/management gets to pick the dog though and this is where people complain.... Everyone wants their own dog.

</comment></comment><comment><USER24> _" Maybe social skills come harder to programmers than to other people (I'm not convinced that's true), but developing those skills will certainly pay off a lot more than trying yet another development methodology."_

Like almost any other skill, "Social Skills" are developed through practice, and they also degrade when they aren't used. People that spend a majority of their time on a computer may struggle when communicating face-to-face. (I've also seen it happen with stay-at-home parents with young children.)

</comment><comment><USER25> Like the author mentions, he subscribes to the "no silver bullet" thought. Methodologies doesn't ensure project success because it's insignificant compared to the individuals involved and the scope of the product. The focus on process, is because process is easy to implement and change, giving the illusion of control.

What good project managers do is much harder than implementing a Scrum method. It's finding good people, making the hard decisions of removing the bad people and get / make a clear understanding of product scope and goals.

The last point in particular should be a well duh, but in reality it's ridiculously common to encounter projects where the PM (and hence even the customer), have a very vague understanding of what's actually being built. Those projects are guaranteed to go massively over time and budget, or being outright cancelled.

Good process is just the icing on the cake. It should be used, process alone does not make a project success.

</comment><comment><USER26> In a nutshell: because by the time software companies start to look for some methodology silver bullet they are already hip-deep in trouble and no amount of 'process' will fix multiple years of bad hiring decisions, bad engineering and unrealistic expectations.

<comment><USER27> Our process is untenable! What additional process can save us from the process quagmire? Quick, implement it.

</comment></comment><comment><USER28> I have a buddy who went through six-sigma and Toyota Production System training in his work as a Process Engineer in a large manufacturing company. When we talked about the application of methodology to an organization, he made a keen observation on human nature: "people don't like to be told what to do." To me, this goes a long way toward explaining why "conceptual integrity" matters more than a methodology, and why it is difficult to apply a methodology to a new team or company unless they discover it for themselves organically.

</comment><comment><USER29> "Everyone has a plan until they get punched in the face."

\--Mike Tyson

</comment><comment><USER30> They work, but you still need very capable people (developers, managers, product owners, etc).

Furthermore, if you have a very capable team, you may not even need a formal "Methodology".

<comment><USER19> Depends on the size of the team. If you have a 5 or even 10 person team, then maybe. If you have 100? You need methodology.

Once you break a project down into subcomponents that interact, you need to coordinate release of any changes to interfaces, so the work of one team doesn't break the work of another.

<comment><USER30> I still think it is the capability of the people what makes the difference.

I actually have had the experience of leading a team of 50 developers in a 120 people project. We all were the new on the project and didn't know each other, I basically picked the most qualified 7 developers and formed teams. We broke the project into modules and look for smart ways to work and not stepping over each other.

</comment></comment></comment><comment><USER31> this one of the many examples of the anti-intellectualism that is so pervasive in the software development scene. Are the inflexible, detail-prescripting methodologies he describes any good? of course not, but I haven't seen a single seriously used methodology be like that in real life unless it fell on the hands of negligent/incompetent management and/or engineers.

<comment><USER32> >anti-intellectualism that is so pervasive in the software development scene

Errrr....

<comment><USER33> How else do you characterize an industry that seems content to re-learn lessons of the past over and over?

<comment><USER34> It seems like almost all professions have a body of knowledge. Software Engineering doesn't.

Imagine getting open heart surgery, your chest is open, and doctors start arguing over the best methodology to do it.

<comment><USER35> It does, and it has for quite some time: [http://www.computer.org/portal/web/swebok](http://www.computer.org/portal/web/swebok)

<comment><USER18> OMG. I just hope you are being sarcastic.

That's everything we are complaining about right there on the index.

<comment><USER35> No sarcasm intended. You don't have to agree with SEI or IEEE, but the complaint was that there wasn't an organized body of knowledge. My response was to show that there is.

I'd be interested in knowing what you find so objectionable about SWEBOK.

</comment></comment></comment></comment></comment></comment></comment><comment><USER36> The problem here is that he defines "works" as "Deliver a predictable or repeatable software development process in and of themselves."

And that's crazy. Software delivery is at least 50% design/problem solving - and those aer neither completely predictable or repeatable.

To me a software methodology works if it _improves_ delivery. If the result with the methodology is more predictable, and less likely to go horribly off the rails than if you'd used a different methodology (or none at all) then it's a good methodology.

Looking for something that can perfectly transform any human requirement into code, in a predictable manner, is just silly.

<comment><AUTHOR> Software DEVELOPMENT is a lot of design and problem solving. It also usually involves changing requirements and discovering limitations of the tools. I agree that there's a lot of uncertainty in the development process.

Software DELIVERY is what management, customers, and users care about. If a software system does not meet requirements, or if it's so late or over budget that it's a net loss to the customer, it matters little how well-designed it is or what problems were solved.

By predictable and repeatable I mean the entire process. Obviously not every aspect of of the development process can be predicted, nor are projects enough alike to be produced by an assembly line. What management and customers want is a reliable prediction that the system will meet requirements and be finished on schedule and within budget. And they want to believe that a process that can deliver a system this year can do it again.

An architect can reliably predict that a house or an office tower can be made from their plans. A chip designer can predict that a working CPU can be designed and built. An automobile designer can predict that a working car can be made. And these processes are repeatable. Any designer/builder will encounter problems to solve and changing requirements. Failures occur in these realms, too, but not nearly as often as with software projects.

I've heard the argument that software development is different: it's a creative process, the people are idiosyncratic, the problems are unpredictable. I think big-budget movies face the same challenges, but even in that domain there are predictable and repeatable processes that are reasonably good at delivering.

I agree that "Looking for something that can perfectly transform any human requirement into code, in a predictable manner, is just silly." I didn't write anything like that, nor is that what I think anyone means by software development methodologies.

<comment><USER36> "An architect can reliably predict that a house or an office tower can be made from their plans."

Yes, but that's because the plans are nailed down and fixed - the creative design part is _done_.

"A chip designer can predict that a working CPU can be designed and built. An automobile designer can predict that a working car can be made."

Neither of these are true until _after_ the designs are finished. Intel has gone massively over-budget on chip designs before, and automobile designs have been abandoned after spending a fortune trying to get them right.

<comment><AUTHOR> I think I'm not making my argument clear. Software development methodologies are PROMOTED as ways to improve the predictability and repeatability of software development. They are adopted because management (or customers) are scared by the usual chaos of software development.

I think I clearly communicated my opinion that no development methodology in and of itself guarantees predictability or repeatability. They fail to meet the expectations of management; in other words they don't work.

I also think I clearly expressed my surprise that even without management pressure programmers will adopt methodologies and then force themselves to follow the rituals. Maybe this happens because programmers don't know better. I think it has more to do with creating a firewall of process and so-called best practices to avoid oversight and criticism. Sometimes there's an element of showing off -- look at how Agile/OOP/TDD/whatever I am, and no one told me to do it!

</comment></comment></comment></comment><comment><USER37> Because Software is inherently complex, one of the most complex things that Humans can try and make. And whenever we successfully make something easier, we push the borders out so that Software is always stretching to the limits of the complexity we can handle. Ultimately, its just hard. Sometimes methodologies help, but there is No Silver Bullet.

</comment><comment><USER38> "I know the feeling working on a team where everyone clicks and things just get done. What I don't understand is why I had that feeling a lot more in the bad old days of BDUF and business analysts than I do now."

I suspect it's the author that has changed, not everyone else. It's probably a combination of a nostalgic bias combined with the author's increasing age making it harder to get on with a typical team of young whippersnappers.

I say this as someone who is over forty and regularly falling into the "things were better in my day" trap (although hopefully self-aware enough to see it).

<comment><USER39> I'm strongly against what he wants to revert back to, but I think he has a point. Many engineers are completely lacking in leadership and strategic capability, and fall prey to a cargo-cult, new-must-be-better, buzzword- chasing careerism no different from what we accuse managers of.

He's probably seen a few teams ruined by young megalomaniacs who want to put terms like Scrum and Kanban all over their resumes because they (being Clueless, in the MacLeod / Gervais sense of the word) think it's the ticket to the brass ring.

<comment><USER40> I agree, unfortunately (or fortunately), having stuff like that on your resume can translate to more dollars and happier wife; happier life. As I get older I wonder if Social Security will be there. In my lifetime pensions have gone away so it wouldn't surprise me to see SS go away. So I'd say load 'er up! Get all the terms and buzzwords you can on there.

</comment></comment></comment><comment><USER41> So what this article is really saying (although reluctantly it seems) is that methodologies really do work, it's just not that they're the end-all and be- all. You need to have common vision and communication that works around the team's goals and personalities. Seems to be pretty common sense to me.

</comment><comment><USER42> I absolutely agree that no software development methodology is guaranteed to work. However, there are certain things that one can do to reduce the chances of embarrassing development stalls, such as proper documentation, continuous unit testing, talking to the end user, and team communication.

</comment><comment><USER43> _Try this thought experiment: Imagine two teams of programmers, working with identical requirements, schedules, and budgets, in the same environment, with the same language and development tools. One team uses waterfall /BDUF, the other uses agile techniques._

Problem is that with agile (as I understand and mildly practice it at least) you can't have "identical requirements", because you don't have full, complete and detailed requirements upfront.

<comment><USER44> I think there's a difference between having an initial set of requirements, and believing that those requirements are _the_ requirements forever and ever, amen. Waterfall relies on the latter, while Agile assumes that they can and will change.

Both projects will be given the set of initial requirements. After all, if you don't have requirements, what the hell are you even doing? It's what happens when those requirements change that's the fun part.

</comment></comment><comment><USER45> There are a lot of issues layered in here, a bunch of complexity that might not be obvious just by scanning the article.

Does a good team deliver solid, quality code? What if it's code the user doesn't want? Conversely, what if the team excels at delivering what the user wants, and they love it, but the code is so buggy that it only works 50% of the time? Would that be better than a solid app the user hates? (Probably yes)

Should a team working inside a large company deliver faster than the organization is able to accept change?

Just what is a good project, anyway? One in which we all had a good time and thought we did a great job? Or one in which the person paying us thought we were awesome?

No matter the criteria, everybody seems to agree that having good people is something like 70-80% of the secret. The big debate is what goes into that other 20-30%

ADD: An interesting thought experiment to play here is to posit that the team sucks -- wrong guys, wrong personalities, whatever. In that case, what would you want to happen? The answer to that should be an important part of whatever you want your process to be. Explicitly define your failure mode. (Because failure is still more often the norm than success in software development)

</comment><comment><USER46> > rigorous studies of software development methodologies haven't been done

A simple search proves this is false. Paired with author's other unsupported and stupendous claims I have to doubt the validity and worth of anything else author says.

<comment><USER47> Could you please link to some of these studies that adequately control for the constituent programmer ability & personalities?

<comment><USER48> Let me recommend you "Lean Software Strategies" book. It refers to many software development experiments and observations, some of them from Lockheed Martin. While the book does not claim to present the ultimate methodology, it draws on progress in other engineering disciplines to create a better, continuously improving process.

[http://www.amazon.com/Lean-Software-Strategies-Techniques- De...](http://www.amazon.com/Lean-Software-Strategies-Techniques- Developers/dp/1563273055/ref=sr_1_1?s=books&ie=UTF8&qid=1392065099&sr=1-1&keywords=lean+software+strategies)

</comment></comment></comment><comment><USER49> I'm a fan of repeatability and process. Here's my take on why they don't work:

1) You can't get around that things don't work as planned, and too many methodologies assume that things will.

2) It is better to have a PM with A level content and B level process, than the other way around. Professional PMs don't have the intuition to solve the daily project problems, but they're the ones selling the methodologies.

3) Too much focus on tools. Using MS Project to keep the plan doesn't work when 90% of the project doesn't know how to use it.

4) Too much change. Rather than settling on a decent methodology that everyone agrees to, companies keep re-inventing their process every few years.

5) Wrong methodology for the wrong purpose. Waterfall methodologies don't work in research. Agile methodologies aren't the "fits every project" panacea.

I can go on, but you can't enforce excellence with formality. The formality can help outstanding people achieve excellence though.

<comment><USER50> #1 and #3 sound like they're right out of [http://agilemanifesto.org/](http://agilemanifesto.org/)

<comment><USER49> Typed from memory w/out referencing it. (I'm not agile certified, or anything to that effect)

</comment></comment></comment><comment><USER51> From my personal experience, the article nails it

"It's common now for me to get involved in a project that seems to have no adult supervision". But my bigger problem is that the youth of today seem to have a much bigger ego than the youth of yesterday.

"Once a programming team has adopted a methodology it's almost inevitable that a few members of the team, or maybe just one bully, will demand strict adherence and turn it into a religion". Recently working with an off shore team, they called their tech lead literally "God". And he was pontificating procedures and styles left and right without understanding the core of the software first. He stopped when the product start to have big performances problems. One of the ones that I liked the most was his prohibition to use class indexers in C#, backed up by an example in Java.

</comment><comment><USER52> This is a fantastic post and I agree with it fully.

I get why process exists, I know management sees it as a way to make software development less lumpy; to bring below average teams up to average productivity, but it isn't a one way lift. Extensive process might raise the below average toward the average, but it can also lower the above average toward the average.

Twice I've seen situations where a team of better than average developers had no really well-defined process (though not surprisingly a sort of home grown process evolved to suit everyone's needs -- agile, as opposed to Agile, if you will) that was highly productive suddenly have process dropped on them from on-high in an undeniably productivity-killing way.

One time it was because higher-ups at the company randomly decided they needed to standardize on the Rational tools (ClearCase, Rose, etc... still have nightmares about that stuff) and out of that insane decision we ended up with some stupidly strictly defined RUP-based process to tie everything together.

The other was when a team was transitioned from one company to another and the other was one of those stupidly-strict "Agile" shops that fully drank the ritual kool-aid and adopted basically every suggested "Agile" strategy they could slap together without giving much thought to the actual original ideals of why "Agile" came about.

I guess the takeaway is be really selective about introducing new process. It might entirely make sense if your project is building some mostly throwaway CRUD app for an internal company department and all of your developers are, well, the kind of developers you can find who will work on such things and the project is off-track. Or even if your developers are all good, but the project is failing for other reasons like lack of cohesive vision. A little bit of process introduced sparingly might help.

But if you have a highly productive team already, don't fool yourself into thinking that because process "improves" software development that adding more of it will make your highly productive team even more productive. Because it very likely will do the opposite.

<comment><USER14> _Extensive process might raise the below average toward the average, but it can also lower the above average toward the average_

The way that I see it is that at best, rigid processes can set set both a ceiling and a floor. It's sort of like going to (a real) Starbucks. 99 times out of a hundred it's not going to be terrible, nor is it going to be great. It's going to be just OK.

If you're the kind of organization that looks at software as a necessary evil instead of a strategic advantage, "just OK" is an appealing thing to strive for.

</comment></comment><comment><USER53> > Individuals and interactions over processes and tools

<comment><USER54> A short comment but the one I was looking for in this thread. People often forget the "People over Process" part of agile which implies no Methodology is going to be the answer. All you can hope for is to create the correct process (methodology) for the people you have at the time.

Trying to fit the people to the process is why software methodologies fail.

</comment></comment><comment><USER55> This would rather much be like a carpentry shop owner lamenting "why don't either electric circular saws OR handsaws work to make my mediocre workforce produce beautiful furniture without all of this wasted wood?"

First of all, creating beautiful furniture takes LOTS of time, as it rests in attention to detail and an uncompromising position towards quality. When you're uncompromising about quality, you require yourself to throw out, to waste, things that are of lesser quality.

Second of all, beginner, poorly trained, and dispassionate employees are never going to produce beautiful furniture. Mostly because of the above: they either lack the ability or the caring to have the attention to detail necessary to do great work.

And the best carpenters aren't going to come work for _you_ unless you're willing to make it worth their time. Coming to work for _you_ means they will have to do a lot more work in a much less comfortable environment than they are used to. Because the best carpenters have their own shop, their own tools, and work on their own time, because they love it. Going anywhere that is not their own setup is automatically worse for them.

It's the same thing in software: great software takes patience, it takes time, and it takes money to convince the best programmers that they should be spending their time on you rather than on themselves.

But at no point does any of that mean that, because Tool X can't magically turn your mediocre working into a stellar one, that means that Tool X is not worth studying. That is completely, 100% backwards. The master practitioner studies _all tools_ , even the ones he or she doesn't like, at the very least to understand what is wrong with them and why they don't produce the results they want. A master carpenter might prefer a hand saw over an electric one because the electric saw chips the corners of the board too easily, or something. But he doesn't know that unless he's studied the electric saw.

You can't have "an absence of methodology" any more than a wood shop can have "an absence of tools". It has to be there. But they all have their pros and cons, and non of them has a pro that includes "makes men out of mice."

<comment><USER5> Nice analogy. Waste is normal in manufacturing. Cost-effective manufacturing doesn't necessarily mean that no wood is wasted. If you are focusing completely on wasted wood you might lose track of overall profitability or quality. (Or, you know, people not wanting to leave your shop ASAP)

</comment></comment><comment><USER56> Methodologies and process aren't created to be silver bullets. It's our human nature to try and turn things into silver bullets, I would guess this is mostly due to our laziness to try and create better process on our own. Methodologies are created to solve the problem that not every team will be a star studded team with excellent communication and cohesiveness. Methodologies address the very real problem of less than perfect teams that still have goals to reach. It's about elevating the below average to the average.

</comment><comment><USER57> I guess to answer that question, you first have to define what a working methodology is supposed to accomplish.

How do you know something is developed in a timely fashion, for example? All we really have is a gut feeling.

We could implement the same project multiple times and use a different methodology each time. Then compare. But you'd want to use people who understand the methodology and care about winning the competition.

Even then, I bet if you ran that experiment with 5 different projects, there'd probably be a different outcome every time.

</comment><comment><USER58> I actually found that rapid-prototyping works best for me and I was able to deliver fairly good results using it. In fact I am starting a consultancy in month or two that will use rapid prototyping and other best practices I observed as effective.

My goal is to provide environment where clients would feel their input is steering project and they are getting results they want, also that developers and others working on a project would like clear direction and ability to show their best skills. Sounds a lot, I know.

<comment><USER34> > rapid-prototyping works best for me

> provide environment where clients would feel their input is steering project

> others working on a project would like clear direction

What tools would you/do you use?

<comment><USER58> There are lot of different tools, alternatives you could use, here are preferred ones by me:

MiddleMan as a static site generator, I also use Foundation by default or can use Bootstrap if someone prefers it. Slim templating engine as it is very easy to read.

ConceptBoard or InvisionApp are good for iterating over feedback.

Trello or any other of similar tools can help you allow visibility what is happening.

It is very important to do things at the right time. First develop wire that would capture requirements, original idea. Then design interface based on wires, and model data (very important step). This is when you can start writing tests, not before. Then coding rest of the interface.

BTW, this also works for developing API and works really well.

</comment></comment></comment><comment><USER59> Well, his post is a bit inflammatory at first, but I sort of agree that processes sometimes get in the way, even the almighty Agile (big A) that some people like to subscribe to.

Ultimately, it's more about the people involved. Bad teams are going to find a way to screw themselves over no matter what process they use. Good teams don't need a rigid process since they'll just find a way to get stuff done no matter what.

</comment><comment><USER60> [http://en.wikipedia.org/wiki/The_Mythical_Man- Month](http://en.wikipedia.org/wiki/The_Mythical_Man-Month)

[http://www.joelonsoftware.com/articles/fog0000000069.html](http://www.joelonsoftware.com/articles/fog0000000069.html)

I've been a web developer for 13 years. Following a specific methodology doesn't matter, as much as focusing on the important aspects of the project, which are the customers, and what difficult problem the product solves.

The funny thing is that even if a team does this, it is not guarantee of success. If the customer base is too small, or there are lots of competitors, even the best software will fail. Conversely, if the customer base is massive, and there are few competitors, even poor quality software can succeed. Luckily for the software industry, and not for consumers, most teams do not follow these guidelines with the net effect being a TON of poor quality software.

Obviously here, Stackoverflow, and various other programmer focused sites, it's common to focus only on the coding side of the equation. The reality is that the best software comes from the collaboration between customers, designers, programmers, testers, usability experts, and sales. When each group brings their strengths to the table and focus on a common goal and solution, everyone wins. However it's very rare, since often the programmers are seen as the builders, the designers as the painters, testers as a nice to have, usability as a fad, and sales as being helpless.

To clarify a bit: design != usability, functional != usable. A beautiful design does not mean usable, look at the very confusing swipe action based calculators on iPhone. Functional is an auditorium with 20+ projects, usable is having the specific video cable dongle.

</comment><comment><USER61> Maybe they all don't "work" because people suck and get lazy? Things can be very pleasing when one works with developers use the planning tools and have a leader who never relents at keeping the team on track with a given methodology, all without being a bully of course. Of course it's rare in the real world, but it does happen.

<comment><USER42> I left my last job because my time had degenerated from doing cool stuff to fixing the stupid errors that my colleagues were making because they were lazy. Allowing some coders to be lazy in terms of adherence to coding standards and methodology has to be one of the best ways to get rid of your good programmers.

For example, we had coding standards requiring a comment explaining the contract for each method written, and this was enforced by version control on check-in. My colleagues were putting in comments like this:

      /**
       * Comment
       *
       * @param foo Parameter
       * @param bar Another parameter
       * @returns Something
       */

to avoid triggering the automated coding standards check, without actually revealing anything about the method they had written. I complained to the manager a few times, who did nothing, so I left.

<comment><USER62> That sort of thing has an obvious problem. Take a fairly simple class:

      class Shape
      {
      public:
        void SetAbsolutePosition(uint x, uint y, LengthUnit units = LengthUnit::PIXELS);
        void SetRelativePosition(int x, int y, LengthUnit units = LengthUnit::PIXELS);
        void SetXAbsolutePosition(uint x, LengthUnit units = LengthUnit::PIXELS);
        void SetYAbsolutePosition(uint y, LengthUnit units = LengthUnit::PIXELS);
        void SetXRelativePosition(int x, LengthUnit units = LengthUnit::PIXELS);
        void SetYRelativePosition(int y, LengthUnit units = LengthUnit::PIXELS);
        void SetSize(uint height, uint width, LengthUnit units = LengthUnit::PIXELS);
        void SetHeight(uint height, LengthUnit units = LengthUnit::PIXELS);
        void SetWidth(uint width, LengthUnit units = LengthUnit::PIXELS);
        void SetColor(Color color);
      };

What the methods do is bleeding obvious and the whole thing fits on a single screen where you can look at it. Now let's put all those comments in, what are they going to look like typically when inserting them is mandatory?

      class Shape
      {
      public:
      /**
         * SetAbsolutePosition sets the Shape absolute position
         *
         * @param x The absolute X coordinate
         * @param y The absolute Y coordinate
         * @param units The units of the coordinates
         * @returns Void
         */
        void SetAbsolutePosition(uint x, uint y, LengthUnit units = LengthUnit::PIXELS);
      /**
         * SetRelativePosition sets the Shape relative position
         *
         * @param x The relative X coordinate
         * @param y The relative Y coordinate
         * @param units The units of the coordinates
         * @returns Void
         */
        void SetRelativePosition(int x, int y, LengthUnit units = LengthUnit::PIXELS);
      /**
         * SetAbsoluteXPosition sets the Shape absolute X position
         *
         * @param x The X coordinate
         * @param units The units of the coordinate
         * @returns Void
         */
        void SetXAbsolutePosition(uint x, LengthUnit units = LengthUnit::PIXELS);
      /**
         * SetAbsoluteYPosition sets the Shape absolute Y position
         *
         * @param y The Y coordinate
         * @param units The units of the coordinate
         * @returns Void
         */
        void SetYAbsolutePosition(uint y, LengthUnit units = LengthUnit::PIXELS);
      /**
         * SetXRelativePosition sets the Shape relative X position
         *
         * @param x The relative X coordinate
         * @param units The units of the coordinate
         * @returns Void
         */
        void SetXRelativePosition(int x, LengthUnit units = LengthUnit::PIXELS);
      /**
         * SetYRelativePosition sets the Shape relative Y position
         *
         * @param x The relative Y coordinate
         * @param units The units of the coordinate
         * @returns Void
         */
        void SetYRelativePosition(int y, LengthUnit units = LengthUnit::PIXELS);
      /**
         * SetSize sets the width and height of the Shape
         *
         * @param height The length of the height
         * @param width The length of the width
         * @param units The units of the lengths
         * @returns Void
         */
        void SetSize(uint height, uint width, LengthUnit units = LengthUnit::PIXELS);
      /**
         * SetHeight sets the height of the Shape
         *
         * @param height The length of the height
         * @param units The units of the length
         * @returns Void
         */
        void SetHeight(uint height, LengthUnit units = LengthUnit::PIXELS);
      /**
         * SetWidth sets the width of the Shape
         *
         * @param width The length of the width
         * @param units The units of the length
         * @returns Void
         */
        void SetWidth(uint width, LengthUnit units = LengthUnit::PIXELS);
      /**
         * SetColor sets the color of the Shape
         *
         * @param color The color to be set
         * @returns Void
         */
        void SetColor(Color color);
      };

So now the class is eight times as long and you have to scroll eight times as much to find anything, in exchange for which you get a bunch of comments that tell you things you already know. Meanwhile writing those comments involved a lot of copy and paste and then changing one or two variable names and descriptions, which violates DRY and is the recipe for erroneous comments.

The better alternative is to comment only those things where the comment provides useful information, so that when you see a comment it strikes you as something you should pay attention to rather than some boilerplate to be ignored because 85% of them are mandatory but useless.

<comment><USER42> While I understand the argument behind not commenting getters and setters, and it is quite valid, no it is not obvious what each of those methods do. For instance, what is the relative position relative to? Is the colour for the outline of the shape or the fill? Why do you have a width and height for a shape - does that mean it is a rectangle?

But of course I meant my earlier comment particularly for quite complex methods that had very ambiguous behaviour unless defined in a comment that could act as a contract. The contract can then be enforced by writing tests against it, and you know your code works when the tests pass.

It's very common to write the code first, write the tests against the code, and then write a comment against the code if you are lucky, but that doesn't actually prove anything, as the tests will be testing the implementation details, not the contract.

<comment><USER62> > But of course I meant my earlier comment particularly for quite complex > methods that had very ambiguous behaviour unless defined in a comment that > could act as a contract.

Which is kind of the point. You _do_ need some kind of documentation for nontrivial methods. But requiring boilerplate documentation for everything encourages the opposite of that because it becomes "fill in the fields" rather than "say something useful." I mean let's say you're right and SetRelativePosition isn't clear about what it's relative to. Which of these is better?

      /**
         * SetRelativePosition sets the Shape relative position
         *
         * @param x The relative X coordinate
         * @param y The relative Y coordinate
         * @param units The units of the coordinates
         * @returns Void
         */
        void SetRelativePosition(int x, int y, LengthUnit units = LengthUnit::PIXELS);

-or-

        /* SetRelativePosition: sets position relative to current position */
        void SetRelativePosition(int x, int y, LengthUnit units = LengthUnit::PIXELS);

</comment></comment></comment></comment></comment><comment><USER63> I like this article, and I get it. In my personal experiences, I have found that scrum is successful when it is used to reinforce a single coherent vision and to build a tight integrated team.

It does not work when it's used as a magic machine of happy fun time productivity…. Sprints and stories don't translate into more productivity. Focus and teamwork do.

</comment><comment><USER64> The real world and its constraints have this terrible tendency to intrude on the idyllic visions imagined around software development methodologies. Budget cuts, people quitting, timelines changing every week, internal politics, sabotage, personality issues - basically everything but the "methodology" itself.

The advice often comes (including in one of the XP books) that the answer to "bad projects/people/environments that you can't change" is to get a new job; this may work at the individual level (sometimes), but it does nothing to actually fix the broken projects, environments, or people themselves.

There is indeed no silver bullet. All these decades later, and many people still refuse to accept that.

</comment><comment><USER65> This made me think about the book "Shop class as soul craft". Cars use to be made by hand by skilled artisans. So did software.

As with any process of production the move to change it in to a documented repeatable process complete with middle management has taken place.

<comment><USER13> On the other hand, cars are _still_ made by hand by skilled artisans. They are _assembled_ by an assembly line on a factory floor by a documented, repeatable process.

A better analogy might be: how do you go from a blank whiteboard to Ford Fusion Hybrid #1?

</comment></comment><comment><USER66> In my experience, a methodology should help a team get work done without having to think about the various steps/stages of the work.

Large corporations like to get everything down to a standard process (typically). A software development methodology lets them do exactly that; it promises a consistent process and (hopefully) quality.

In a way this works well - small firms innovate and come up with new methodologies which may at some point get to a tipping point where everybody wants a piece of the latest craze. Not everyone is in the business of questioning what works well or why - "if the competition is going Agile or setting up a DevOps team, then it must be good for us as well"

</comment><comment><USER67> 1\. Most important thing: do the users want the change. If not they sabotage and you fail. Users will never be happy.

2\. Do you have enough experience and do they work well together, if not your mostly screwed. Right hand doesn't know what the left is doing. Takes too long to train new people usually.

3\. Are estimates being treated as estimates or is date,team and scope being dictated from above? project triangle anyone. Stretch goals for managers mean long nights and weekends for the team and bonuses for other companies recruiters.

4\. Has management been over sold on buzz words and marketing hype?

5\. Is there some kind of incentive to come in under budget. So, much for quality.

All of the above can screw up a project quick.

</comment><comment><USER68> I think the key insight of the article is how different each person is in temperament and how that comes out in programming teams.

What is interesting is why this relates to software more than, say, ditch digging or gardening.

I would say that is because software involves dealing with the most complex situation imaginable as effectively as possible. In other situations, a person only has to mobilize some of faculties, in software, a person has to mobilize all of their faculties - or at least much more of a certain type. But this shows how different people's abilities are at the limit. Not just different in extent but different in kind.

</comment><comment><USER69> The author seems to answered his own question if you pull out some key points and examine them in a logical way:

1\. Software development was tightly controlled in the 70's through a hierarchy of management (project managers, business analysts, senior programmers).

2\. Today the hierarchy is gone, reduced to "team leads" and "scrum masters" with no real authority or control.

3\. Today programmers left to themselves often adopt or create methodologies stricter and more filled with ritual than software development in the 70s.

4\. Today he often gets involved in 1 or 2 people projects that have so much process and "best practice" that nothing of real value gets produced.

5\. What makes software development work is "conceptual integrity" or common vision or that feeling working on a team where everyone clicks and things just get done.

6\. He doesn't understand why he had that feeling more in the 70's than now.

Well if you follow the logic, what is missing? The hierarchy of management. Which he seemed to blame for the original reason why software development methodology doesn't work.

I hate to admit it, but maybe the hierarchy of management added more value than we gave them credit for?

He sort of suggested finding that "feeling" in a project/team was unpredictable, random. But perhaps the hierarchy of managers actually had valuable skills that led to higher success rates of projects achieving that "feeling"? Perhaps they had a knack for picking the right people and for managing people in a way so they worked together more efficiently? Of course they weren't perfect and there were some bad apples, just like any profession.

I wonder what the demise of the hierarchy of managers was caused by? Did the hierarchy of managers lose these skills overtime and become useless? Did programmers just not recognize their value added and throw them under the bus for 30 years until they didn't have a leg to stand on? Was it pure budgetary, cut costs and get rid of the resources with the least perceived value?

DISCLAIMER: I am not a manager. I use to be very hard on managers, then I became one for a while, realized how difficult their jobs can be, and now I am one of the easiest people to manage.

</comment><comment><USER70> I think software development methodology 'erodes' over time.

For example original waterfall was kind of similar to agile methodology, there were re-estimations, milestones, prototyping... But I never heard anyone recently saying that our presumptions were wrong and we need to re-design and re-estimate.

Agile (scrum to be specific) in many companies is practically form of micromanagement. Number of companies are using 'agile' without automated tests and other necessary tools.

</comment><comment><USER71> Methodologies alone don't guarantee success.

I find more problems when there's less focus placed on understanding the data, manually, first, before placing it into a process.

Methodologies don't make it any less important to find, connect and understand the data first, but it seems to happen way too much.

A methodology I see missing is when we developers obsessively focus on optimizing tooling and code, instead of obsessively finding and understanding the data first.

</comment><comment><USER72> I agree mostly with the article. The most important thing about any team is its people and their individual & team dynamic. 2nd is motivation to make the project a success.

3rd or possibly lower is the methodology used. The methodology's main purpose in my opinion is to align everyone's working style to milestones, it doesnt reveal anything about whether the project will succeed, only how we will approach it.

</comment><comment><USER73> I am becoming more and more convinced that the single most important part of the development process is the creative one. Seems every successful project I have seen has been one with a very well directed creative development team.

My hypothesis is that when you get engineering and management teams to try and manage out the creative aspect of most projects, things just go poorly.

</comment><comment><USER74> Nicely said.

One thing I found that helps a lot is to work on a product that includes EEs and MEs, e.g. not pure software. It really drove home two points:

\- process can work if people actually follow it

\- the craft part of engineering takes a long time to learn but software is such a young field that practitioners are distracted by shiny objects instead of focusing on learning their craft

</comment><comment><USER75> +1 for old-timer perspective and the reference to fred brooks' conceptual integrity. And to think, the MMM said most projects suffered from too weak of management _back then_.

-1 for being too short of an article; I wanted to hear better specific examples, and was sad when I saw the comment section starting :-)

<comment><AUTHOR> Thanks for the kind words! I have a pile of notes that I decided to work into several articles, so stay tuned.

</comment></comment><comment><USER76> I have to say, I'm not a huge fan of articles or discussions with titles that beg the question.

</comment><comment><USER77> It all depends on the domain.

In defense applications, software development methodologies work excellently. For example, MIL-STD-498, which I've used extensively in the previous decade, has worked wonders.

</comment><comment><USER78> Summary: No article containing the word "methodology" is worth reading. Instead, spend time talking and listening and understanding exactly which problem you need to solve.

</comment><comment><USER79> I think one part of the problem is that success is extremely non-normal with a very fat tail. To separate the effect of methodology from luck, you are going to need a lot of data.

</comment><comment><USER80> I think one large problem is that no matter which new-age dev methodology you're into, if you're working to an incomplete spec it won't matter.

</comment><comment><USER81> It's not the methodology; it's the people.

Been around long enough to observe 100% correlation, extensively.

And it's a small minority who are competent.

</comment><comment><USER82> it seems to me that iterative methodologies (like basic "agile") are an implicit acknowledgement that development methodologies don't work. periodic re-adjustments based on local circumstances are necessary because the terrain on which our current software systems rest is too unpredictable

</comment><comment><USER83> Because they only really affect the dev team. The clients are virtually exempt, which destroys any process.

</comment><comment><USER84> Workification, tricking people into doing useless work by making it seem productive and unfun.

</comment><comment><USER85> Because, in the end, no one actually knows how to write software.

<comment><USER5> That's clearly untrue, because software does get written and often enough it even works well.

Knowing how to make something doesn't mean that you know how to make it instantly without any costs, however - or on whatever other arbitrary schedule management sets out of ignorance

</comment></comment><comment><USER86> Form a good team is more important than choosing a methodology.

</comment><comment><USER87> Of course they don't work. You expected something else?

</comment><comment><USER88> People.

</comment><comment><USER39> None of it works because Waterfall and most forms of Agile both assume closed allocation, which is a bad assumption that wrecks everything. Closed allocation dooms you to prevailing mediocrity and process can only make that worse.

Most management and process exists to turn 1.0x developers into 1.2x (in theory) but turns the 10x into 3x or 2x or sometimes -2x. When you start enforcing process, closing up definitions of work, and take power away from engineers, you lose so much more off the top than you get from bringing up the bottom.

The problem is that very few executives _actually_ want to create an inspiring place to work where people do their best. ("Fuck you, I've got mine.") They want incremental "improvements" (of questionable long-term value) on what already exists. This hand-wringing about process sounds a lot like early communism: it trudges along happily, inventing new structures, in complete ignorance of the human motivations around it.</comment>


Been waiting for ACH transfer from Coinbase since last Thursday - <AUTHOR>

Do you know what's happening with Coinbase? They never had such slow service and always delivered on specified date. <comment><USER2> Did you contact them?</comment>


"Crap" iPhone App Milking $200/hr - <AUTHOR> http://www.iphonedev.in/iPhone/Crap-iPhone-App-Milking-$200/hr.html

<comment><USER2> I'm so tired of talking about fake gag iPhone apps.

I'd like to thank the person who made the Clinometer app, wherever he or she is. It's like a $2 digital level. It's really a slick real-world tool I didn't expect to turn my iPhone into.

</comment><comment><USER3> I don't understand where these ads he is displaying are showing up?

Can someone with an iphone explain please

<comment><USER4> I just downloaded it: there's a thin banner across the top that says "Find Golf Resorts Maui Hawaii Now!" with small "Ads by AdMob" text beneath that.

<comment><USER5> Anyone know if there are other options (besides AdMob) for developers to insert these kinds of ads in their app?

<comment><USER6> Google does :p

I am just saying that because I wondered too what company does iPhone ads. I guess any "mobile ad" thingy will do it for you.

Anyway, in my 45 seconds research I found one called JumpTap.

What I didn't find is how much a publisher can expect to earn with any company. If it's around the same rate as websites, let's speculate because it's fun.

To achieve $200/hr at .50 cpm

$1 = 2000 "page views"

$200 = 400,000 "page views"

400,000... that's probably how many "sessions" with the app. Now with a:

10% ctr: 4,000,000 sessions per hour; 25% ctr: 1,600,000 sessions per hour;

Free app... 20 million possible user base... ah, whatever... that's getting complicated :p But I bet a spreadsheet where we could tweak the numbers could show what's the potential of popular apps to earn with ads...

<comment><USER7> I'm somewhat doubtful about the original claim of making $200 per hour exactly because of the math that you present. Or rather, $200/hour for how long?

Even if all 20mio(?) iphone owners downloaded and used the app once that only amounts to $10000 bucks. If we assume they show it to all their buddies in school, say 20 times, then we arrive it $200k bucks. Heck, add a ton of clickthroughs and real hardcore fans and make that $400k.

One hell of a deal for a 20 minute app, no question. But all under imho _very_ optimistic assumptions. I'd go as far as to smell a little PR stunt maybe?

Anyone know some real world figures about iphone app sales?

<comment><USER3> Agreed, I think 200$/hr is probably an exaggeration. Although as a developer I would love to hear otherwise.

I found this post from a couple years ago about admob: [http://venturebeat.com/2007/08/07/admob-ups-ante-in- mobile-a...](http://venturebeat.com/2007/08/07/admob-ups-ante-in-mobile-ad- fight/)

The comments thread is interesting. Apparently admob is mostly a CPC company not CPM. I can only imagine how low the clickthrough rate for golf resorts in hawaii on a sound bomb app are.

<comment><USER7> After a bit more research on the subject I think it's fairly safe to call bullshit on that $200/hour figure. It's either a concerted PR stunt or the app developer is trying to push his market value.

While I didn't find much information about iphone app sales or revenue figures I did indeed find some sobering bits about regular web ad gigs.

A good example with published stats is one that we all know: Desktop Tower Defense. [http://novelconcepts.wordpress.com/2008/03/11/happy- birthday...](http://novelconcepts.wordpress.com/2008/03/11/happy-birthday- desktop-tower-defense/)

This game has undoubtly spawned one of the biggest viral hypes of the recent years. Nonetheless and despite fairly reasonable advertising efforts under massive traffic it "only" managed to pull in 100k over 12 months, or roughly $11 per hour.

So yes, those hawaiian golf resorts must be paying one hell of a CPC/CPM rate. Wonder what they'd pay me for wearing a t-shirt with their URL. I think I'd do that for a measly $1/hour...

<comment><USER6> Yeah, I feel you. I think I know what happened. Some "journalist" took poetic licence interpreting what the developer probably said:

Dev: It took me 5 hours to build and I made $1000.

Reporter: Developer makes $200/hr building iPhone apps.

We've all done this kind of math before (revenue / work time), but I think somewhere the context was lost on this one. _Unless_ somewhere we can find the developer actually saying "I make $200/hr even when I am sleeping."

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> I have doubts that he's making $200 an hour w/ that app, especially with AdMob. We dropped admob b/c of the terrible returns, check their forums.

</comment><comment><USER9> his "tip" is to do market research to prove that everyone is uncool? sorry bud, you got lucky...

<comment><USER10> That seems to be his point. "Like the pop market, it's hit or miss; sometimes it will work, sometimes it won't."

Basically he's just managed to find the immature market. The thing about that is, it's extremely difficult to reproduce.

As much as gagware pollutes the market with bright colors, loud noises, and minimally functioning apps, it obviously has market value, so it won't be going away anytime soon.

<comment><USER11> Kind of like spam? I doubt anyone would send 411 scam emails or sketchy pharmacy ads if no one ever fell for them or bought pills.

<comment><USER12> I'd say it's still a couple rungs above spam: you're still making something people want. I don't think anyone actually _wants_ to be defrauded. (you could bring up honey pots by law enforcement, but I don't think they're the inteded market for scammers) In fact, if the outcome was desired by all involved parties, you couldn't call it fraud.</comment></comment></comment></comment>


Bye Bye Linux (Ubuntu), Hi Again Windows - <AUTHOR> http://hypecycles.wordpress.com/2009/09/01/bye-bye-linux/

<comment><USER2> Good stuff, but there is something a lot of people don't consider (and the author didn't here either). Most "benchmarks" people use to judge Linux are based on experience with Windows, yet almost no one ever judges Windows based on Linux. Linux makes much more of an effort to meet Windows benchmarks than vice versa.

Linux is (mostly) secure by design. How does Windows stack up?

Linux has a powerful command line interface which can do almost anything that can physically be done on a Linux system.

Linux comes equipped with programming support (I think a C compiler should be considered a standard part of ANY system).

Linux (generally) has resizable dialog boxes. The Windows environment variables dialog box is downright evil.

Linux allows for a great deal more system and desktop customization.

If you get used to running Linux, you can pretty much dual-boot or straight up change your OS on a whim (especially given the available of Gnome and KDE). Also, you have something to change to. If you decide you get sick of Windows, it's a much bigger deal to change OS. Windows to Linux is nothing like Ubuntu to Arch.

Installing and running a development/test web server on a Linux machine is almost trivial.

I would say in general where Linux excels, it excels far more than Windows does where Windows excels. Windows may be a little better in some areas, but where Linux is better, it's so many lightyears ahead that Windows isn't even in view anymore (think virus protection for example).

<comment><USER3> The command line really is hard to make up for, without a lot of hassle, that is. When I'm running windows it's the thing I miss the most.

Other than that, it sucks that Firefox is not nearly as polished under Linux as it is under Windows. Same goes for adobe's flash player.

<comment><USER4> Have you tried Powershell? I haven't found much I can't do with it (though I admittedly have limited Linux experience)

<comment><USER5> Powershell's single, deal-breaking problem is that there is no integration with the rich Unix CLI environment, which means that it can hardly be used as the superglue that bash and zsh can be used for. Which means that it's basically a shell language on steroids, for which I'd much rather recommend and interactive Ruby or Python shell. Powershell's problem is that it exists in an ecosystem that does not acknowledge the CLI, and it will not be useful until that situation is reversed. Since, to this day, mos windows apps don't have backends for CLI interaction, I doubt thethings will change for several years.

</comment></comment></comment></comment><comment><USER6> This is a nice article. He makes some good points. I'm generally leaning Linux-ward these days, but I really appreciate what he says about laptops.

A few notes:

\- On the initial installation, CD + 20 minutes for Linux, CD + 2 hrs for Windows, sounds about right to me. But another point to make is that on Ubuntu, another 20 minutes, maybe an hour at most, gets me a fully loaded system, while on Windows I'm swapping CDs for days. Of course, I don't have to do that Cisco VPN stuff he complains about.

\- An issue that he doesn't touch on at all is the general "scriptability" of the system. I've found that under Linux, it is usually much easier to write a little script to automate some task, than it is under Windows. Of course, this matters not at all to some people.

\- Laptops, external displays, etc.: Definitely. If I were running the Ubuntu project, I'd put everything else on essential-maintenance-only status, and _get_ _it_ _working_ _right_ _on_ _a_ _laptop_ as soon as possible.

</comment><comment><USER7> Unfortunately one of your problems is reliance on Microsoft Products and specific hardware even when you were switched to Linux, such as Office/Outlook and products such as the Dell Docking Station and Multi Function Printers who doesn't support any *nix, and Cisco VPN (look in to vpnc). That's like comparing using Windows and trying to get KOffice and Cygwin working on Windows and benchmarking so.

You pick a platform, and start using the tools associated natively with it.

Linux isn't a good suite for everyone, and definitely not in this case.

<comment><USER8> Yeah, the VPN paragraph had me laughing. Surely one of those 14 blogs should've mentioned "sudo apt-get install network-manager-vpnc". VPN is a breeze on Ubuntu.

<comment><AUTHOR> Yes, I saw that but it doesn't work too well if you can't use Network Manager to begin with.

See bug 55434 that I reported in december about this.

<https://answers.launchpad.net/ubuntu/+question/55434>

I had to switch to WiCD which did allow me to do WiFi at work.

Now, it may be possible that I could use network-manager-vpnc with WiCD but I couldn't find a way to do that.

<comment><USER8> Ok, that's legitimate. But it sounds like your complaint is really with network manager, not Ubuntu's VPN support. And hey, at least you have a place to report bugs :)

<comment><AUTHOR> There, my friend, you have a point!

Yes, my grouse is with Network Manager but that is really a distinction without a difference. I have a problem with Ubuntu by extension.

</comment></comment></comment></comment></comment><comment><USER9> Actually the external screen stuff worked quite well since one or two releases ago. At least for me. They added nice controls for it.

Printer - oh well, just have to buy the right one, I guess.

Docking station: very exotic use case.

<comment><USER10> > Docking station: very exotic use case.

It's only exotic to Linux users.

<comment><USER9> With modern notebooks I have never seen the benefit. What does the docking station add?

<comment><USER11> Really?

The way my desk area is set up is I guess a vastly different use case from yours. My laptop is primarily mobile -- I take it to work, work from coffee shops, the couch, etc., but when I want to do something that I need need more of a desktop setting for (I can't do image editing on the couch, or without a mouse, or without a large screen usually) I just plug the laptop into the docking station.

The docking station is connected to an external hard drive for backups, speakers for sound, external monitor, keyboard, mouse, power cable, Line 6 Pod XT guitar pedal and mixing board.

It allows me the flexibility of having a convenient desktop setup while still maintaining the portability I bought a laptop for. I'm surprised more people don't use it, as it seems like the edge case here instead of the norm.

<comment><USER9> Most of those problems went away with the arrival of USB hubs. Granted, I still plug more cables than you do (monitor, sometimes audio). But I think for audio a USB solution could be found, too, then I would be down to three cables (monitor, usb hub, power). Sure, docking station is a bit faster, but it is also much uglier (most of the time). I guess it depends on how often you move around with your notebook.

I always work with an external monitor at home, but I use my notebook's keyboard. Atm I also only bother to plug in audio when I need it - I admit audio is a sore point, but when I have time, I'll try to find some wireless solution.

<comment><USER11> I suppose that's true, but then I'd still have to plug in a USB cable even. I guess I just really like the idea of not having to plug in ANYTHING.

If I'm away from the docking station, I mumble curse words when I have to plug in so much as an ethernet cable.

</comment></comment></comment></comment></comment></comment><comment> old-gregg He is complaining about docking a Dell. Can anyone here confirm that latest Ubuntu works with latest Dell Latitudes and their docking stations?

I just placed an order on one of them and I'm getting nervous. Google searches didn't reveal any potential problems.

My specs:

Latitude E6400,

NVIDIA Quadro NVS 160M,

Intel® WiFi Link 5300 802.11a/g/n Draft Mini Card,

E-Port, dock for charging, digital video, and USB / eSATA port support

</comment><comment><USER12> Complaints are:

1\. Hard to set up printing to complicated printers.

2\. Laptop docking station doesn't work.

Yeah, hardware compatibility is indeed a perenial problem with linux distros. The reason is that it's not something the OS vendor can solve. The truth is that Microsoft doesn't make this stuff work, HP and Dell do. They're the ones who get the support calls when stuff fails, so they're the ones with an incentive to make the integration work right. The linux world has no equivalent player (in the consumer space -- there certainly is on servers, where vendors care deeply about linux support).

3\. Distros don't update Firefox when new releases come out.

I think this is fair. There are arguments to be made either way, but it's true that a windows user has a much easier time upgrading to new versions of popular software at release time than linux folks do, where you generally need to wait 0-6 months for the new Ubuntu. I think some kind of answer for the user who wants to download someting new Right Now would be a good thing.

4\. External monitor support sucks in X.org.

Absolutely true, but it's improving rapidly.

<comment><USER13> 3 I don't get. Ubuntu has both Firefox 3.0 and 3.5 available to choose in a simple list of software. His problem seems to be that he doesn't like the Firefox codename which is hardly the end of the world.

<comment><AUTHOR> Not really. When I wrote this post, 3.5 was not an available UPGRADE for 3.0. You end up with both 3.0 and 3.5 on your system, and still do.

I have no issue with the name.

The issue with many Linux bigots is that they think the rest of the world is somehow stupid and not as smart as they are, as evidenced by some of the other comments on this trail. They seem to believe that the things that the rest of the world wants (which they see as unimportant) are in fact worthless (like the comment about docking stations).

</comment></comment></comment><comment><USER14> Just a note for the upcoming October release of Ubuntu: I've been trying the alphas, and in version 2 all my external display woes have gone away. It's as easy as setting up external displays in windows.

</comment><comment><USER15> I'm a little depressed that external monitor support is still so poor. The last time I tried it was 2 years ago back in college, and it took me weeks of Googling, reconfiguring and reinstalling to get it to just barely work. Seems like it has barely moved since then... what a shame for something so obvious and vital to many laptop users! Reminds me of the xkcd comic. (<http://xkcd.com/619>)

</comment><comment><USER16> Could do without the attitude, but would be interested to see the author of the blog try a mac for a bit and compare.

<comment><USER14> Yeah good luck with the docking station and installing on his computer.

<comment><USER17> MacBooks have docking stations?

<comment><USER14> I guess that's a show-stopping problem for this guy, eh?

</comment></comment></comment></comment><comment><USER18> With the default xorg.conf, usually you just plug in your second monitor and type 'startx -- :1' for your presentations... it is annoything that if I'm working on the train (one screen) and I get to work, I have to start a new X session. I think xrandr solves this issue but it's not ready for me yet.

</comment><comment><USER19> Its a sad thing that while most of linux kernel code is drivers, its hardware support is still flaky in many places :(</comment>


Show HN: The Poet of Logic Programming (Interview with Robert Kowalski) - <AUTHOR> https://thesearch.space/episodes/1-the-poet-of-logic-programming <comment><AUTHOR> I just launched this podcast about logic programming, kicking off with an interview with one of the founders of the field. Any and all feedback appreciated!

<comment><USER2> Podcasts don't generally count for Show HN, but this one is such a nice and obscure topic that we'll make an exception.

In general, you'll do better with these on HN if you can include a transcript and make it primarily a thing to read, with the option of listening as well. Audio posts do worse than video, which in turn do worse than text. Not sure why that is, but it's been the consistent pattern here for years.

<comment><AUTHOR> Ok thanks for the info and for making an exception! I do have a full transcript and plan to put it up. Just need to rebuild the site first... (It's a bit surprising that audio does worse than video btw.)

<comment><USER2> Email us when the transcript is up and we might be able to give you some tips.

<comment><AUTHOR> Thanks, sure will.</comment></comment></comment></comment></comment>


Chrome Cube Lab - <AUTHOR> https://chrome.com/cubelab <comment><USER2> Does the breaking scroll bother anyone else? Besides trying to make a statement, does the breaking scroll serve any practical purpose? For example, does it give the cube on the top/first nav window a chance to load/unload?

Also, it's especially weird that the button in the top left takes you all the way to the top, but the buttons on the top right manage the rest of the navigation.

<comment><USER3> yeah, makes the back button super fun too. Each pause seems to insert itself into history.

<comment><USER4> This is the second link I've seen today that does this (Hood.ie being the other). Can we stop this before it becomes a thing?

</comment></comment></comment><comment><USER5> Why is this so slow on Firefox? Why is every single cool thing that show up on HN so slow in Firefox?

<comment><USER6> Chrome is quickly becoming the new IE. Browser demos are now frequently written and tested for the quirks and behavior of a single browser. (and it's always Chrome)

This behavior people have been railing against for years is once again standard.

<comment><USER7> Not really. They are based on open standards that use functionality that happens to be faster under V8 (chrome's javascript engine).

In fact, this uses threejs[1] under the hood. It is just that the version of Firefox someone is using sucks in comparison to Chrome for the three.js stuff (likely WebGL).

[1] [http://threejs.org/](http://threejs.org/)

<comment><USER8> In practice, an "open standard" that has only been suitably implemented by just one party really isn't all that open.

Now, maybe there's a greater chance that the situation will change, and other suitable implementations will eventually arise. But until that happens, an open standard with one usable implementation really isn't different from a closed standard at all.

<comment><USER7> I would counter that and say, "An 'Open Standard' created and then implemented by 1 party is no different than a closed standard".

However, Khronos[1], the entity that makes opengl, also made the webgl standard. The fact that mozilla hasn't done as good of a job implementing it as google has doesn't magically negate the fact that it is still an open standard (that mozilla has actually implemented, just poorly).

[1] [https://www.khronos.org/webgl/](https://www.khronos.org/webgl/)

</comment></comment></comment></comment></comment><comment><USER9> The 'Get the Code' link is broken ([https://chrome.com/cubelab#create](https://chrome.com/cubelab#create)). Does anyone have a link to the code?

</comment><comment><USER10> This is really cool.

Aside from the cool tech, it seems like Google is trying to build on the viral mechanisms that made 2048 so popular - they make it really easy to fork, customize, and launch your own version.

Nice idea, really.

</comment><comment><USER11> Well... IE 11 failed in rendering this correctly like i knew it would. Yet every other day my PC nags be about updates

</comment><comment><USER12> If you're into JavaScript pop open the browser console on this guy: [http://iamthecu.be](http://iamthecu.be) :)

Works best in Chrome / Safari / Opera.

</comment><comment><USER13> Cool! It seems that other than WebGL, this experiment uses only CSS3 transform. I never thought such a complicated thing can be done by CSS.

But...The faces wink a little on my firefox

</comment><comment><USER14> WebGL "hit a snag" on like 30% of these but the 808 one was magically timed to the tempo of a song I had playing (the tap tempo didn't work, though).</comment>