Archive for the 'Project Management' 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..
“Inside-Out”: IEEE presentation in Longmont (09/02/08)
On September 2nd, I’ll be speaking at a meeting of the Denver IEEE Reliability Society. It will be held at 5:30 pm in the Seagate Building in Longmont (CO), on Nelson Road between 75th Rd and Airport Rd.
Here’s my abstract of the talk:
INSIDE-OUT: Organizations too often treat software reliability as an ‘after the fact’ consideration, performing testing as a last step and then constraining it due to schedule and financial pressures. Webster will present a simple “inside-out” software lifecycle model where all software development activing (not just coding) takes place within a framework covering a broad spectrum of quality-related activities.
I’ll post the presentation slides here after the talk. ..bruce w..
Latest Baseline column up
My latest Baseline column is now up:
Last week, I talked about some of the reasons why large organizations often reject the best solutions for a troubled IT project: fear, pride, budget, and the ever-present internal politics. This week, as promised, I will talk about what it takes to champion the right solution. I can’t guarantee that you’ll succeed, but you will have a better shot at it.
Go read the rest of the column. In the meantime, I’ll start posting more pitfalls here. ..bruce..
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..
IT projects: fooled by success
I’m currently reading (and enjoying) Fooled by Randomness by Nassim Taleb; his concepts inspired my latest Baseline column, which talks about the risks that follow a successful IT project:
But sometimes with projects that really shouldn’t succeed—that are attempting too much, too fast, with too many risks—enough things go right, particularly along the critical paths, enough superhuman effort is made by those involved, so that the project does indeed go into production on time and possibly even under budget. Upper management is thrilled; the development team looks great; and all’s right in heaven.
And that’s when the real trouble begins.
Feedback is welcome, there or here. ..bruce..
Latest column up: distributed development (part 2)
My latest Baseline column is up, discussing how to make a distributed software development project work. ..bruce..
iPhone 2.0 - Or The Importance Of Load Testing
In case you did not happen to be within 3 miles of an Apple fan today, Friday July 11th was THE day, the holy day when Jobs the Magnificent would allow the faithful to purchase some really nice hardware, namely the second generation / 3G iPhone.
But, boys and girls, this is instead a lesson on how you can custom craft your mega phone for a year or so, spend millions on marketing and and commercials in all manner of media. You can crank your reality distortion field to maximum and still look like a crew of chimps who somehow got lost in your own hype and forgot to focus on the fundamentals.
Software and system testing is not sexy, it won’t make the cover of Newsweek, or Wired or even the Farmers Almanac. Load and performance testing is even more arcane and neglected. Everyone just figures you can always throw more hardware at the problem and you will be fine.
This morning when iPhone 3G went on sale, Apple (in it’s infinite wisdom) put a software update for the original iPhone out for distribution (through iTunes) that would give the older phones many of the same features as the new ones. They also released software for the iPod Touch (and iPhone without a phone) to do much the same. It was Christmas day for Apple gadget freaks world wide!
But as the phones went on sale at 8 AM Eastern time in the US, it became clear that trouble was brewing. As more time zones opened up and the phones went on sale, the web infrastructure that supported the sales and activation began to crumble.
What went wrong? A few things. First off Apple bowed to AT&T and insisted that everyone who bought a phone go through the activation process before they left the store. This was in part to ensure that the grey market in iPhones stopped. While it may have accomplished that, it also ensured that the real (revenue generating) market stopped too! Rather than people getting into the store, buy their phones fast and have them set up their accounts at home (in a distributed and non-time critical fashion), they created huge waits at the store, and made the whole thing hinge on how well the iTunes store could hold up.
Hold up it did not. As of 4:30 Pacific, it is still in chaos, people are left with new phones that don’t work, old phones that have been turned into bricks, and iPods that are trashed.
Given that Apple was in charge of how many phones were shipped, they did know how many people were going to try and activate on the first day. It should have been possible for them to load test these features. Instead Apple now looks like fools during a very high profile event. From what I know of Steve Jobs, I am certain several people have already been reduced to radioactive slag.
Testing is not sexy, but look at what not doing the proper testing has done for Apple.
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..
“Pitfalls of Modern Software Engineering”: an update
One of the books I’m currently writing is Pitfalls of Modern Software Engineering, a greatly expanded and updated version of a book I published back in the 1990s. I’ve been posted new and revised pitfalls over at my Bruce F. Webster & Associates (bfwa.com) website. To make the pitfalls a bit easier to browse, I’ve now added a page to that website that lists all the pitfalls posted to date, with link to their individual entries. Just FYI. ..bruce..