How do you recognize great software engineers

Meanwhile, the overall challenges of software engineering became more familiar and more entrenched. A decade after his 1975 intervention The Mythical Man-Month: Essays on Software Engineering, Fred Brooks lamented that little had changed. In response, he proposed incremental development, or prototyping. Today’s software development is iterative, and for good reason: Software wasn’t ever really akin to manufacturing and construction, where changes were difficult or impossible after initial implementation.

But, software was never not akin to manufacturing and construction, either. Almost 50 years after the NATO Science Committee conferences, some of its participants’ warnings still hold. “In the competitive rush to make available the latest techniques,” the ’68 report opines, “we strive to take great forward leaps across gulfs of unknown width and depth.” The same sentiment still holds today.

So, what happened? The personal-computer revolution, for one. In the 1960s and ’70s, computers were expensive and scarce. They were confined to research, in governmental, corporate, and industrial contexts. But with the rise of the microcomputer in the late 1970s, anyone could own, use, and program one.

This democratization of software development ignited the consumer and business-software revolution. But it also changed the stakes of software engineering. Developing Microsoft Excel or the back-office systems at American Airlines was hardly glamorous or fast-paced. A giant product like a spreadsheet or a reservation system was still something like a bridge or a building: It had to work right, especially since patches and revisions were expensive and required physical intervention. Such cases require an engineering approach, while trying one’s hand at a program for upload to the local BBS (or the modern app store) does not.

The informality of software development accelerated even more with the rise of the web, starting in the mid ‘90s and continuing through today. As software services moved to websites, smartphones, and the Cloud, two things happened.

First, the pressure to get things right the first time around was relieved, because updates and changes could be applied centrally, as in the mainframe era. Over time, the ease of rapid repair became an excuse for rapid development, and Brooks-style prototyping mutated into the constant software updates we experience today. Facebook has wisely retired its one-time internal-development philosophy, “move fast and break things,” but no business reliant on civil or structural engineering would ever have adopted such a motto in the first place.

And second, software became more isolated from the world, even as it became more predominant. Earlier computing systems were imbricated with other aspects of business, industry, government, and society. An automobile customer-management system has to integrate with dealers, suppliers, shippers, banks and lenders, regulators, legacy systems, and customers. But today’s software mostly stands alone. Instagram, a photo-sharing service valued at $35 billion last year, just uploads and downloads images between its servers and its app.