What Others Are Saying About Software - 12/19/2008

Making Agile Stick
Another great post from the Dark Side. It boils down to value and working software. David makes the case that it is not an IT 'thing', it is a business 'thing'. And from a business-oriented developer, Bravo.

Estimation Is Not For Accountability (It’s For Visibility)
Max takes a strong stand for real reason for estimates. Interesting read for sure, but I wonder how Max squares his view with those who do Agile training? You hear the word "commitment" a lot from Agile consultants when referring to an iteration. Maybe it's a way to get their foot in the funding procurement door to pay their own consultant fees?

Hardware is Cheap, Programmers are Expensive
Nothing earth-shattering from Mr. Coding Horror. But I like to keep track of these posts, if only for my own benefit when debating my pre-optimization brethren.

KC Day of .NET Presentation

I gave a presentation at the KC Day of .NET today. If you attended my session, thank you!

Here is the slide deck and demo source code. It's located on Live Skydrive. You don't need to login to download, just select the file, and you should see a download link on the upper left.

I added NCover to the build file (we didn't have time during the presentation). So check out the html report in the artifacts directory.

If you don't mind, please leave me feedback on my presentation by commenting on this post.

Download Materials

I will be blogging on this topic and more in the near future. If you don't use a blog reader, I offer email notifications. Look right. --->

What Others Are Saying About Software - 12/3/2008

3 differences between 'Small Business' and 'Enterprise'
Someone is obviously battling some serious corporate bureaucracy and his frustration shows. But he does make some interesting observations.

The Wisdom Of Insecurity
Wisdom is sometimes the result of not knowing and the humility needed to learn from it.

How Hard Could It Be?: My Style of Servant Leadership
A few managers get it. Management is not the art of managing, it's the art of getting the hell out of the way.

How I Did I Get Started in Software Development?

It was a while ago, but Rob tagged me with this topic. Here goes:

How old were you when you started programming?
I guess my first actual coding took place on some old 8086 machines in my high school "computer" class. These machines did not have hard drives, so we had to boot to DOS via floppy every class period.

What was your first language?
BASIC on the previously mentioned machines.

What was the first real program you wrote?
A CRM package for a manufacturing company written in ASP 3.0 and SQL Server 7.

If you knew then what you know now, would you have started programming?
Most likely. You never know what will happen if you make different decisions. But all things equal, programming has offered me many opportunities.

If there is one thing you learned along the way that you would tell new developers, what would it be?
Always understand who writes your paycheck and ask yourself before every design decision: Does this provide value to our client? If it doesn't, then you should be asking questions of your team, project manager, architect, and even CIO if necessary. Most software development problems can be traced back to a point where the interests of the client and the efforts of the developers diverge.

What's the most fun you've ever had ... programming?
Watching my newly developed code run in a production environment, helping to solve business problems. That probably seems like a weak answer on a software development blog. But true to my blog title, it's the business result that matters, not something like a new language feature in C# 3.0.

On Software Development Methodologies

Greetings!

For those of you still subscribed to my blog feed, thanks for being patient. I just wanted to send a note to everyone to let you know that I'm still here and planning some specific blog topics for the near future. The emphasis for my next few posts will likely be methodology and issues related to team software development.

In the mean while, here is a favorite tech quote of mine from Andrew Hunt and David Thomas in The Pragmatic Programmer.

"No matter how well thought out it is, and regardless of which 'best practices' it includes, no method can replace thinking."

Job Change

Just to let folks know, I changed jobs this spring. The bank has been good experience for me as a developer, but I wanted to take my career a different direction. I took a position with a "mature" web start-up company closer to home.


My family has also grown by one, and that prompted a change to make my commute shorter.


I've been away from the blog for a while, but I do plan to get to some regular posting soon.

New Feed

I'm redirecting my feed to Feedburner.com. Please subscribe here:
http://feeds.feedburner.com/BusinessOrientedDevelopment

More content to come soon!

Ice Storms, Power Companies, and Project Estimation

Rob, a coworker of mine tagged me to come up with an example and confirmation of Agile development principles in real life.

To be fair to the business world outside of software development, most of the Agile software principles existed in the "real world" in various forms long before they were expounded by Agile proponents. But it's nice when you do observe the real world confirming an agile principle you have worked to implement in a team software environment.

Recently, a massive ice storm knocked out power to a large portion of the mid-west. The resulting damage in my community caused power outages to over 50% of homes and businesses. If you have ever lost power for an extended time period in sub-freezing temperatures, you understand the importance of electric power for the necessities of life. And when that power is lost for multiple days, it becomes a really big deal.

Even though the situation was not humorous, I had to laugh out loud when I heard the power company's estimate for restoring power in our area: "We hope to restore power to this area in 2 to 10 days."

It wasn't a mocking laugh or a laugh of ridicule. I laughed at the brutal honesty of the project estimation. I laughed at some of my past software projects where we probably knew less about our project requirements than the power company, but gave a more feature-rigid and date-rigid estimate.

Every subsequent morning, the power company was on the radio giving their revised project estimates. 2 to 10 days became 6 to 8 days, the next morning it became 4 to 5 days, and the morning after it became 2 days. Since it was impossible to really know on the first day the extent of the work to be performed, the power company didn't provide a wild guess. They effectively worked in daily iterations, revising their estimate as they worked. Since electric power is so critical during cold weather, they didn't have the option to guess on day one, and find out 4 days later that it would take longer than expected. When it comes to electric power, there isn't any room for salesmanship, PR spin, or blatant bluffing.

Agile software development allows us to take the same measure-by-doing approach. Instead of spending large amounts of time designing and estimating at the beginning of a project (which often ends up being mostly a guess anyway), we can start working in short iterations and revising estimates as we progress. By the second or third iteration, there is enough real-world data to chart out a reasonable projection of when the whole project will be completed.

So, can the software world learn something from a utility company? Yes. Estimate by doing. And if it is important, there is no room for guessing, bluffing, or wishful thinking.