Bridging the Technical Generations

[article]
Summary:
Development like this could make richer long-term payoffs for investors, if not as something new, then as an advance on what went before. But this can't happen in companies where everybody is too new to meet their technical goals effectively. What could have been a scaffolding became a bubble of baseless IPOs that floated away and popped. Age discrimination is illegal, but it's non-competitive as well. Let's mix the generations from now on.

The Silicon Valley internet boom, for some of us who were around during the last start-up scramble, looked like deja vu but with a difference. There were the same youthful techies in the same one-product shops, working the same goldminer hours, with the same visions of innovation and bonanzas. Hair was shorter this time, and the bangles and wild color schemes were on the bodies rather than on the clothes. But the cult of the new was the same.


So were a lot of other things. Java was new, but not OOP programming structures-those came in with C++ in the 80s. Relational databases were slurped up practically unchanged; really big data still can't go to ground as Web-based content. Management and process strategies for high-tech development never change. Read the old masters like Gerry Weinberg, Tom DeMarco, Ed Yourden, Grady Booch, and you'll see today's companies are still rerunning the same messes and successes.

Software test is another technology the 90s didn't make obsolete. Testing techniques that worked for client-server didn't suddenly grow irrelevant when the new economy added an extra tier. However, the dot-comites didn't see this carryover. They wanted their QA to be new too. So, many of their test balloons floated off with only new people at the helm. There were many crashes, and many more preventable bumpy rides.

Let me remind you about new technology in the 80s. This was the beginning of mass-market software and hardware, a whole mini IT shop on a PC for each customer, a whole new world that the lore of the mainframe didn't fit. Our desktops now are measured in megabytes, but they were in kilobytes then, and stand-alone, until LANs started to connect them. PC developers were largely self-taught, as mainframe developers could never be, though many of the first PC programmers had professional mainframe experience. Test for the PC was greener, with little influx from mainframe QA groups; our shrink-wrap ways weren't what they were used to. ("Agile development" isn't new either!)

So we reinvented software test for the PC-and reinventing it then made sense. A menu-driven desktop app can be ad hoc tested cheaply and effectively. We made some attempts at automation, but the tools were crude, and we couldn't keep up with changing menus. As it turned out, our apps lived only two to three years before being coasted-too short a time for regression suites or documentation to be missed. Habitual test planning didn't happen till the late 80s, when OOP and its multiplex apps pushed us out of the oral tradition.

So when client-server came in to make things even bigger, we were ready, we just added networks to the complex OOP testing we already knew. Connectivity became an issue, but not too quickly. At first the UI and business logic stayed on the (sometimes-layered) desktop, while only the data migrated server-side. Multi-user and data refresh were new only to the desktop. Relational databases had handled both from mainframe days.

Thus, software test at the start of e-Business technology. The Net and the Web widened the world. Business logic and network functionality were modularized on an array of differently configured servers, leaving little on the desktop besides a browser-rendered UI and the odd applet. Load, connectivity, JVMs, and mean-time-to-failure acquired new importance for test, though maybe not as much for those of us who tested on WANs with DSP and wireless. But as with client-server, NewTech testing was a manageable next step from what we'd already done. Or so it could've been. Instead there was a disconnect. Internet development was spearheaded by a new generation, and circumstances of the boom made this territorial expansion look like a voyage to some other planet.

Entrepreneurs have been coming to Silicon Valley to make money by making hardware and/or software. Then for a while people were funded to come and make IPOs-high-tech credentials were optional. Investors stopped checking whether clients could run a high-tech development project, and it turned out that many of them couldn't. Zillions of dollars were wasted while these elephants labored and brought forth nothing but the proceeds on used office furnishings. Other Web-age management had technical backgrounds but little business experience. Many found themselves running companies without having worked for one. It's easy to miss something when you start at the top.

The lore of software QA was often missing from NewTech companies. There are courses in software test now, but how many hotshot developers would ever take one? They wouldn't take relational databases or other non-sexy programming classes either, but they know the old crafts exist, and if they need a programmer who can do them, they know what questions to ask. But they don't know the technical requirements of software test. Developers believe they can do test themselves, but they don't want to be bothered with details. What do testers do but sit behind the wheel and watch for orange lights?-while they design the engine.

So software test was ready for NewTech, but NewTech wasn't ready to hire it. Instead, they started software test all over again, with green people sitting in front of browsers, trying to ad-hoc their systems out the door. But what worked for tiny, isolated PC apps can't work on multi-megabyte engines. Many defects in Web-apps don't even surface in the UI, and the ones that do are usually coming from distant processes, where back-end testing could pinpoint them and save hours of developers' time. Companies that haven't failed may still be floundering without the QA experience they need. And with spending so tight now-more tight than it is wise-managers may fail because their customers won't accept a badly tested product.

But if we're no longer blinded by newness, maybe we're ready to see the real technical and financial superiority of software development for the Web. Desktop client-server companies still have market share, but they're hurting. They're supporting multiple patched versions in the field, and their designs are bundles of old code that disintegrate further with every resource-hungry rev. And their mergers may make things worse, as they try to get incompatible apps to work together. The browser-based separation of UI from back-end processes is much cheaper to maintain, since teams can rev and test individual modules without re-architecting everything.

Development like this could make richer long-term payoffs for investors, if not as something new, then as an advance on what went before. But this can't happen in companies where everybody is too new to meet their technical goals effectively. What could have been a scaffolding became a bubble of baseless IPOs that floated away and popped. Age discrimination is illegal, but it's non-competitive as well. Let's mix the generations from now on.

About the author

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.