Many times I’ve decided to document what is involved with getting my ISV and consulting business setup and running. This time, I’m doing it for my own sanity. A challenge all of us face is the sense of having done something useful over a period of time and then assessing only the present configuration/ Details are forgotten…then overwritten to the detriment of the business.

I’ve taken a short break to “Get my Systems Up to Date”, thinking that meant I needed to replace some hardware in the servers, update a few machines, etc. Well, that was a scope problem. I now realize that a critical fault is to leave that ‘Systems Inventory’ sheet blank.

But first, a little background because understanding the operational environment and how it came to be, is essential to understand what it now is.

I’ve always had ‘The Knack’ (Dilbert Readers will understand, as will my family. If not, here’s a link). It is not unheard of to be invited over for a wonderful dinner, an awesome dessert, satisfying conversation that you realize you ached for; then be introduced to a misbehaving device. You touch it, maybe even open the case, nudge a few things (tweak a few settings), close it up and the blasted thing works. This does not quell the reputation. Your workbench mysteriously fills with things rendered dysfunctional.

This is true during life as an employee as well. Over the course of my career, I found myself inheriting a problem, fixing it, then being asked to make the solution useful for something else. Some of these (literally) have been thrown over the wall. So it goes with software, databases, and spreadsheets. The reason is simple. To fix, there is a pattern. One must diagnose, then link to what has been learned (Learn, Assess, and Link). Learning is lifelong for many of us, or so we want to believe. First level assessors are ubiquitous – “This doesn’t work”, but the Diagnostician is uncommon (What failed?).

However, to come up with a remedy is to either have encountered the problem resolution before, or to invent a remedy novel to your known solution set. In my experience, that invention comes from prior knowledge coupled with the ability to see commonality. But linking the factoids of what has been learned to the problem at hand is rare and also requires the coincidence of appropriate knowledge. In other words: don’t expect the car mechanic to fix your asthma.

Over the course of time, Engineers begin to see how the same generic problem is encountered and generically solved – or should be solved. It’s the ‘Should Be’ that lands the Engineer in a Lair of creativity, such as the garage or the basement to make that generic solution. Among the generic solutions obvious to me, I choose those requiring software. I have hardware solutions to be worked out, but you have to start somewhere. To try more than one at a time as an individual puts one at the precipice of insanity. Too many and the individual will despair of accomplishing anything useful, so I picked.

Now here’s the fun part. How do you make that general solution, generally available? That takes The Engineer out of his comfort zone (see ‘The Knack’ again…) and into the realm of communicating. With People. The same people who brought The Unsolvable Problem to The Engineer in the first place. Some (most?) of us ‘Engineers’ have the notion that the operation of ‘things’ are obvious to all people at all times. I learned a long time ago that this is never the case. In fact, it is the major challenge to bring anything into the market, much less getting it to a point where your cube-mate can also use what has been created.

Today’s marketplace is bustling & noisy just as those of yesteryear. Even more so, because it is not local. The requirements and expectations of doing even one transaction in this marketplace: myriad. In order to manage, The Engineer, along with the collective lot of people hawking stuff on the internet bazaar, turn to systems to implement a process for the people. The systems allow you to access this marketplace and conform to expectations. When all systems are running, all considerations will be consistently met. The problem is that those considerations are incomplete and there are people.

The bottom line - It takes People. People need Processes, Processes need Systems. In the next post, I will outline my processes, then fill in the Systems and rationale to answer the question: “What do you really need to make and sell your software?”

No Comments