Application Development is a Passion

Application Development has been a big part of my life for nearly 25 years. I started life more as a mechanic, from refrigerators to huge steam plants and journeyman Air Conditioning, I loved fixing things.

In the 70’s, I got an opportunity that allowed me to play on an early HP “personal” computer: two big cabinets and a monitor and keyboard; single user. It was an engineering computer and had an early “basic” language on it. I got hooked but could not afford to do anything with it till years later when the Commodore 64 was introduced.

From then on, I could not get away from it. I programmed early in the morning and late at night. I taught myself databases and assembler code (the language of the machine itself) and loved it. Eventually friends asked me to write programs for them and I hacked some things out and made a few bucks. But one thing I figured out early on, reading the manual and then hacking away till something worked would be fine for a while, but even then, there were people developing methodologies and processes to create better programs. Mostly, they worked on bigger programs for bigger companies but the principles were still the same.

So I made it my mission to learn all I could about how “the big boys” did it and bring the relevant amounts of that process and procedure to the work I was doing on small database projects. In the process, I developed a four-step process modeled from many of the things I was learning.
I spent hours on the old Compuserve forums learning from the best in the business. I sent my code out into the world to get criticized by them as well. That was tough, like sending your baby pictures out only to be told they aren’t that cute. Eventually, that changed, and I started getting more kudos than cuts, thankfully.

Several things I learned over the years:

• One, many people who program for a living don’t take the time to learn their craft and they typically have to fix and fix and re-fix problems.
• Two, the right amount of project management is required for every project; none is NEVER the right amount. You must go through the steps of defining what you are going to build, designing the way you are going to build it, and then building it according to the design, testing that all the way. For a small project, the time it takes is minimal. For a larger project, $100k to $500k, the process must be more rigorous. But it MUST be there even for projects you are just doing for fun yourself, or they will fail.
• Three, all businesses, even ones that seem exactly alike from the outside, are not alike. In fact, most businesses take on the personality of their leaders and it’s an amazing and fun thing to see.
• Four, communication is an art and not easy. The biggest impediment to communication is the illusion that it’s actually happening. If you could take a picture of the images in two people’s brain when they were talking you, you would, I’m sure, be amazed how different they were.This means that if you are trying to build software, pure ideas to start with, you have to question, and re-question what you thought you heard in order to get to the real picture. That is fun and results in very interesting discoveries.

  For instance, most companies have words they use frequently that mean entirely different things depending on the context but they don’t even recognize it. As a non-participant though, the words cause immediate confusion.

  Likely though, frequently inside the company, these same confusions occur but more subtly because people have learned to adjust. This can be a source of inefficiency and conflicts frequently with misunderstanding as to the source.

  As an analyst trying to create a model of the business a computer can use, one has to be very clear on definitions; computers are not good at situational meanings. Through this process I have heard more than once, “I know my business better today than I did before you started”. That is one of the greatest compliments I have or will receive.

• Lastly, for now, I frequently see application development that is done by modeling the individual views of each stakeholder and then trying to link those views together. In fact, there is always an underlying model for how the business runs, which then can be viewed through various lenses at various angles to show the right person the right information at the right time.

Miss this and the program is inevitably very complex, bulky, and not as effective. Get the underlying model correct, and all sorts of changes can occur for years without ever needing a rewrite.

I love teasing out the real underlying model of the business that serves all the stakeholders. It’s like looking in a fog at first and poking around till you find the substance. Application development is a passion for me.