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).
Evolution
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!
I have tried to introduce shared Code Libraries at my new place also, but what I've found is that every problem tends to have that 20% that is slightly different so cannot just use the gallery code as a direct reference.
ReplyDeleteInstead the code is copied, pasted and tweaked. And of course, no-one does TDD or TAD anyway, so forming a branch of the gallery doesn't happen.
My point: I've never worked anywhere that actually churns out enough separate projects to make keeping a shared gallery worthwhile; usually by the time another project comes along things have moved on (example, .NET keeps adding stuff as part of its standard framework). I understand the ideal but only the fortunate can afford to pay for it.
Having said that I have my own personal "DMG" library - because this is "mine" I don't feel compelled to document, test or provide any guarantees like I would if it was to be shared. Is this selfish? Probably! Would it be up to your standard? Probably not!
Glad to see that you are finally in that position though - if only all companies had faith to invest like this.
I think this highlights one of the few downsides there are in the "better" or "modern" ways of working. Things like YAGNI and KISS are good but when it leads to a few partially implemented custom date controls littered throughout your code base, with no doubt a lot of repeated code and are hard to discover because your to ashamed to register it on the component palette, it does become an issue.
ReplyDeleteI think more awareness from during informal code reviews "you really should extract this code in to a reusable method" and the stuff you mentioned at the end will help. Although I do think the days of writing a "(near) complete" custom control when you only need a small bit of functionality are probably gone.