Slashdot Mirror

It's a good article, but the pattern is an old one. Twenty (20) years ago, I wrote much the same thing about object-oriented technology. Since then, I've found that the same issues, the same pitfalls, pretty much apply to any new technology or methodology; here are some more generalized pitfalls (based on ones from the 1995 book) that I wrote up nearly a decade ago (2008):

-- Adopting a new technology or methodology for the wrong reason
-- Thinking a new technology or methodology comes for free
-- Thinking a new technology or methodology will solve all your problems
-- Betting the company on a given technology or methodology
-- Getting religious about the technology or methodology
-- Adopting a technology or methodology without well-defined objectives
-- Overselling the technology or methodology

These all apply to Agile -- but they also apply to just about every other 'silver bullet' technology or methodology that's come along. ..bruce..

Not to pile on here, but there is nothing new or recent about fear-driven projects of any kind, much less fear-driven IT projects. All you need to do is read some of the classic books on IT project management, including The Psychology of Computer Programming by Jerry Weinberg (1971), The Mythical Man-Month by Fred Brooks (1975), and Death March by Ed Yourdon (1997).

Back in the early 90s, I was chief software architect for a start-up developing a large, complex and novel commercial software product. After working long hours for years, we had missed our original release date and were struggling to come up with a new date that we could be sure of making. Top management (CEO, CFO) was considering carrot/stick "incentives" to "motivate" the engineering team to make a certain date; one of the senior developers stopped me in a hallway by the engineering offices and asked, "Don't they realize they're dealing with grown-ups back here?"

P.S. At the risk of sounding like an old fart, I remain appalled at the profound lack of familiarity among far too many IT industry practitioners of the essential books on software engineering and IT project management. As I have said ad infinitum and ad nauseum, not only do they keep re-inventing the wheel, they keep reinventing the flat tire.

Summary points to a press release. The actual decision is available here: http://bfwa.com/docs/dealertrack.pdf (7 page pdf)

Actually, outside of the discussion of architect vs. developer, Brooks doesn't address "managing seasoned programmers" a lot, which was the poster's question.

As you can see from this article and from this list, I have a lot of books I can recommend for IT management in general, starting with "The Mythical Man-Month". ..bruce..

Gary:

Yep. What you said. :-) I happen to be writing a book (Pitfalls of Modern Software Engineering), which is a greatly expanded version of a book I previously wrote and published (Pitfalls of Object-Oriented Development, M&T Books, 1995). I'm posting the revised pitfalls, a few at a time, on another website (see here). Many of these pitfalls are clearly political ("Picking the wrong horse") and are labeled as such. ..bruce..

Actually, there are quite a few books that discuss IT project failure (including runaways); here's a recommended reading list that I keep on one of my web sites (though you'll have to wait until the server recovers). ..bruce..

A cursory glance at a semi-reliable source of information hints at which company ABC just might be (also apparently on the same slashdotted server as brucefwebster.com -- confirmed via DNS).
Now who would like to identify BigFirm?

Thanks for all the great comments, though I suspect many of you didn't ready anything more than the brief extract posted here at Slashdot. :-) Because certain themes keep coming up again and again, I thought I'd address them in a single post (I also posted this over at my website).

Here's a response to the main themes that I see coming up there.

The Dead Sea effect isn't unique to IT. True enough, though I could say the same thing about just about any project management issue regarding IT. What is unusual about IT (shared with other engineering disciplines) is the degree to which individual talent and other factors affect productivity and quality. And what is unique about IT (as opposed to, say, civil / mechanical / chemical engineers, architects, etc.) is that there is no standard (state-run) professional certification, so there is no assurance of minimum education and competency.

This is obvious/common sense/trivial. So are most of the problems in IT. Fred Brooks and Jerry Weinberg pretty much nailed down all the essential issues in IT project and personnel management more than 30 years ago; yet, amazingly, the problems haven't all gone away! There is a profound lack of professional and institutional memory in IT; almost everyone who writes about IT project/personnel management (myself included) is looking for new ways to cast or explain the core issues in a touching hope that maybe this time someone will actually listen and fix them.

The Dead Sea effect is just the Peter Principal (or a corollary thereof). No, it isn't. The Peter Principal is that a given person rises to her/his level of incompetence (I'm actually old enough to remember when 'the Peter Principal' first came out). This has nothing to do with promotion within the IT organization; it has to do with self-selected removal from that IT organization, not due to a lack of promotion or opportunity, but just because there are greener pastures elsewhere.

Not all IT shops are like this . I would certainly hope so. In fact, there are IT organizations where just the opposite occurs; the quality of the IT engineers is quite high, and engineers who are mediocre or disruptive either don't get hired or don't last long if they are. I worked in one such IT group (Pages Software) for five years. During that time, we had only one voluntary departure (the network admin); we had two others who were dismissed due to problems, and a few others who were (painfully) cut in downsizing.

Not everyone 'left behind' is incompetent . Again, this syndrome doesn't apply to all IT groups, and it doesn't apply to the same extent to all IT groups. Turnover in IT personnel is common (though it can be reduced by intelligent management), and just because good engineers have left a given IT group doesn't mean that the rest are, in fact, residue. What I'm talking about here is a very real syndrome, typically found in large corporations and government organizations, but it's certainly not universal.

The IT hiring process is broken. Amen. Not only is the IT hiring process broken in many organizations, the entire approach to IT is often broken. It is rife with empire-building, 'heroic' project management, and an 'interchangeable code monkeys' mindset. As mentioned in the comments

• Becoming a Technical Leader by Gerry Weinberg. Gerry talks specifically about making the transition between being in the trenches and being a manager-type and just what you have to give up in the process.
• Journey of the Software Professional: The Sociology of Computer Programming by Luke Hohmann. This book is not nearly as well known (and read) as it should be; it's also a great source of references for hard research on IT development teams.
• The Mythical Man-Month (20th Anniversary Edition) by Fred Brooks. Just because anyone in IT management should read, understand, and believe this book. I deal with failing or failed IT projects for a living, and most of those failures occur for the same relatively small set of reasons.

As I stumbled down memory lane, I came across an open source project to resurrect Sundog, by its original author.

Woo Hooo!!!

Elite

Indeed. SunDog as well.

In my experience many in the IT field fall into one of two categories: Those who do the work and those who make a living telling people there are better ways to do the work (this group usually correlates with people who couldn't actually do the work themselves). Reading your resume it is readily aparent what category you fall into...

Brooks, in the "No Silver Bullet" essay referenced above, stated that there is both essential and accidential complexity in software development, and because of that there never would be a "silver bullet" to slay the software "monster". However, there are fundamental practices that increase the likelihood of success and fundamental pitfalls that every project faces. And, in the end, the root causes of most failed IT projects are human factors; in fact, you could just cite the "seven deadly sins"--pride, envy, gluttony, lust, anger, greed, sloth--and probably hit the nail on the head.

In conjuction with that, far, far too many practitioners in the IT field lack one or more of the following:

• Talent
  
• Sufficient (or any) education in software engineering (or even computer science)
  
• Any familiarity with the literature from the past 30+ years. I'm not talking about IEEE/ACM Transactions, I'm talking about standard classic works such as _The Mythical Man-Month_ (Fred Brooks), _The Psychology of Computer Programming_ (and everything else by Gerry Weinberg), _Principles of Software Engineering Management_ (Tom Gilb), _Peopleware_ (and everything else by Timothy Lister and/or Tom DeMarco), _Assessment and Control of Software Risks (and anything else by Capers Jones), _Death March_ (and anything else by Ed Yourdon), _Journey of the Software Professional_ (Luke Hohmann), and any of the 100 or so texts on software engineering on the bookshelf behind me.
  

To quote George Santayana (who is often misquoted):

Progress, far from consisting of change, depends upon retentiveness...Those who cannot remember the past are condemned to fulfil it.

Software engineering is hard enough--with all the human issues--without further handicapping ourselves with ignorance of all that has been already discovered and documented. Yet that is exactly what most IT workers do. Until we find a way to solve _that_ problem, the failure rate for IT projects will remain high indeed. ..bruce..

Brooks, in the "No Silver Bullet" essay referenced above, stated that there is both essential and accidential complexity in software development, and because of that there never would be a "silver bullet" to slay the software "monster". However, there are fundamental practices that increase the likelihood of success and fundamental pitfalls that every project faces. And, in the end, the root causes of most failed IT projects are human factors; in fact, you could just cite the "seven deadly sins"--pride, envy, gluttony, lust, anger, greed, sloth--and probably hit the nail on the head.

In conjuction with that, far, far too many practitioners in the IT field lack one or more of the following:

• Talent
  
• Sufficient (or any) education in software engineering (or even computer science)
  
• Any familiarity with the literature from the past 30+ years. I'm not talking about IEEE/ACM Transactions, I'm talking about standard classic works such as _The Mythical Man-Month_ (Fred Brooks), _The Psychology of Computer Programming_ (and everything else by Gerry Weinberg), _Principles of Software Engineering Management_ (Tom Gilb), _Peopleware_ (and everything else by Timothy Lister and/or Tom DeMarco), _Assessment and Control of Software Risks (and anything else by Capers Jones), _Death March_ (and anything else by Ed Yourdon), _Journey of the Software Professional_ (Luke Hohmann), and any of the 100 or so texts on software engineering on the bookshelf behind me.
  

To quote George Santayana (who is often misquoted):

Progress, far from consisting of change, depends upon retentiveness...Those who cannot remember the past are condemned to fulfil it.

Software engineering is hard enough--with all the human issues--without further handicapping ourselves with ignorance of all that has been already discovered and documented. Yet that is exactly what most IT workers do. Until we find a way to solve _that_ problem, the failure rate for IT projects will remain high indeed. ..bruce..

Well, at the very least you can go check out the web page made by Bruce Webster, one of the Sundog authors.

I loved that game...

There was also a Mac program-the-robot game that had a visual programming system for which it was impossible to write a syntactically incorrect program. It sounds almost identical to what you're describing (drag and drop icons into a 2D grid), but my aging brain can't quite remember its title. Kind of sad, since I believe I reviewed it for Macworld. Sigh. ..bruce..

(has-been game designer, SunDog: Frozen Legacy)

There was also a Mac program-the-robot game that had a visual programming system for which it was impossible to write a syntactically incorrect program. It sounds almost identical to what you're describing (drag and drop icons into a 2D grid), but my aging brain can't quite remember its title. Kind of sad, since I believe I reviewed it for Macworld. Sigh. ..bruce..

(has-been game designer, SunDog: Frozen Legacy)