"The hype and dogma of Agile evangelists has left in its wake a trail of broken projects, ruined businesses and misguided neophytes bleating the tired doctrines of their long departed prophets. The games industry was no exception, with many swept up in the phantasmagoria from which we are only now beginning to witness the debris."

http://gwaredd.blogspot.com/2010/02/game...world.html

Ugh. I had a nice post going but accidentally three finger swiped my trackpad and lost it. A wonderful feature that you cannot turn off (unlike all the other multi-touch controls) and only gets used by accident.

Anyway. The summary: I liked the article. It pointed out some things that I've noticed too. Agile seems to break down when you don't have a crack team of highly motivated people. As a "people oriented" practice, it creates a lot of animosity when you have just one bad egg on the team. There were some other points I was going to make, but I don't remember them anymore.

Meh i believe software development paradigms are bull. If you follow blindly any paradigm you are bound to fail.

Fixed business paradigms imo are followed by inept managers that have no clue about their business, and are incapable of formulating a well thought out plan/methodology with their own brains. So in general i think following ANY fixed business paradigm is a good predictor for failure.

You need some intelligent, technically adept management capable of coordinating the job, delegating the right tasks to the right people, following a rational methodology but keeping it flexible in order to work out the problems that most likely will occur.

If you get management without any technical experience in the business, things will possibly get very ugly. Unlike many fields where marketing is more important than the product, this is not the case for software, and making a good product is not trivial. Take the case of John Sculley, the marketing man that did wonders for Pepsi, almost killed Apple.

Making and selling software != Making and selling sugared water

Oh. One of my points was that the last place I worked at, with AndyKorth actually, often had the two of us working together on small well contained projects. They gave us a lot of latitude to manage ourselves as we saw best and I think it worked out pretty well. Those were probably some of my most productive times at that company.

Najdorf Wrote:Meh i believe software development paradigms are bull. If you follow blindly any paradigm you are bound to fail.

Fixed business paradigms imo are followed by inept managers that have no clue about their business, and are incapable of formulating a well thought out plan/methodology with their own brains. So in general i think following ANY fixed business paradigm is a good predictor for failure.

Well, and in our cases, I think most of us are "lone-wolf" developers who work individually or in small teams of up to two or three guys. Group-think and large team strategies don't matter much on our scale.

Still, it's important to pay attention to some of the ideas out there because many of us might wind up in those situations some day. I don't know how it is in other parts of the world, but here in the US, corporate group-think stuff is the way of the land nowadays.

OTOH, I was just reading "Skunk Works" about Ben Rich's time at Lockheed and there is definitely a different approach to everything. The old days of lean and mean teams are going away quick though.

Honestly I have the impression most of the programming paradigm tips are needed for management that would have no clue otherwise.

For instance SCRUM's brillant idea to keep a working build and adding one piece at a time. Duh, to me that's common sense that any software developer has.

I think these paradigm are just a way to interface managers with development common sense.

Has anything been written about the paradigm (if in fact there was such a thing) employed by Xerox PARC in the mid 70s?

Najdorf Wrote:Honestly I have the impression most of the programming paradigm tips are needed for management that would have no clue otherwise.

For instance SCRUM's brillant idea to keep a working build and adding one piece at a time. Duh, to me that's common sense that any software developer has.

I think these paradigm are just a way to interface managers with development common sense.

I think that Scrum's biggest advantage is it decouples actual developers from higher management. Progress-disrupting bullshit ("Hey, can you animate this button? My dog thinks it'll look better!" [theoatmeal.com]) gets stuck on an impartial stack of tasks. Managers are forced to look at all the things on the developers' plate and to actually justify the added value to the product of whatever hair-brained feature they're demanding.

Scrum's biggest weakness is that it requires that the developers have the discipline to select tickets to work on and are motivated enough to have someone take the boring jobs. Otherwise it all falls apart.

I totally agree though: when you start worrying about process more than product, you've already lost your product. Methodologies like Scrum when used as a tool are fine, but when adhered to like a religion... BadStuffâ„¢ will happen.