Xp - Extreme Programming: When it shouldn't be used

One of the premises of extreme programming is that you use it when working on new software with rapidly changing requirements.

Anyone who has ever done development understands the chaos that changing requirements brings. But if you actually plan to live in an environment of rapidly changing requirements, you might want to reconsider your job.

Think about that type of mentality in other professions. Can you imagine building skyscrapers to changing specifications? Or a car? Or the parts of a movie (its a cartoon, no, it's claymation, no, it is a drama)?

I actually worked on a mansion once in the construction trade that was "cost plus", meaning that the specifications could change at any time. And they did, all the time. And at the end of the project they got a house that cost 3 times as much as the one next door even though it was comparable and it is structurally flawed and the foundation is unstable.

The fact is that stupidity and chaos is not a modern invention, it has been around since the beginning of time. To some extent waste is a byproduct is experimentation and is essential, but not everything in life should be an experiment when there are ample procedures that bring positive, proven results.

Think about what rapidly changing requirements means. It means, on an extreme level, that you don't know what you are building. It is one thing to allow for requirement flexibility on minor things, for instance allowing that the colors on a page might end up being blue or green. It is another to say I might be building a stock trading application or a property management application, but "I'm not really sure".

It is true that every product has revisions, but that is okay. It is okay to make accounting software that exports to a new format. It is okay to have accounting software that adds a new tax form. These are incremental updates, not huge architectural changes. It is not okay to start work on accounting software without having a solid idea of what the first product is going to be. Even if the client is willing to pay you cost-plus, you will likely end up with egg on your face.

A project manager really needs to have the guts to say that if the project requirements are not possible to nail down to a large degree, they won't work on the project.

A company hiring an IT team need to understand that if they don't know what they are trying to build in specific detail, they shouldn't even start.

Software without bugs: developers tell me it is impossible

Recently I was speaking to a developer who was astounded mentioned a site I had built, a 120 page website, all dynamic (database driven), and there were no bugs in it.

For most developers, that is one of the craziest things they have ever heard in their lives. After all, they are brilliant, and their project managers (if they have them) work 60-80 hours a week, so if they can't do it, nobody else can.

The application I worked on was not trivial, it supports significant functionality for a company that is the largest in the world in its market, and they had over 1000 employees at their height.

I have consulted for many companies over the years, and one thing that stands out to me most is that the success or failure of any project seems to hinge on the skillset of the project manager (and not the amount of hours they put into their jobs).

Agile methodologies and Extreme programming seem to go in the wrong direction in terms of solving the problem of creating software that arrives on time and without bugs. Adaptability is not the key to success in a programming project, but rather understanding of the problem at hand. Sometimes it requires attention to thousands (or tens of thousands) of details, but for people properly trained in simple techniques, even the most difficult projects can be successful, without bugs, and on time.

The truth about software development is that it shares a lot with building, but formal processes have been in place in the construction trade (like drawing proper blueprints) for a long time that are not in place for the software industry. In fact, the proliferation of tools and methodologies rapidly outpaces anyone's ability to even keep up with them.

For now, there will continue to be billions of dollars wasted in failed IT projects each year, but someday the dust willsettle and certain practices that work best will dominate.

Micosoft vs Linux

Last year I was speaking with an IT manager and we discussed the question of our time: Microsoft vs. Linux

When he asked which camp I was in, I said that any person involved with Microsoft technologies needed to be very careful.

He said that was very interesting because stockholders tend to approve of Microsoft product rollouts at companies while IT managers are often reluctant.

The argument between which of the two technologies to use has two parts. Many people think that cost is the big issue, and ultimately that is the case, but the argument is best broken down into two parts: functionality and risk.

Functionally, you can accomplish anything that matters in the real world without a Microsoft product. For instance, if I am building web applications, I can use Cold Fusion, PHP, or Java (among others) as easily as ASP. They all accomplish the exact same thing. If I am building a desktop application, I can use Delphi or Java, among other environments, rather than Visual Basic or C++. If I need a web server, I can use Apache rather than IIS. If I need mail services I can use sendmail, postfix, Lotus Domino, or qmail rather than Exchange. And so on for every important type ofsoftware in use today.

So if you can accomplish every task without Microsoft products that you can with them, which should you use? The answer is it depends on the skillset of the people you have hired. Unless you are weighing other factors, it usually doesn't makesense to spend 6-12 months retraining employees to use a competitive technology when they already know one. Think about it, if your entry level programmer is making 50K or so, and you have a couple of them and want to retrain them from ASP toPHP, 100K of lost productivity probably isn't worth the benefit of avoiding a few thousand dollars of Microsoft server licensing costs.

The other important factor in determining whether or not to use Microsoft products is risk. A few years ago when Office 97was current, I could get it for $30.00 on eBay. Currently, because of an increase in sales price, the cheapest I can get Office XP is $175 on eBay. And Office 2003 costs $499 on Microsoft's site. For 99% of users out there, the features that they use have not changed in 8 years. Most end users do some basic Word processing, some basic Powerpoints, but they pay infinitely more to do those same tasks because competitors have been squeezed out of the market and you have to upgrade for "compatibility" with other users.

Common practices of Microsoft include frequent updates that break compatibility with competing products, participating in softwarepiracy policing and promising not to prosecute the accused if they promise to take competing products off of their computers,bogus research findings, and even paying for the sabatoge of competitor technology by inside employees in some cases (sounds like a movie but fact is sometimes more surprising than fiction).

At the end of the day, the risk that exists is that a company invests millions of dollars into developing a software infrastructurethat costs a fortune to maintain because of things like the old operating system is no longer being supported and large upgrade fees since the competitors are gone. In contrast, a Perl application written 10 years ago that supports an entire enterprise can be ported to a new computer within hours for very little platform cost.

As an experienced developer, I understand I can give exceptions to the trends outlined above, but overall they are valid issues and ones that individuals with significant and broad management and development experience will recognize.

Degan Kettles
President
Enterprise Consulting Group
http://www.enterpriseconsultinggroup.us

Delta Air Lines - Find airline tickets, manage your SkyMiles account, or check flight schedules

Delta Air Lines - Find airline tickets, manage your SkyMiles account, or check flight schedules

Delta is a huge disappointment today. After driving like a madman through an unexpected snowstorm, I try to get my boarding pass for a flight which didn't even board until 45 minutes after I was at the airport, and they gave me the run around until they started boarding and said they couldn't get me a boarding pass then. It turns out they had oversold my flight, and they had no flights available the rest of the day. Their website doesn't come up today and their 800 number has given a busy signal all day long. All the while I miss out on a huge business meeting for which many people were flying in. All I got was an "I can't do anything" from Delta ticketing employees. The worst part is knowing that I was there in plenty of time to get on the flight that I paid for and I couldn't get on it.

Degan Kettles
President
Enterprise Consulting Group
http://www.enterpriseconsultinggroup.us