Totally unrelated to software engineering topics (…at least until I can find a way to mix the two), here is a picture of my new bike!

In the past several months I’ve had the privilege of assisting with the technology direction for a key product. The one big takeaway from this is quite intertwined with the essential philosophy of “release early, release often.” By this I mean that it is ever so tempting to sit in a closed boardroom, void of your target customers or end users, and incorporate what you think your customers want.

So you can spend weeks and months conjuring up the ideal picture of your technology offering, only to discover that your customers are saying to you “that’s nice, but what I really want is X, Y and Z.” Fortunately, we’ve not ventured down that path. The risk you run is that your core product will end up being stretched and pulled in the direction that the business team deems necessary when really all you needed was a little customer feedback in the loop.

The conclusion then is clear - pick your core product(s) based on customer feedback and work and rework those concepts until you have a masterpiece.  What you will then have is a cornerstone product on which to add down the road. As the firm grows in its ability to handle the multiple directions, you’ll always have that flagship product to rely on. This, I suspect, would not be possible had the business team gone down that path of destruction where “nice-to-have” features become “requirements” and the scope creep issues start to grind the development team down to the point that you have a monstrous software project with no clear direction.

My advice to others in the critical stages of new product definition then is simple: hit a homerun with your core software pieces and put the less critical software features on the backburner for now. You can revisit those ideas down the road with the benefits of hindsight and customer input. Try this and I’m sure you will see that many of those “must haves” are indeed not necessary at all.

These days it seems that it would take very little for a would-be competitor to copy your web application and set up shop next door to you. In fact, taking a look at the massive duplication that is offered as a service across the internet, it isn’t a stretch to say that many entrepreneurs are more akin to “bangwagoneers” (I just made that word up right now, how do you like that?) than genuine inventors.

Since you have no control over whether your competitors will decide to copy your ideas, you can at least make it excessively difficult. Unfortunately, that also means more work and R&D upfront for your company as well.

My view is that if you are dealing with a less than mainstream domain, or a type of business that is not overly accessible to the general techie public, then you have a built-in advantage right off the bat.

Even if there are a million good developers out there who could build what you’ve built, the idea would never occur to them simply because they do not have access to the same domain. As an example, consider hospital integration software that allows multiple disparate healthcare facilities to exchange messages with each other. At its core, this is not rocket science. Rather, it is a lot of standard HL7 messaging and intermediary processing, which any developer familiar with XML, or other message structure, is easily able to replicate.

Now these million developers will just never have access to the particular situation that makes it necessary to build these tools, so if you were in the health care integration business you needn’t worry about them because they are never going to materialize as competitors.

So if you can gain a foothold in your selected domain, and that domain happens to be something other than mainstream internet, you want to branch out and cover as much of that domain as you can while sticking to your company’s development strategy. Each time you cover off another area within that domain the price to enter the game goes up for your competitors. Eventually, they’ll realize that you have too much coverage and hopefully you can continuously improve the software during the period.

It seems as though some people in the software world are quite okay with being “ethics-free” provided that the economic payoff is sufficiently enticing. But to the professional software engineer, you can find yourself in some situations which require careful thought.

I’m amazed and dumbfounded that people who call themselves engineers are so willing to turn a blind eye to circumstances which are, at best, flirting with the unethical. I’m reminded of the SDI (Strategic Defense Initiative) story from the Reagan administration in the early 1980s. In particular, this story is of great practical value to those of us who find ourselves involved in projects that we may not be fully comfortable with.

The SDI project was essentially a proposal for a computing platform to protect the United States from an inbound nuclear missile by way of various ground and space-based systems. In short, the project never left the ground and Dr. Parnas, a key panel member for the project, decided that the proposal was not feasible and could not possibly work as expected. The crucial lesson to obtain from this is that sometimes we are placed in a situation where the overriding ethical principle is far greater than the benefits of the technology itself.

A modern example, which seems to be an increasing point of debate in Canada, is the privatized health-care system, a-la-USA. In essence, if Mr. CEO can afford to pay for the best health care, then should health care providers be allowed to accomodate this? The ethical issue arises if you, as a software engineer, are asked to develop information systems that would run these private health care clinics. What would you do? 

It is my belief that the ethical choice is not to work on the project, regardless of whether the technology is feasible. In this case, the bigger picture reveals that the damage to the social equality of health care in Canada would be compromised if these ”HMOs” were allowed to exist in this country. It is true that one individual’s refusal to develop the technology would not specifically prevent this, which goes back to my original point: there are always people who will work on something based solely on potential for profit.

Software engineering is certainly maturing as a branch of engineering, but there are quite a few remnants of the old cowboy field that it once was. Chief among these obstacles is the view that software is a means to unparalleled corporate profits, rather than a means to achieving a greater social good. I don’t object to companies making decisions to improve their bottom-lines, that’s just good business sense. What I will always object to is companies pretending like that is the only real factor in a business decision. It’s not.   

For some reason, Software Engineering seems to be considered “programming” by many people. In fact, it is commonly understood by the general population that Software Engineering == Programming! I find it a little ridiculous that even today, years after real software engineers began emerging from the universities that people are still so ignorant to the differences.

Yes, some software engineers program as a matter of course. The inverse is not true. No matter how much programming you do, it will never make you a software engineer. So this really is flirting with the whole “is it a true engineering profession” debate that seems to be alive and well. Engineers design systems to work under given circumstances and need to be able to verify that their systems function as expected. They rely on conventional engineering tools like physical models, mathematical tools, simulations and testing. There is a clearly dividing line between the two distinct fields of engineering and programming, the only question remaining is how much time will pass and how many accidents will happen before industry becomes fully aware of the distinction.

A Scary Thought…How would you feel if the aircraft you are about to board had been “programmed” instead of “engineered to work” in all circumstances? Think about this the next time you consider intermingling engineers with programmers.

One sector that stands out in my mind as having some serious potential is electronic medical software. This really encompasses all things having to do with patient information and the digitization of such data. Sounds fairly obvious, but digging into this problem a bit further reveals enormous complexity.

Depending on how you look it, you could say that I’ve had the privilege of seeing some of the intricacies and challenges that are faced when designing new medical platforms. Clearly, information security is the number one concern in this space, but fortunately we have some standard ways of managing this and even borrowing proven ideas from online financial institutions.

The bigger problem when viewing Canada as a single medical entity is trying to understand how we will manage to streamline the healthcare process nationwide. Considering that each province/territory has its own method of handling patient registrations and billings, this presents a rather complex engineering challenge.

Compounding this issue is the need to interact generically with various other organizations and providers: pharmacies, hospitals, doctors’ offices, clinics, specialists, laboratories, etc.

How, then, are we to standardize these systems? Sure, each doctor’s office will eventually implement some particular breed of electronic medical records application which must meet certain basic requirements in terms of external integration capability, but this is a far cry from the ultimate goal of Canadian healthcare unity. Hospital operating systems are varied in terms of their capabilities and implementation successes.

But even working on the assumption that the big organizations manage to make it happen, is there anything in the works that will enable me, as a patient, to be able to walk into any healthcare facility in Canada and have my information instantly accessible to my provider? I’m not talking about a USB key with my profile on it, that seems like a short term hack rather than a scalable long-term solution.

What about self-directed healthcare? As a patient, if I had the right tools on the web, I would be better able to manage my own health and take some responsibility for it. The list of benefits to a unified healthcare system is endless, so my take on this is that there are numerous opportunities for technology companies to not only prosper but to play a critical role in improving the experience for patients.

Anyone who has been involved in a software project has followed some sort of development methodology. Software engineering faculties are expected to teach these formal approaches:

• Waterfall Model
• Iterative Model
• RUP

There are many others, but what is interesting is that a lot of the newer development teams are concentrating on Agile development methods, commonly called extreme programming methods, or XP.

It certainly appears that these agile methods are rapidly superceding the traditional methods for development, in part because of the shorterning development cycles. Considering that a Web 2.0 company can go from nothing to beta release in a matter of weeks, it seems that there is little use for a 12 or 18 month development cycle.

Does the widespread adoption of XP spell the end for RUP and friends? In fact, entire companies are being founded today on the principle of agile development. Critics of XP abound, here is just one such example.

I will concede this: it is certainly not worth the risk in fully adopting agile methods when dealing with systems that are responsible for people’s lives. Web companies pale in comparison to this burden. I am entirely of the opinion that developing flight control systems or nuclear reactor shutdown systems are not all suited to XP methods. After all, those big detailed requirements specifications are absolutely vital when a failure would mean the loss of life.

Therein lies the decisive factor which separates the two camps. If your image uploader on your new Web 2.0 site bombs out, the biggest problem you have is an unhappy, but alive, customer.

I, for one, am onside with agile methods provided that the software is being developed for the consumer space and is not tasked with safeguarding lives. So it seems that the traditional methods are to be considered fundamental for a reason: they are not going anywhere in our lifetime.

Most web developers are fortunate enough not to have to deal with this situation, but there are some business situations where the question arises:

Should the web application be hosted on an internal host or would it be better off hosted publicly?

On numerous occasions I have had this conversation with business stakeholders and I can relate to developers that there is one overriding factor in these discussions: many people today are apprehensive about allowing a thid party internet host provider to “own” their application and data.

Of course the argument can be made that any host is potentially vulnerable to compromise. However, I contend that few would disagree with the fact that hosting your application inside your company’s intranet is far more secure and less likely to result in data loss or any of the more common security breaches.

It has been my experience that hosting highly sensitive applications in house is worth the increased hardware, maintenance and administrative costs. There have been some companies that have bravely hosted sensitive data publicly, but many businesses will flat out refuse to go this path.

In my personal experiences helping business customers there are two distinct classes of applications that strongly suggest in-house hosting. If your application conforms to any of the below statements you would be taking an unnecessary risk in hosting on the public internet:

• Proprietary - if your application would reveal confidential company info or trade secrets or anything that provides a competitive advantage you may not want the public to see this.
• Medical - some companies have dared to host medical applications publicly. My own view is that this is somewhat reckless and exposes the company to possible liability. Confidentiality of medical information should be held in the highest regard. Host in-house wherever possible.

Now from a development standpoint, I would much prefer if every system was hosted publicly because it makes my job easier. When anything needs to be edited or if something should malfunction, it’s easy to login to the public host. Conversely, you would need to setup a more intricate system if you want this feature for inhouse servers (ie: remote desktop, VPN, etc).

The bottom line is that when a development/business team is working on anything that may be confidential, serious consideration should be given to the hosting model. If in doubt, host in house.

So now that Web 2.0 is in its full glory, everyone can see the benefits. No argument to be made there. But where is the next stop? I would suggest that web technology has but scratched the surface in two areas:

1. Enterprise
2. Mobile

If you’ve had experiences with current mobile technology, you are quite likely aware of its present limitations. The biggest problem is that the user interface for mobile applications is terrible. On a scale of 1 to 10, most applications rank a lowly 1 in terms of usability. Improvements in mobile technology is likely to make a big mark in the industry in the coming months.

The second wave of the web is most certainly going to be targeted at the enterprise customers. This concept has been called Enterprise 2.0 of late.

If you think about it though, many of the great features of Web 2.0 (think collaboration and user contributed content) would be absolutely fantastic if they could be ported to the enterprise.

In reality, this is probably more complex than it sounds. The reasons are many, however the biggest barrier to enterprise adoption will likely be the lack of integration with major corporate systems. This is a common and perfectly valid concern of corporate leaders. Afterall, they have invested millions in the deployment of systems like SAP, JD Edwards, PeopleSoft, etc, and these systems form the backbone of most corporations.

So one key factor in assisting corporate adoption of Web 2.0 technologies will be the ability to say in your pitch “…so-and-so system integrates seamlessly with your existing enterprise software…”

Without that it’s not happening, I’ve seen this time and time again. You can have the world’s greatest software application, but if it lives in its own little bubble there will be little incentive for big companies to buy it. Now, allow me to emphasize what corporations are saying right now: give me 2.0 that works with my business! Let’s face it, they want it but we aren’t building it. Business opportunities abound for those who are prepared.

Maclean’s has released their list of the best employers in Canada. The competitive process reduces a pool of thousands of companies to a mere 100. These, according to Maclean’s, are the best places to work in Canada.

Quick fact check: does your employer provide any of these cool things?

• 3 to 4 weeks of vacation, to start!
• generous salaries
• specialty coffee bars — my personal favorite
• job training in Paris…nice
• Caribbean cruise weekend - sign me up

See the full report here. These employers are right on the mark when it comes to recruiting top talent, especially in view of the impending labor shortage in this country. For an interesting read, check out this article detailing the talent woes that Ontario is facing.