Software Development Moment of Clarity #2

kevinw@software-logistics.com (Kevin D. Wolf) — Thu, 23 Oct 2008 23:35:40 GMT

From George S. Patton

Good tactics can save even the worst strategy. Bad tactics will destroy even the best strategy.

Let's relate that to software:

Strategy = Architecture

Tactics = Programming

If you have a poor architecture, it can be made up for by great programmers, but if you have poor programmers implementing software on a great architecture results will probably still be poor.

-ec

Make Progress Every Day!

kevinw@software-logistics.com (Kevin D. Wolf) — Sun, 16 Apr 2006 13:00:45 GMT

I really like this quote from "Verizon" I think it would be a great tag line for my company but Verizon might not like it too much.

So what does it mean to make progress every day? On a software development effort progress can be measured in two distinct areas:

Progress building your software product
Progress adding features/functionality to that software that helps achieves the business goals.

Chances are your company wants to focus on the second of these two points, since they are not generally in the business of writing software for the sake of writing software. This doesn't however say that the first item is not important. Actually the efficient coder knows that building a solid foundation early on in the project will pay huge dividends once work begins on the actually functional requirements of the system.

Let's look at an analogy of Race Cars. The object of building a race car is to be able to go fast and complete/win races. However to do this there are a number of factors that contribute to the ability to go fast and complete/win the race. Going fast there really needs to combine performance, safety, measurement and control.

With most software development efforts, man-hours is the most significant expense in building a system, also time to market with respect to your competitors may also be an important factor. Therefore it seems obvious but the quicker you build your system, the better off you will be. Stating that however there is a real difference between speed and progress, if you are going real fast in the wrong direction or quickly building a system that is ripe with defects you may be going real fast but not making much progress.

To make real progress you need the right people, process and technology as well as management that understands that when development effort begins a significant effort will be in place to work on a foundation that may not have many visibile deliverables beyound the development team. Then once the visible deliverables start to be created, they will come at a very rapid pace and of a higher level of quality.

Either I've got my mind into building the race car (building the tools and the infrastructure) or racing the car (building the actual application). Working on these two different areas require a different mind-set and what I've found is if I spend a greater amount of time building an efficient race car, the faster it will go once I start the race. The down side here is that if the car was built to race on an off-road course, but it needs to be ran on a paved oval course, I've probably wasted a lot of time and won't have a car that will perform very well.

The Efficient Coder

Software Development Moment of Clarity #2

Make Progress Every Day!