Monday, March 24, 2008

The Mature Software Industry, Corporate Specialization, p2

In driving down I-293 around the city of Manchester one night this weekend, I noticed some of the old factories across the river were lit up so you could see the machinery they contained. Those machines have probably been producing goods reliably for decades.

In my last post, ("Corporate Specialization") I used an analogy of power plants to describe how software engineering groups might someday fit into the corporate landscape.

I found myself thinking that a more precise analogy would be to liken software application development to... hardware application development.

When it comes down to it, hardware, software... the end user doesn't care. They're all just tools to get their real jobs done.

I remember seeing this when I was a kid. I recall observing that when the Atari 2600 has a cartridge inserted, and it's powered on, the hardware and software components were functionally indistinguishable. The complete system might as well be a dedicated-purpose hardware machine. It became an appliance.

Modern platforms don't really change that appliance effect to the end-user.

So, aside from operators, I'm sure these classic B&M manufacturers have technical people to maintain and manage their equipment. I'd be surprised to find out that they keep a full team of mechanical engineers on the staff, though. It seems to make sense that a mature software development industry will start to look much more like that over time.

Further, take a look at computer hardware. It's undergone some maturing over the past few decades too. There really aren't many companies that actually bake their own. I remember tinkering a bit with chips & solder. Then, I started building PC's from components. While my current desktop at home is still one of my own "Franken PC's", I think it's been over a year since I even cracked the case on it. I suspect that when I finally break down & replace the thing, it will be 100% Dell (or maybe Sony) [and Microsoft].

With respect to software engineering, never mind all that FUD we're hearing about IT getting sucked into business units. That's good for "operators" and "maintenance" types, who become analytics and process management in the new world order. I suspect the heavy lifting software engineering will eventually be done mostly by companies that specialize in it.

With that, it might be more educational to look at the histories-to-date of the industrial-mechanical and electrical engineering groups to see the future of the software engineering group.

I think this might be where MS & Google are really battling it out, long term. As the software industry continues to mature, the companies with the most proven, stable software components will end up with the market advantage when it comes to building "business factories" out of them for their clients. ...or maybe it will just be about the most matured development and engineering processes... or maybe both... ?

Corporate Specialization

There's an old adage: "Anything you can buy, you can produce yourself for less."

In our business, we're well aware that there are a few fundamentally flawed assumptions with that sentiment. Despite the barriers to entry and many other recurring costs, somehow the idea seems pervasive in the business world.

I started my career in a consulting shop that insisted it was a product company. Then I moved, through market forces, into products based companies. I stayed on board with some of them long enough to help shut out the lights and unplug the servers when the sales didn’t hit the marks. The other big problem I’ve seen with product shops was that it’s engineering group typically went through its own “release cycles”… once the product was released, my team was cut to the bone.

I've never been in a classic IT shop, per se, but I’ve definitely been on tangent IT-support projects within “product” oriented companies. In IT groups, I’ve often thought that companies might see IT projects as frills and overhead. At some level, I think the pervasive IT-alignment is a counter measure to that idea. Still, it seems IT projects are typically viewed as liability, rather than asset. When it comes time for the company to refocus on its core competencies, (which is inevitable in the ups & downs of business) IT projects are prime targets for cutbacks.

Since the “.COM bust”, in these types of companies, an engineer on the staff for just three years is often seen as a “long-timer”… but no one feels bad about that, since a lot of these companies fold in that time frame, as well.

After experiencing the product based companys' ups & downs, and seeing many colleagues who had already been through the IT shops, I’m convinced… the outsourced project / consulting route is really the wave of the future, even more than it has been in the past. It’s only a matter of time before business admits this necessity as well.

It makes sense... I wouldn’t figure on every company to own & operate their own power plant.

Why should they typically want their own software engineering group if they don't have to?

[Edit: See also Part 2 Here]

Saturday, March 15, 2008

The Wetware Bus

A colleague pointed me to this post about display size improving productivity.

It brings up a favorite topic of mine... With my current laptop (@1024x768), it's a bit of a pet-peeve.

It totally makes sense that tuning bandwidth to wetware improves productivity. Display real-estate is the front-side bus to wetware!

That's why I also like the Dvorak keyboard layout... Personally, I never achieved the level of proficiency with twenty +/- years of QWERTY (with formal training) that I have with the Dvorak layout over the past three years. Dvorak's a hard curve to get past, but I committed to it in the interest of tuning bandwidth (and maybe hoping to reduce RSI).