Archive for the 'Surviving Complexity' Category
(Chronologically Listed)
The five books every IT manager should read…right now
I’ll add “software engineers” as well, not to mention CIOs and CTOs.
My latest Baseline column is up, and in it, I discuss just why you should read these books — or, if you have read them already, why you should re-read them. ..bruce w..
The latest Baseline columns
The first column, “Second Class Software Quality for Major IT Projects”, talks about the curious fact that organizations are willing to spend millions, tens of millions, even hundred of millions of dollars on major IT project and yet still nickle-and-dime their software quality assurance (SQA) effort. It doesn’t help that SQA personnel are pretty much on the bottom of the tech status totem pole, either.
The second column, “Do Not Defer The Difficult in IT Projects”, describes the all-too-human tendency in IT development to put off dealing with the toughest problems until last — at which point, you may not be able to solve them all. It also explains why so many IT projects get 80-90% “done” and then suddenly slip for weeks or months without making much progress.
Enjoy, vote, and comment! ..bruce w..
New Baseline column up
I have a new Baseline column up on the tendency of large organizations to reject the best solutions for a troubled IT project:
The consultants, usually with the help of the employees in the trenches, would use their time, effort, and expertise to analyze the system under development or in production. They would arrive at a clear, supportable, essential solution – technical, architectural, methodological, organizational, whatever. This would be presented to upper management…whereupon upper (or project) management would say, “No, we can’t do that.”
Sometimes, they would give no specific reason why the solution was not acceptable. Sometimes, they made it clear that it wasn’t the solution they wanted or that they felt was acceptable. If they did explain their rejection, it was usually in budgetary or political terms.
The investigating team would often then go back and look for an alternate (and less optimal) solution. If one was found, often that was rejected as well, and so on, often down to the least desirable solution. Barry [Glasco] said that he and another colleague, Chuck McCorvey, had gone through this so many times with one client that they joked about simply presenting the worst solution first, since it seemed to be typically the only solution the client would accept.
Go read the whole thing; comments are welcome here or there. ..bruce..
Latest column up: wrapping up IT project metrics
My newest Baseline column is up: “Lies, Damned Lies, and Project Metrics (part 3)“. In it, I wrap up my discussion on IT project metrics, outlining a possible approach using instrumentation and heuristics. Go check it out. ..bruce..
Latest column up: more on IT project metrics
My newest Baseline column is up: “Lies, Damned Lies, and Project Metrics (part 2)“. In it, I talk about why it’s so hard to apply metrics to IT project management and begin to suggest an approach. Go check it out. ..bruce w..
The challenges of hiring software engineers
As noted in Works in Progress, I’m writing a book called Surviving Complexity, which deals with the challenges of IT development and deployment. Over at my personal website, I’ve posted material adapted from the first chapter of that book:
In my forthcoming book, Surviving Complexity, the very first chapter is called “The Wetware Crisis”. This is a greatly expanded look at a problem that I first discussed in print twelve years ago in the late, great BYTE Magazine, namely that one core problem today in information technology (IT) is that there just aren’t enough good IT engineers and that there never will be. The article itself focused on just one aspect: inherent talent. My argument, supported by various studies, is that certain people have inherent talents that help them in IT, just as others are gifted in math, music, language, and so on. My follow-up observation is that the percentage of really talented IT engineers in a given human population is (a) small and (b) fixed. (It’s hard to argue for natural selection increasing that percentage where we’re talking about geeks breeding.)
Go over there to read the whole thing. ..bruce w..