Monday, June 18, 2018

The Art of Humor


A friend consulting with me on an Data Warehouse development effort (Lee Laniear) once told me an excellent metaphor that explains the three types of software development projects.

You are like an archer with a quiver full of arrows. In the first type of project, your user places the target in the distance, you grab and load your straightest arrow from your quiver, you draw back the bowstring, take aim, and you give it your best shot. The objective, of course, is to hit the bullseye. You may hit or you may miss, and certainly the aim is more difficult with increasing distance to the target or with increasing crosswinds. But the main point is that you can see where you want to go.

In the second kind of project, you are still the archer, but the user runs back and forth fifty yards away carrying the target. The objective, of course, is to hit the bullseye (not the client). He may stop, run one way, then suddenly stop and run another. He may stand still for brief periods of time, and then without warning start running around again. You grab your straightest arrow from your quiver, you draw back the bowstring, and you aim where you think the target is going to be by the time your arrow reaches it. Your success depends to a great extent on your historical observations of how the user changes his mind. And your self-control to aim safely for the target and not allow your emotions to divert your attention toward more animated ends.

In the third kind of project, you grab your straightest arrow from your quiver, you draw back the bowstring, and then leaning backward, you shoot your arrow straight up into the air. The object is to get the user, carrying the target on his head, to position himself directly underneath the falling arrow.

Successful project managers have an ability to separate themselves from their immediate feelings about the folks providing them with work. They need to be able to understand a larger picture of how others view their world, have a sunny disposition, and cultivate a fair amount of self-effacing graceful humor.


Thursday, May 17, 2018

Artful Versions


When you focus on modular resilience, one item that helps a great deal is to pay attention to versioning. Version numbers are of use not only for change management but for testing and customer support as well. Apps developed with Microsoft tools keep their version numbers in a config file. You should standardize on a common meaning for the four subparts of version numbers.

Upgrades that produce a system that is incompatible with a prior release should increment the "major" version number. Upgrades that retain compatibility but that add significant functionality, should upgrade the "minor" version number. Bug fixes that get packaged into a distribution should increment the "release" version number. Finally the developers should increment the fourth component, the "build" number, with every compilation.

I like to present versions to the customer as major dot minor, for example this is versions 2.4 of the software. This version should display in a welcome pop-up and in the title bar of the main screen of your application. But for purpose of technical support I like to display (in a pop-up "About" box) something like version 2.4.3 build 118. Of course all of the version components are retrievable using the system reflection class.

Another helpful trick is to include a parallel matching version number within the backing database. When the client begins to run your software, make sure the version number in the data is compatible with the number in your software.

You should also version all of the modules within your software in a similar fashion. Although the component module versions aren't typically presented to the end user, reflect them to a called module (for debugging purposes) so that the called class can display the version of the invoker whenever it throws an error.

Sometimes it may seem superfluous, but it only takes about 30 seconds to update a version number, and with multiple developers on a project you will find that having this tracking available is invaluable.


Friday, April 13, 2018

Artfully Clean


Imagine buying a house and then never doing the laundry, vacuuming, taking out the trash, or washing the dishes. You just let stuff pile up until you run out of space and then you throw your up hands and go “oh, it must be time for a new house.” Sounds ludicrous eh?

In a highly competitive development environment though you build tables and files and directory folders, develop software, test a bit, and away you go. You patch up the bugs, optimize the queries, add a handful of indices, and you’re flying.

After a couple years though people are wondering why things take so long. Unsurprisingly the typical reason is a failure to archive and then remove the old data. Nobody is taking out the trash! Data retention and archival policies never get baked into the original specifications as the sponsors seldom see any immediate competitive value from them. Eventually however a clean system becomes less of a luxury and more a necessity. Folks start to notice the pile of dirty dishes.

The effort required to retrofit for cleanliness is about the same as the effort for planning for this up front. Strictly operationally however it is better to delay this expenditure until a system becomes a mess as you will then have a better understanding of the corners with the most fuzzballs.