I’d like to question some decisions made in tough economic times. When the economy gets soft many companies look at software projects for possible cuts. And, usually, they look at non-developers first. The thinking goes, “if I have software developers I can still develop applications. I like having dedicated architects, business analysts, project managers and QA staff, but I don’t really need them.” Depending on circumstances, that may prove not to be true.

Software developers provide the technical expertise to make applications run. But non-developers provide the higher level meta-intelligence about the processes being automated, the environment in which they will integrate, the best delivery method(s) for that environment and the necessary steps to ensure quality. Without them, teams may do a great job of delivering software that doesn’t solve problems or automates unnecessary processes. Predictable delivery and quality often get lost in the mix.

This is not to say developers don’t understand the value of testing, etc. But their role is highly technical and needs to be focused on turning technology into magic. Non-developers fill roles that are both technical and process: they focus on the connections between systems as well as human and business factors. In many cases, it is this “human intelligence” that makes the difference between cool software and applications that really meet business needs.

So I’m thinking companies don’t do themselves any favors by cutting the environmental, process and human aspects of a development team just to keep writing code. Often times, the worst trouble a development team can have is when they don’t understand the problem they are solving or how it relates to the rest of the business.

I attended a pre-proposal meeting last week, where a very large company was asking their vendors and other interested parties to comment on and ask questions about their software selection process. A group of five in-house managers had been assigned to create this process and the written specification. Now the five of them were present to attempt to explain and clarify the written document we all had in our hands. Just for a little context, the audience was composed primarily of high-level managers representing vendors or their supporting partners. Most of them seemed very strong in understanding the proposal from a financial and business implementation perspective.

Very early in the extended Question and Answer period, the issue of Cloud Computing came up. The preliminary spec was asking that the next generation of software be more “Cloud-like.” The audience was obviously looking for clarification. Remember this wasn’t a technical audience and even if it had been, the specification wasn’t really clear. The moderator of the panel asked if anyone else on the panel could explain Cloud Computing. No one volunteered. The audience laughed a bit. He smiled and then asked if anyone in the audience could give us a brief definition. Dead silence. He smiled a little wider and said, “does anyone here know anything about Cloud Computing?” That was it for me. I had to put my hand up.

I explained to the room that Cloud Computing is the idea of delivering common business applications like word processing, spreadsheets, contact management, and so forth online, accessed from a Web browser. The applications and the data are stored on servers that are somewhere on the Internet—hence the concept of the cloud. A person or a business should be able to see the computer world as a cloud, where they can pick and choose from the applications and services they need and want at the moment. I then went on to describe some of the current business models that were out there. I finished by talking about the current public offerings like Amazon, Google App Engine and Microsoft Azure. I was kind of proud of myself for trying to connect with them on a business level and from comments I later received, I think what I said was helpful. Unfortunately it didn’t really address the specification or a real need by this group. I didn’t realize that at first, but as I sat down, I started really wondering what the panel meant by making the software more Cloud-like.

The company already has a first generation version software product. How is that product delivered? As a Web application. Since one great example of providing software on-demand as a service is a Web application, the existing product is already on track as being “Cloud-like.” Even more strange, the ultimate users, a number of in-house business units, pay only for what they consume. This is very much according to the Cloud Computing “metered service” approach. Yet despite these two critical Cloud elements, they needed the next generation to be more Cloud-like?

So what was I missing? What part of the Cloud model were they talking about?

As the meeting continued on into the afternoon I kept getting little bits and pieces of information. I talked to 3 of the 5 panelists personally. I even took a 5-minute break to read the Wikipedia article on Cloud Computing and do a little Web research. I’ve been an active developer of Web Services and Web Applications for almost 6 years now, so I feel I’ve been a genuine contributor to the current Cloud infrastructure. Never-the-less, I left the meeting convinced that I hadn’t really understood what piece of the cloud they were missing.

A few days later, as I was reading my nth article on the Cloud, I stumbled across what part of the Cloud they were having a problem with.

At the meeting I had been told something by one of the panelists about what it takes for a business unit to adopt this software.

The company requires its business units to use software only from vendors who are on the “approved” list. This requires a time consuming evaluation period including things like face-to-face presentations and pre-scheduled software evaluations. Mind you, this is even for a Web application that is hosted off-site and uses a pay-as-you go model. When a business unit chooses a new vendor they need it to work with their own back-office accounting and their own business rules, so for each “roll-out,” the vendor, along with the business unit, have to customize for the business-unit’s back office. Just to be clear, every business unit has one or more of their own unique back office applications.

So here we have a metered, no-install Web application, but it can take over a year to adopt? It’s crazy really. I think the Cloud piece that they need next is the adoption piece.

Adoption is a key element of the Cloud. A Cloud offering needs to have the quickest and most efficient adoption possible. Any Cloud offering should aspire to little or no adoption time. This allows for the end user to turn on a dime and change to another software offering in the blink of an eye. If they can’t do that, then the software that they are using is bound to become stale.

To me, there are two problems to solve. First, the evaluation period needs to be cut down. Second, the back-office customization needs to be dragged into the Cloud age.

I would replace the current evaluation, with an iPhone App Store approach. When a vendor submits their software for review it goes through a set of automated tests to ensure compliance. If the software passes the tests, then after some small subjective evaluation (1 or 2 hours at the most) the software is placed into the hands of any and all business units.

Addressing the back-office seems pretty straight forward. Even though each business unit has its own back-office, there really is only so much information available from the vendor software, so to me, that’s where to start. Build a Web service into the vendor’s software that allows any and all back-offices to request and receive the information they need. To me, this would be a simple W3C compliant Web Service. This “channel” into the needed back-office information would be part of the specification, and to be considered compliant, each vendor would have to implement it.

The first migration would still be difficult, but a lot easier than it would have been. Just using a standard Web service makes things go smoother, speeding adoption and reducing errors. The real advantage though is that once this back-office connection has been written, the business unit can switch to another vendor in the blink of an eye.

With adoption effort, time and cost down to almost zero, a business unit could quickly change from one vendor’s software offering to another in the blink of an eye. This gives the business units a real advantage economically. It also is very helpful to the vendors as well. Vendors who give a good presentation and do good customization work aren’t always the ones with the best software offerings. With an inexpensive adoption model, vendors can focus their efforts on getting their software right and keeping it fresh into the future.

I was kind of skeptical of the Cloud model up until this experience. Not because it doesn’t make sense, just because it seems more of a buzzword than anything. Strangely enough though, when I was forced to look at this project from a Cloud perspective, I discovered something very useful. The Cloud means many things to many people, but when you look at something like software adoption, I think most would agree that zero-effort adoption is definitely the Cloud way.

Stout’s Bill Heitzeg is one of the driving forces behind a new software development study group. The concept: meet for one hour a week, bring your laptop, learn more about some hot topic in one hour than you would normally learn in weeks of unstructured, unmentored self-study.

Why does it work? Because the instructor for each one-hour session has already waded through the subject and can pick out the key, key, key things you need to understand. From there, you can make good progress on self-study because you already understand the fundamentals.

Imagine if our iPhone developer spent one hour guiding you through the maze that is iPhone development? If you have heard any of the horror stories about an iPhone submission, you have an idea about how much time that could save you. And that’s just the submission process!

So here is my question: if we figure out a way to make these live, interactive Webinars, would you be more interested? less interested?

The study group meets in Ann Arbor on Tuesdays during dinner hour. With a Webinar, we could probably do lunchtime study group sessions, saving commute time and time away from family. The downside is that the networking aspect isn’t nearly as prominent.

I’d be very curious to know your thoughts. Please post!

I have been working on a pet project lately.  I’ve been trying to write a genetic algorithm to solve a simple test problem.  In case you don’t remember genetic algorithms are search techniques designed to find problem solutions by mimicking natural occurrences from the field of evolutionary biology.  They are part of the larger studies of Biological Computing and Artificial Intelligence.  Long ago (and I’m not saying how long) I studied these and other algorithms as part of my graduate work in Computer Science.

The basic premise of a genetic algorithm is that you first initialize a search space with potential solutions each represented as some sort of string.  In biological speak each string would be a gene.  You then follow the space (i.e. the gene pool) through successive generations as some genes die, others strengthen and new genes are created through mutation and crossover.  This is all supposed to be the computer representation of natural selection in process.  With each generation, the “best” genes are selected and new, hopefully better, genes are created by mutating and combining the good genes.  The idea is that, if this process works so well for finding unique biological solutions, why wouldn’t it work for computer problems?

The problem I’m trying to solve is purely recreational—I’m trying to write an algorithm that will discover the correct solution to a Rubik’s Cube from a random start condition.  Some problems are so difficult that a particular approach won’t generate a viable solution.  I’m so blind on this project that I have no idea if I’ll succeed or not.  To my thinking, the search space – the pool of potential solutions – is relatively small.  And I’m starting with the knowledge of the exact result I want.  Generally it’s easier to write a search solution when you know in advance what you’re trying to find.  Have I succeeded?  I don’t know.  I’m spending quite a bit of time early on just figuring out how best to represent my genes and how to manipulate strings in C.

But this does take me back to my study of AI—or, as I like to call it, advanced algorithms.  Honestly I miss this kind of work.  In some ways the advent of the internet has moved computing ahead by orders of magnitude.  What were once disjoint point solutions are now part of the global connected computing landscape.  But, in others ways, the internet has actually moved us backward (my opinion).  This is especially true as pertains to unique or elegant algorithms.  For example, have you ever heard anyone wax rhapsodically about the elegance of HTML embedded in a classic ASP page?  No you haven’t - because it is anything but elegant.  In some cases it’s nearly illegible.

But I digress.  The point is I’m back at it; using what I remember about genetic algorithms to see if I can answer the age old question, “Can we really get all the red cubes on the same side?”  My hope is that success on this test project will open my mind to other ways I can use this technology to solve more meaningful problems and maybe find a solution that I didn’t already know before I started.  Wish me luck!

I walked passed my 11 year old son’s bedroom the other day and saw him kneeling down in front of his desk frantically typing away on his computer keyboard. Puzzled where his chair might be, I made a mental note to check on that when I had a moment. Almost two hours later, I returned only to find him still kneeling there. Curiosity getting the better of me, I went in and asked him what he was doing. He answered that he was finishing up Level 14 of a game. Only he wasn’t playing this game—he was designing it!

For a while now, my son has been spending a fair amount of time with a program called Scratch. Scratch is a visual programming language which strives to make programming more engaging and accessible to children, teens and others who wish to learn programming. The concept is quite simple. To create a game program the user snaps blocks together into stacks. Blocks are designed to fit together only when it makes syntactic sense. The result is a program that controls and mixes graphics, animation, music and sound. And then, to top it off, creations can be posted to the Web site so that others can sample or even collaborate on each others work.

Scratch also allows users to learn important computation concepts such as iteration, conditionals, variables, data types, events and processes. Besides being a lot of fun, many kids take it to the next level by moving on to actual text-based scripting languages. Several research papers have been written about this.

The program is built on top of the Squeak programming language and is an open source—but closed development—project spearheaded by a team of researchers at the MIT Media Lab.

Download Scratch.