Atomic Spin :: Elements of Software

Allan Kelly draws some interesting conclusions about Agile software development methods as related to forming business strategy. The impetus for his post was a piece in the MIT Sloan Review entitled “Should you build strategy like you build software?.”

From Allan’s “Make strategy like you make software?”:

...for companies which use a lot of technology software and strategy are increasingly converging. Ultimately your software is your strategy – so much so that I sometimes imagine software code as liquid strategy.

...many of the practices and techniques used in Agile software development can be applied to strategy formation and execution. McFarland focus on techniques such as small iterations, collective ownership, overlapping phases, direction changes (i.e. refactoring), organising around people not tools and abolishing big up front design.

It is not only software development where managers and companies have suffered from the Illusion of Control it occurs in strategy formation and planning. Strategy formation is an emergent process, in the same way that software design is emergent.

Recently, some of us at Atomic Object have been providing a small video that demonstrates any new features that we have implemented for our customers. It has been proven to be an effective technique when a customer has either been remote, busy, or traveling. Video demonstrations are also effective when the project is so small that setting up a weekly meeting with the customer is not plausible. However, even when the customer is readily available and is an active participant in the project, having these small video demonstrations can prove useful when they would like to show his/her coworkers a particular feature.

Surprisingly, the amount of effort you, as the developer, has to put forth actually decreases and customer satisfaction increases. A video demo is easy to make and it provides a “to the point” and a clear representation of the features. The customer can easily download and view the video in a matter of minutes. Because the features are being demonstrated and focused on; the customer can provide feedback quickly about what they like or dislike.

Most customers have other jobs and cannot focus solely on your project. Because of this, they may not have the time to download, launch, or try out new features. (Especially if it is 4:30 p.m. on Friday.) A small video demonstration makes life easy for the customer and it focuses them on what matters.

Another, not so obvious benefit, is how the video could quickly become viral and propagate to other end-users. For example, we had a small, tightly-scoped project that got a good deal of feedback in a short period of time, due to the amount of people that were able to view it. This enabled us to make tweaks and adjustments quickly without “burning up the budget.”

There are two tools that I know of that can do screen video capturing. Snapz Pro is my choice for MacOS X, it is easy to use and relatively inexpensive. I do not have any experience using screen capturing on Windows. However, when I did a google search, TechSmith popped up a few times and it appears to have some nice screen capture tools.

I was struck recently by how rarely software developers and project managers really analyze software development expenses.

Ever been part of a discussion about purchasing a third party library? Ever considered whether to automate a particular task? How often have you or anyone involved estimated how much money the library purchase or automation would save in comparison to the needed developer time?

Risk and reward are as intimately entwined in software development projects as they are in any other aspect of life. Higher risk goes with higher reward. Lower risk projects can expect lower returns. Tim Lister recently helped me better understand risk. He points out in Waltzing with Bears that the common goal of “eliminating” risk is not only infeasible, but undesirable. If you could truly take all risk out of a project you’d also be removing all potential reward. The risk in a software project represents everything you don’t know or can’t control. And it is these very elements that usually make the project interesting and potentially valuable.

Every human society has a similar expression about the nature of complexity. In English we say, “The devil is in the details”. In Sweden they say “Djävulen finns i alla detaljer”. Same idea, exactly. Customers of software development firms often underestimate, with a vengeance, the truth of this well-worn aphorism. Maybe that’s a necessary thing, as their vision needs to be unfettered by details in order to bring to life something new, innovative, and valuable. Software developers, on the other hand, are required to deal with the devilish details. Computers demand precise, detailed instructions. Software craftspeople must turn a customer’s vision into a working system, devilish details included.

Six years of working with people who have ideas for software projects they think will help them or their company make money has taught me a few things. Speaking in terms of my first career (as a professor), I feel the time is right to introduce a new course: Software Customer 101.

My hope is to improve the odds for Atomic Object customers and potential customers to have a successful project and make money from their great ideas.

The material in this course will be grouped into six major sections:

I. Inconvenient Truths

II. Doing Your Homework

III. Evaluating a Vendor

IV. Evaluating a Proposal

V. Making the Choice

VI. Running your Project

I was recently introduced to the writings of Dr. Gregory F. Treverton. Treverton is currently a RAND analyst and previously a high-ranking US intelligence official. In his book Reshaping National Intelligence for an Age of Information Treverton made the distinction between mysteries and puzzles. Dr. Treverton offers that puzzles are questions with answers – for instance, how many nuclear missiles a nation possesses. Mysteries are those questions for which there are no answers – for example, whether a particular country will take military action against another. Puzzles involve facts and data. Mysteries involve judgment, analysis, and interpretation.

This distinction between Mysteries and Puzzles encapsulates something essential about the nature of software.

Chad Fowler gave a talk at the last XP West Michigan meeting on November 28th. Chad shared his insights about career advancement and his mindset toward personal development, learning, and growth. He prompted us to think of ourselves, or our career, as a product. By treating our career as a product, we can start to put ourselves through a simple, iterative product development life cycle.

Everyone has heard of Offshoring. Clothing, automotive, and other mature industries have found that low wage centers overseas make good financial sense for certain types of work. In manufactured goods (particularly in mature industries), technological developments have allowed low skill, low wage workers to supplant highly skilled, highly paid workers in many tasks. Software is a bit different than manufactured goods in that it still requires skilled workers, but the draw of low wage centers certainly applies. And, technological development has simplified some aspects of programming and made common all types of computing technology. Cutting through all the hyperbole, Offshoring in IT/software is simply an indication that software is a maturing industry in a global economy. No longer are all software development projects cutting edge and comprised of the latest technologies. In a maturing industry, there are many needs that can, in effect, be met through commoditized services competing on price.

In comparison to Offshoring, Inshoring is not generally a readily known and used word. And where it is used it’s typically only as the yin to Offshoring’s yang, i.e. Inshoring is selecting a domestic vendor instead of a low cost overseas alternative.

The common understandings of Offshoring and Inshoring simply miss the full reality of what’s going on in the market. Domestic software companies are not recognizing the need to change the way they do software and do business. To survive and thrive, domestic software companies must truly understand the business model of Inshoring and embrace it.

We’re currently on our second IP-based phone system in the office. Our first IP phones were a set of Cisco phones purchased because of a potential software project involving custom data-driven applications using the web api these phones supported. It would’ve involved the kind of “cool” technologies you see in the Cisco tv ads with these phones. Color displays on some models would let you send photos, display maps, etc.

Chad Fowler spoke at XP West Michigan last night. He did a great presentation on career development and provided excellent perspective on offshoring from his experience in India. One very intriguing thing he addressed in career development was marketing the product that is you. He offered frank criticism of the “geek culture” that takes pride in seeing itself above things like marketing. His comments apply equally well to a software business as to an individual developer. He went so far as to say that if you have a great product or service, it is your moral obligation to tell the world about it. While doing things well will certainly draw attention, without actively communicating yourself to the market-at-large, far too few people will know about you. Ignoring marketing is, in effect, robbing others of the opportunity to save money or make money. You have a responsibility to tell the world about the innovation or great experience you can provide. Recently, we (Atomic Object) have been discussing truly developing our strategy to communicate the benefits we have to offer to the business world. Given Chad’s comments, allow us to offer our apologies to you, world, for not better communicating the insanely great things we do in software before now. Forgive us.