This Vinnie Mirchandani’s post lets me know of a recent two-part interview by Jason Pontin @ MIT Technology Review, with C++ inventor Bjarne Stroustrup. It’s very interesting as he discusses what’s wrong with most software code nowadays.
He makes some excellent points, going straight into the old time-to-market problem (here it is a post I wrote few months ago about it):
“[...] looking at “average” pieces of code can make me cry. [...] People reward developers who deliver software that is cheap, buggy, and first. That’s because people want fancy new gadgets now. [...] Significant improvements are needed, and they can only come gradually. They must come on a broad front; no single change is sufficient. [...]“.
It’s no mistery though that outsourcing is changing the way software is designed and coded, putting the software process in a new, geographically-distributed dimension: this might lead to a rise of interest in formal methods in software engineering, to reduce cultural mismatches and leave no room for ambiguities. An awesome - pdf – article by ETH‘s Bertrand Mayer @ IEEE Computer (January 2006, pp. 121-124) deals with the new reality of offshore outsourcing and the revolution in the industry.
A better education of software professionals is needed too, Stroustrup says. To this end, Michael Stal’s latest post about teaching architects is very interesting too.
Stroustrup talked about performance and hardware-software relationship too:
“Software developers have neutralized the astounding performance of modern computer hardware by adding layer upon layer of overelaborate [software] abstractions. We seem to have hit the limits of linear speedup for hardware, but in many cases, we could win a couple of orders of magnitude back from the software.“
The problem is not so easy to address, though: abstraction is an essential strategy to address complex problems, no doubt about it, and challenges to tackle in software development are getting harder and harder (Manfred Broy, “The ‘Grand Challenge’ in Informatics: engineering software-intensive systems” IEEE Computer, October 2006, pp. 72-80).
Thus, a lots of dimensions of variation improvement are out there, and the optimal trade off is still to be found; or maybe we shouldn’t be looking for a trade off at all, which is Stroustrup’s own point of view: a bit strong perhaps but…does it mean he’s wrong?
