My thoughts on failure in software development.

What cause failure in a project from my point of view are a couple of small basic Issues.

  1. Sufficient Information.
  2. Leadership
  3. Talent

I know it seems like I’m over simplifying things, but I’m about the general case why projects tend to fail. Not because the company got sold, or one day you your systems collapse the day before ship or anything short of divine intervention.

1. Sufficient Information:

Providing proper documentation about the project is essential to the success, a lot of people are of the notion that the developer doesn’t need to everything about a project. While they don’t need to know everything it would be nice to know most of it. This means that the Analyst or PM must provide all work flows of how a user’s will be accessing and using the application. so that there are know gotcha’s in the end. I do not place most the blame on the Analyst or PM because the user might not at the time tell them everything. But that is there job… to quote Billy Hollis ” this is where prototyping with a rapid feedback loops is essential.”

2. Leadership:

There needs a to be a person providing the direction technical or non-technical direction, but someone with a vision of some sort. This is so that the project feels more than just that, making the people involved as part of something greater; giving them a sense of ownership in what there doing.

3. Talent:

There needs to be a person that pushes the envelope and set the bar. There something to be said about people who truly love what there doing, if you project is full of people that just want to be there 8 to 5 and just get there task done…well you gonna put out something that reflect 8 to 5 and just works, and feels like any other application.



In my previous post i was talking about retro fitting extreme programming into agile programming… well guess what its been already defined… its called… SCRUM

So what is Scrum development?
It’s a team based, project segmentation development pattern. So whats so new about it nothing really its just a mash up of old and new practices. The project gets split into small segments( or feature for you agile guys) and each team (like in extreme programming) works on a segment.

Since this is basically building developing a project out of small components. The smaller the component the faster you can build the system.

the reason i like this idea is because its an extensible development process.


  1. Control Chaos:]
  2. Wikipedia:

Retro Fitting Extreme Programming Into Agile development

What do i mean by Retro Fitting Extreme Programming Into Agile development?!?!???

Agile Development also known as Feature Driven Development, this is where you build a list of features and the order that they are to be implemented. This responsibility can be placed on the Software Architect or Senior developer.

Extreme Programming also known as Test Driven Development is where you build your test before you code. This responsibility usually is place and should be placed on the Developer and programmers at a slightly Lower level.

I don’t see a reason why these two styles (or methodology) should conflict. You can simply write a set of tests for a feature in your feature list. This should give FDD a bigger success rate.

ASP.Net Ajax lets be selective

What happend to the Client ScriptCallback feature of Asp.Net 2.0, Well nothing really happened to Asp.Net 2.0’s client call back…its there and MS (aka atlas) actually uses this in the back end. The reason why we don’t here about it is…it is a paint in the you know what! To actually get anything done….but there was less of a foot print on the page.

Right now we have a couple API’s for writing Ajax is

  1. MS Ajax.Net (aka Atlas)
  2. Anthem.Net
  3. Ajax.Net or Professional Ajax.Net

Out of all three has a smaller foot print on the page. The other two still simulate the full page life cycle using XmlHttpRequest and pushing most of the data back. Which means that most of the application written in using or writhing the actual javascript your self will be faster than using an API with all the over head.

What MS and Anthem do offer is that they are easy to use, and you do not have to dig into the specific and writing javascript. Just throw things in a UpdatePanel or AnthemPanel and all your post backs get translated to callbacks. This is still better than a full post because your screen doesn’t flicker…. but lets not get to the point that everything is done through XmlHttpRequest and we basically have gone back to the old problem.

Tips when not to Use Ajax… because the list of when to use it is actually longer…

  1. To hide objects don’t do a full callback just use javascript to set its style display to none, why do a full call back if all your doing is hiding something.
  2. If a callback is going to Redirect a user when it get back to the client, just do a post and redirect him or her from there because it gets annoying. If it has to go all the way to server just do a post and redirect or do a Server.transfer.
  3. Don’t do a call back if it take 30 sec to return, but if you must give the user a message so he or she knows your processing data.

Small pet-peeve of mine are all there API’s that say they are an Ajax library and there purely javascript….. YOU’RE A JAVASCRIPT API LIVE WITH IT!!!!

Script Callbacks in ASP.NET
MS ajax