Duane Gran’s log of thoughts

The old maxim of business that nothing happens until a sale is made holds true, but force of reality isn’t always enough to make truth ubiquitous. An impassioned counter claim from a technologist caught my attention. The point is simple enough and not so controversial. Business people need technologists to implement systems and solutions — that much is clear — but engineering fulfills one part of a total business endeavor.

I like what Guy Kawasaki said, in a list of his top ten lies from engineers:

My theory is that for version 1.0 of a product, the maximum allowable distance between the engineers and marketers is thirty feet.

Marketing and engineering have a torturous relationship. Marketers distill product capability into language suitable for customers and salespeople occasionally promise features or deliverables which frustrate engineers. On the flip side, engineers hedge about building new functionality and infrequently describe systems in useful terms for marketing.

Because sales and marketing have a potentially better grasp on the customer interest it only makes sense for their vision to direct software projects. Unfortunately the attention span of the marketplace is more fickle than most development cycles, so marketers often refine, revise or scrap a product design. This is supremely frustrating for engineers, but building the wrong system or finishing one that won’t sell has no value.

My point is that technologists need business people. They sell stuff and put lipstick on the pig for investors and a host of stake holders. As a career programmer turned IT manager, I’ll readily admit that customer focus is hard to maintain when building the guts of technology. Looking back on my entrepreneur days I see better my blind spots. Ignorance — not knowing or not caring — about the customer is common, but it is almost the rule among technologists.

As an illustration, I’m fond of Ron Garrett’s list of ten geek business myths. Several of the points could be summarized as “my ideas matter” whereas successful ventures are aligned with the goals of the customer.

I recently had lunch with a nineteen year old Computer Science major who requested my advice on many things software, but mostly about how to pursue a fulfilling career in IT. We had a wonderful discussion which concluded about how academic computing differs from what one finds in the industry. To summarize:

• An academic project is nearly always a fresh code base with few interactions, whereas most software development involves improving existing functionality or adjusting systems to comply with current business policy.
• The system requirements of academic projects are nearly always discrete and clear, whereas most software requirements are vague and it is the task of management and developers to translate requirements into a software design.
• An academic project is mostly evaluated by how well it matches specific requirements, whereas most software is judged by its correctness in addition to how well it scales and resists malicious or careless data inputs

In all fairness, when I studied Computer Science I had an instructor for a database design class who masterfully tested software. He would make students demonstrate in front of the class, except that he would interrupt the demo and ask you to enter in awkward data. Nearly everyone’s program crashed or corrupted data as a result. The lesson remains with me today and represents one of my most practical classroom experiences.

A British Computer Society essay identifies an even larger delta emerging over an increasing mode of developing software as a service.

If the gap between public knowledge and academic curriculum isn’t large enough, the gap between academia and industry practice is a gaping hole. While academic departments concentrate on developing new computer systems in an ideal organisational environment, a lot of industry has moved away from in-house development to a focus on delivering a service.

…

Interrupts, loops, algorithms, formal methods are not on the agenda. IT is about deploying resources to meet the information needs of its customers. Implementation, facility management, systems integration, service management, organisational change even environmental audit are the language of IT. These hardly feature on computer science courses.

If all of this hand wringing seems irrelevant, consider that Department of Labor forecasts, as summarized by Business Week, that “computer/math scientist jobs, which include programming, will increase by 40%, from 2.5 million in 2002 to 3.5 million in 2012.” Yet, “Colleges aren’t keeping up with demand. A 2005 survey of freshmen showed that just 1.1% planned to major in computer science, down from 3.7% in 2000.”

The good news may be, as the BCS essay illustrates, that software development is becoming ever more approachable to the masses. Many “good enough” programs are developed by amateurs which don’t justify the rigor of the CS curriculum, but the applications benefit immensely from being written by people fluent in the domain logic. If you have ever witnessed a programmer’s blank stare as you describe finance or metrical poetry you can appreciate why this transition is important and empowering.

The academic curriculum does an excellent job introducing students to computational task and theory, but more projects should be framed by someone outside of the discipline. Every CS graduate knows how to simulate the Towers of Hanoi but few have practical experience collaborating outside of the domain of math and science. Those who do possess a strategic advantage over their peers.

The good news for my young lunch companion is that the field is growing, but the bad news that the field is changing rapidly. Anyone over the past 40 years could say effectively the same thing, but I mean that a software developer must consider supporting and collaborating with stake holders who increasingly expect to build part of the software.

Who would have thought that Jim Cramer, of The Street, would be speaking today in Charlottesville. For a small community we seem to attract an interesting spectrum of speakers.

Cramer will speak at the Darden School of Business at 4pm and stand by tickets for the public will be available on a first come first serve basis at 2:15. He is known for his theatrical antics when talking about finance and investing. His qualifications are impeccable and he is a crowd pleaser for a certain crowd which gets excited about stocks and the like.

I prefer to work with my investment adviser on a more personal (and fiduciary) relationship, but you can’t deny that Cramer has a certain draw about him. He is responsible for enticing many people to make the plunge into investing and his advice is generally good. For example, he advises that you allot five hours per week to research every issue you hold — hence the reason I prefer to work with an adviser.

Others watch closely the results of his recommendations, but most would agree that his performance is a mixture of entertainment and information.