CHAOS = BS

Anyone who has looked at software development methods, myself included, is probably familiar with the CHAOS report of The Standish Group. I have blogged before about Robert Glass's article that the numbers reported that group simply are not supported by other studies. I was happy to see that referenced on Herding Cats.

The effects of the data they report (189% cost overrun average) are negative for the IT industry. They are used to justify all means of odd process controls and contribute to a general excessive scepticism about the possibility of making a software project a success. The lack of context given for the data (actually, the data is kept secret) means that all of this is based on a very shaky quantitative foundation.

Having just finished "Fooled by Randomness", I am going to take another look at the Monte Carlo approach to estimation. I used it in a couple of cases to provide broad estimates for large projects, but all of the numbers came out quite low. I still the think the only responsible thing to do is to provide a range of estimates, especially when the nature of the work to be done is uncertain. And it usually is. The real benefit of the simulation approach, from the fooled by randomness perspective, is that they allow to take account of the black swans. If you are using a purely inductive approach, you can't account for things that have never happened. Like a 3 day power outage in your server room. Or system administrator that changes the name of your source control server and costs 10 person days of work. Or a new programmer that checks his whole c drive into the source code repository. Well, those 3 have actually happened to me, but they aren't the sort of thing I usually factor into my estimates, particularly when using the methods from "Planning Extreme Programming", which are purely based on yesterday's weather.

The real challenge here is estimating the shifting sands. Until you have a feel for the rate at which requirements change, you are only going to be able to estimate based upon what people thought they might want something they don't understand to do. Of course, if there is a reorganization in a business you are supporting, and there usually is at some point, the rate of change can shoot up. This is where the difference between methods really starts to kick in. If you are using a method that "embraces change" (the subtitle of the XP book), then you can leverage change to be the engine that carries the organization forward. If you try to keep the requirements frozen, you will be one of the projects reported when the Standish Group calls and says, "tell me about your failed projects".

Many Methods

Cognitive Dissonance development (CDD) - In any organization where there are two or more divergent beliefs on how software should be made. The tension between those beliefs, as it’s fought out in various meetings and individual decisions by players on both sides, defines the project more than any individual belief itself.
-Scott Berkun

I've been there...wondering whether it is better to give up the argument because the other person is so incredibly stubborn. And it would have been better for the actual product had I given up. Not because my idea was worse, but because trying to do it two ways at the same time was worse than any one way.

I've been on projects where people waste all of the time trying to pick a product. I now have the confidence to tell people that most products really are not that good. Particularly ones that are intended to make development easier. So many of these create frameworks that are more complicated than what one was trying to accomplish in the first place, but offer less flexibility.

I was on a project that was trying to replace an ArcView 3.1 data entry and analysis application with about 25k lines of custom scripts with a Java web application based on ArcIMS and ArcSDE. This was in 2001. With a primordial version of Netscape. When all ArcIMS did was push jpegs down the wire. Oh, and they wanted to host it at a remote site. Adding points in ArcIMS at the time was a serious challenge. Adding lines was nearly impossible. I quickly quit. The project kept growing until the first deployment was such a failure they had to hide the bodies.

Obviously a place where Agile would have made a big difference. "Architects" in the ivory tower of the CIO shop had decided that we must have web apps for everything. If they had just put the demo app in front of an actual user, the whole project could have been quickly canceled.

I was listening to Uncle Bob Martin's Agile Skypecast while mowing the lawn on Sunday. It's a must listen. Despite all of the BS and corporate maneuvering around the buzzword, agile has deep principles behind it. I suggest ditching the buzzword and sticking to the concepts.
Early and frequent delivery of working code. Daily customer feedback. Developer testing (I am still working on mastering that one.) And the big one: Embrace Change. Don't fight requirements volatility, leverage it. (of course the trick is keeping the requirements stable during the iteration...)

It is interesting how Scrum leaves a lot of these things out and is, as Bob says, more of a management process that doesn't have much to do with software.

My favorite part of the agile universe remains the XP planning game. Point budgets as a means of giving multiple customers a voice, realistic estimation feedback, and ever so slightly, possibly, a little wee smidgen of fun. We could all use that from time to time.

Anyway, Uncle Bob gives the principles a good run through, worth the time to listen to a podcast.

I never really liked cats...

...but this has pushed me over the edge. The "LOLCATS" madness will pass.

Bad code...are you 'aving a laugh?

A little bomb I defused today in an ASP application I am replacing...weirdness explanation at the end.

nextTuesday = ""
showTuesday = ""
gotTuesday = 0
todayDate = weekdayname(weekday(now()))
'response.Write(todayDate)
if todayDate = "Monday" then
holdNextTuesday = date
nextTuesday = formatdatetime(date,1)
' response.Write("got it")
else
j = 0
'do until gotTuesday = 1
do while showTuesday = ""
j = j + 1

if j > 10 then
response.write("ERROR: Infinate loop
" & j)
response.write(weekdayname(weekday(nextTuesday)))
response.end()
response.flush()
end if

nextTuesday = DateAdd("D",j,Date)
'response.Write(weekdayname(weekday(nextTuesday)))
if weekdayname(weekday(nextTuesday)) = "Monday" then
gotTuesday = 1
holdNextTuesday = nextTuesday
nextTuesday = formatdatetime(nextTuesday,1)
showTuesday = nextTuesday
end if
'response.write(nextTuesday)

loop
'nextTuesday = ""
end if

thisMeetingDate = holdNextTuesday
'response.write thisMeetingDate
previousMeetingDate = DateAdd("D",-7,thisMeetingDate)

----
The meeting date was moved from Tuesday to Monday and they didn't change the variable names. I have no explanation whatever for the "infinate loop" check. That one just kills me.

Biggest JRuby (Java) Lie

"Nearly impossible to crash runtime or VM" -From Nutter and Enebo's MountainWest RubyConf presentation.

I managed to do it on a daily basis for years, the simple recipe is to add WebLogic to the project.

This is not to take anything away from their achievement with 1.0. It's a Java application running nearly as fast as a c application. I am very curious to see if it's as compatible with horizontal scaling...

Many Lo-Fi Prototypes

I've been listening to the audiobook of 10 Faces of Innovation by Tom Kelley of IDEO. He has a great insight into something I sorta knew, but had never thought about why it was so.

The basic idea is that showing just one prototype to a customer is bad. This tends to force them into a binary/reactive decision, one that is often determined more by their relationship to the creator of the prototype than to the item itself. Given multiple items to evaluate, the attention turns more to the items, and more feedback can be gathered, since it won't be perceived as direct criticism.

The telling analogy Kelley provides is that of a husband that is told by his wife that she has purchased a new dress. She then tries it and asks how it looks. Of course, it is difficult for the husband to say anything negative, because the question is really about how she looks wearing that dress. However, given multiple options to consider, the husband is actually more free to give honest feedback.

Now, it can be expensive to buy multiple dresses, or build multiple prototypes. The answer then is to use lo-fi prototypes: whether it be pictures in a magazine or crude drawings. Still, the more prototypes that are created, the less pressure there is to get it right the first time, which is a crushing force against innovation.

Having heard his brother speak at a conference in 2006, I love what IDEO are doing. If didn't need to make quite so much money, and had any confidence in my abilities, I would like to work there...just to live at that creative level every day would make me so happy.

Another retro RSS reader.

A must for Neal Stephenson fans, the RSS telegraph gives you all of your feedy goodness in Morse code.

Saw the steampunk turntables on BoingBoing- might have to trade in the 1200s.


Steampunk...

Empowerment and Trust

I've had this in draft for a while, can't figure out what the point was, but I don't want to think about it anymore. I've seen so many people chafing about the enterprise IT shop at one of my clients...unfortunately only I can do is add another forlorn whine to the choir.

My friend sixty4bit recently blogged about some trust and power issues at a client we have both worked for. Their behavior is bureaucratic in the extreme, they run all projects through a slow and cantankerous review board for all of their technology selections. In the end, the review board exists because the organization does not trust software developers and does not want to empower them to make decisions. The end result is that they slow everyone down and drastically reduce the effectiveness of the organization. The overall atmosphere created is one of fear of anything new, where people stop asking to try new things, because it isn't worth the time to get them approved. In a lot of cases, you have to get approval just to try something.

Laughably, this client is attempting to move to agile development processes, which are certainly focused on empowering the people who are doing the work to make decisions (although that is more of a Lean idea), while continuing on the opposite track in terms of empowering individual projects to meet their customers' needs.

In reality, particular technical decisions about technology selection can be contentious, especially in regards to projects across the enterprise choosing incompatible technology stacks. There is also a need to coordinate purchases across projects to gain negotiation leverage. Even more important, although completely overlooked by these bozos is that the license terms for all software need to be read by actual lawyers. However, it's clear that the real issue here is one of trust and power, tied up with the fun of getting to decide how to spend other people's money.

I am working on a devious plan to: a) get them to trust me, b) keep them feeling powerful, and c) allow for innovation and progress. Reading "Influence: Science and Practice" by Robert Cialdini tonight. Maybe that will help with a and b.

$11M for uLocate

Pretty big round for uLocate. Famous for providing support for Flagr, the mobile version of MapQuest etc.

I tried to download the new Where (how much did that domain name cost?) app to my phone, but it's not supported as of yet...

Their mobile technology is sorta cool- going for the whole write once run anywhere thing for mobile apps with an xml style application definition. A location specific version of something like mFoundry. Of course, when they don't support your phone, it's a little harder to buy into that concept.

Anyway, XML as a programming language? Just because it worked sorta okay for HTML doesn't mean there aren't better ways to do it- especially when you are talking applications.

Mobile Platforms

For work purposes I am currently carrying two phones- a Blackberry and a Palm 650. I like both of these OSes, although the Palm OS does crash quite a bit. I've also been testing a couple of mobile GIS applications running on Windows Mobile 5. We're trying to figure out where to go next with it- RIM, Symbian, Linux (iPhone), etc.

While I like RIM and Palm OS, with a edge to RIM, Windows Mobile is completely unappealing to me. The main plus from a development standpoint is that it is relatively standard across devices. However, this is easily eclipsed by the usability, the memory consumption, and the way in which closing most programs doesn't close them- it just hides them. The stability varies pretty widely across devices, but it's about on the level of Palm OS.

I am still waiting for the mobile OS that implements virtual memory paging (with an SD card as the pagefile holder). It might be slower, but the RAM is so easily consumed in simple apps, it would enable a variety of applications that just don't work now. I know, you just have to wait a couple of years and it will all change, but right now it's a very tough decision if you want to figure out which mobile OS to develop on.

Now, some might say- why not just do mobile friendly web applications versus applications? For a lot of applications, you need more interactivity than the limited browsers on the phone provide. For others, the constant lag is the impediment. Overall, it's an area of potential, but limited to only the simplest applications today.

However, the mobile device is where some of the virtual machine technologies can really come to bear. In particular, Java Mobile Edition is pretty widely available, even if the apps look as out of place as they often do in Desktop OS land. So, you can do a Java app and get a reasonable percentage of phones to work, although they all seem to implement slightly different profiles.

Now we have the Apollo, Silverlight, JavaFX model of what are in reality enhanced web browsers that build UIs out of things other than HTML. JavaFX mobile is one picture of how things could go in that direction, where the environment could provide all of the basic phone functions, in addition to providing a decent programming environment for content delivery. Of course, I am not sure how much of that is really one thing, or if it's a set of technologies that Sun is lumping under one banner.

Anyway- let's say I have an opportunity to port one of these mobile GIS apps to a platform or OS- which way should I go?