Ones and Zeros

Engineers build things and analyze systems to be able to build new ones better.  Engineers apply science and scientific knowledge and methods to solve problems.  There are basically four key steps to doing engineering:

1. Determine what to build by taking the project goals and translating them into technical specifications and requirements.
2. Design the necessary elements of the project’s system to satisfy the specifications and requirements.
3. Build the system to meet the design.
4. Verify that what is built matches the projects specifications & requirements, and thus ultimately the project’s goals.

This, I think, is a general approach for all engineering disciplines.  In the software world we use various methods and tools to handle these steps including ticket tracking systems, source code tracking systems, and various design, development, and testing methodologies.

I usually like being an engineer.  For most people problems are an interruption to their work.  For me, problems are my work.  The way I look it it I get to figure out how to make people’s lives better, how to improve things.  And that’s a nice way to make a living.

(I’m aware of military and weapons engineering, clearly the above doesn’t apply to this kind of engineering!)

Most software people consider themselves either developers or perhaps programmers. I try to be an engineer. Some basic engineering principles are:

1. Each project should have a set of defined goals as it’s purpose. Ultimately, the success of the project is tied to how well it matches these goals.
2. Software should be replicatible and trackable. Source code control systems allow tracking of changes and regeneration of older versions.
3. Testing should be able to match the project’s features with the project’s goals or requirements.
4. A project should not use any more computing time and space resources than necessary to achieve those goals.
5. Projects should be documented at a architectural level and at a detailed level so that future software engineers will be able to takeover the project.

Practical realities of time, budget, and managerial pressures pull us away from on or more of these principles. I don’t live in a dream-world of engineering.  I’m in the same real world everyone else is with funding issues, project changes in midstream, and schedule overruns. But that shouldn’t keep us from remembering what the process is actually supposed to be and to work toward that process.

Microsoft is aiming high with Bing, they’re trying to unseat Google.  Or at least make them uncomfortable.  But based on my weblogs, there’s a long way to go.  I got my first reference from Bing this last week.  Virtually all the people coming to OnesAndZeros come from Google or from a non-search engine link.

So, welcome Bing!  Competition is good for us web users, and good for Google too.

Risk concerns the expected value of one or more results of one or more future events. Technically, the value of those results may be positive or negative. However, general usage tends focus only on potential harm that may arise from a future event, which may accrue either from incurring a cost (”downside risk”) or by failing to attain some benefit (”upside risk”) - Wikipedia

Flying small airplanes and driving a Citroen 2cv are considered risky by some people.   So sometimes people think my wife and I are risk-seekers.  In the past I’ve been an entrepreneur and my wife has her own business now too.  These too are sometimes considered risky endeavors.

But there’s actual risk: (probability of an accident) X  (the loss per accident).  Then there’s perceived risk, “those little airplanes are always crashing”, “small old cars will kill you in an accident”, and “large companies are always more secure”.

There are some risks that are larger in flying than driving: altitude for example.  Then some things more risky in driving too.  In flying I don’t have some yahoo on his or her cell phone at 70 mph just 6 feet away from me and drifting into my lane for example.  In the plane,  I’m much more in control of my own situation. If I avoid zooming too close to the ground and flying too slow, don’t fly in weather I’m not trained or equipped for, and make sure I have enough gas, then I’ve just avoided most of the accident causes!

Small cars are not always more dangerous: they can move out of the way more easily.  And recent economic news makes it clear that large companies aren’t secure.  Perceived risk is not real risk, it’s just not accurate.

Bruce Schneier has a great article pointing out that we systematically perceive risk incorrectly saying, “People have trouble estimating risks for anything not exactly like their normal situation.”  This psychology has also been studied (see “Stumbling on Happiness“).

There’s a lot written about mitigating risk.  This just how to avoid risky situations.  There are various ways to do that: sit at home and don’t do anything is one extreme.  But my wife and I handle risk in several ways: using training, and maintenance to prevent some of the types of risks. And where those won’t work, simply avoiding putting ourselves into that situation.  I.e drive the backroad instead of the highway in the 2cv.   Life is more than simply avoiding risk. We have decided it’s more risky to get to the end of our lives not having enjoyed them.  Or as my wife puts it very simply, “Life is for the living”.

But I’m still not keen on bungy jumping.