Who knows what possessed my friend Scale This! to seize on this particular tweet of mine, immortalising it through the medium of ceramic mug?
And What Is Truth?
In the perceived software development wars between academic ideals and commercial pressures, the first casualty, according to the ingenious definition supplied by Alfred Tarski, is unlimited satisfaction.
My first CS tutor at university, in a 1976 introductory lecture, first stressed the need to make every program solve "in some sense" the maximum possible set of problems, before going on to say Hello World in FORTRAN. Contrast that with the philosophy behind some of today's popular industrial methodologies - Agile, Test and Behaviour Driven Development - where the stated goal is to write just the minimum amount of code satisfying strictly delineated requirements.
The trouble with the lean and sparse approach is just that, assuming we know what we're doing, we do tend to design complicated systems in a modular way, ideally using plug-in replaceable components. These components need to have readily discoverable characteristics, specifications, and interfaces; they should not be capable of surprising us. In an audit scheduling application, a control for selecting a date should never be constrained to use only future dates, on the justification that audits can't be scheduled for the past (and support for past dates would require extra coding effort in the control implementation).
Finding the happy medium can involve a certain degree of oscillation. In the early days of our company, I and others championed the idea of a Code Gallery, holding chunks of reusable Delphi; for example, utilities for date, string and other data types, or controls such as hierarchical combo boxes. For various reasons - including a span of years spent developing just a single app! - there was never a great deal in that gallery. Most of what there was, was never in fact shared with a second project.
Source control arrived, and one fine day when my back was turned, the Gallery disappeared! Absorbed whole into the repository of our flagship product. It was impossible to protest, as by then the Gallery had come to be seen as merely a mechanism allowing code sharing across projects, and this clearly wasn't happening. Personally I thought the reduced visibility of Gallery code, which was nonetheless applied across multiple disparate modules of that single app, to be an unfortunate mistake, effectively precluding any notion of testing other than the black-box kind. A more prominent Gallery, I felt, might have encouraged more unit testing, more component-level integration testing, and eventually perhaps (step 2: "?"), better modularity and re-usability (Profit!).
Departments, portfolios and personnel all change. Today we have an internal review group tasked to investigate matters like these. One new developer in particular has done much, using not only his ridiculously popular and now-famous dynamic slide shows, but more importantly his own experience of design methods, code review, sharing and reuse, to begin once again promoting awareness of our roles as both producers and consumers of each other's output. This is a good time for our department!