This is a companion piece to the article It's All About Support published this week
There is an issue that came to my mind recently when thinking about how long one has to support items after they have been surpassed or deprecated, and that is the issue of Education and Research.
Education
"He who can, does. He who cannot, teaches" [1]
[Bernard Shaw (1856–1950), Maxims for Revolutionists, Man and Superman, 1903.]
"Those that cannot be trusted to either, are management"
[Mark Keating, It's All About Education and Research, Shadowcat Systems Blog, 15 May 2009][2]
How do we keep upto date with our education in a fast-paced development strategy? There is certainly good reason to keep oneself abreast of any recent changes if one is an educator, in fact it should be an almost absolute requirement. But what of those who have been educated? How much responsibility does the community have, or to be clearer, how much should we assume in keeping the education of our progression as positive an experience as possible? And how do we do that?[4]
I guess my main issue is along the lines of the support. If we are assuming an eighteen-month to two-year development strategy, with an 'n' amount of changes that are being introduced, refactored, deprecated or deleted completely, we have to assume a slightly longer period for this to be part of an educational system. And we should assume it is part of an educational system. At this point there are training courses et al., but one should always strive to introduce more formal education in any large subject. As one does one should also assume that there is going to be a continuum of development stages, so unsupported leapes or changes can foul this system as there would be little chance of keeping all parts of the educational system at the same innovative position.
Research
Books
This issue also ties into our research concerns. When one is producing a book on a computer subject there is the necessary temptation to make it as upto date as possible. In fact the real truth is you want it to herald. the next evolutionary step of the development process (unless it is a manual :) ).
That presents us with a possible issue...
Say the step you herald, the changes you desire to make, are so unworkable in practice that they are removed at the next stage? Or worse, say they are so good there is a million hungry developers screaming to make changes and add features? By the time your book is produced it is almost going to be obsolete.[5]
Documentation
This isn't really an issue in regards to documentation...
Wait a second and let me rewind that...(make little rewind voice sounds in your head)
This shouldn't be an issue that affects documentation. But in regards to that, some docs take a long time to be updated and revised. There is also the matter of introductory documents, easter eggs/advent calendars and the other trappings of projects and communities that end up on wiki pages and strewn around the blogsphere. What is the strategy for keeping them sync'd. I have often noted that a particular 'newby' to a project will start by updating a wiki tutorial, or an advent calendar freebie because the docs do not cover deprecated items. The whole issue of updating old blogs and forums is huge. In any formal strategy these should be considered as well. If one is consolidating an effort an attempt to recognise all the issues is probably a valid approach.
This effort make seem like a Herculean task, but it need not be. It would be difficult to perform in a retro-active manner, but if one starts with the idea that all the things need to be tied together and the efforts consolidated with a clear strategy, and perhaps sort formal listing system, then one could potentially keep documentation relevant and upto date, and could keep people posted for changes to blogs/forums. It could probably even be automated to some degree using a scripting language that links together some text-based instruction files, we could even have a database or something...who knows...
Conclusion...of sorts
I am not trying to suggest in these articles that there are major problems. But the issue is that we should consider it part of our thinking process when we build a broader strategy for any medium- to large-scale development. The notion I am trying to work on is that it is 'potentially' disastrous, and almost certainly facile, to have a rules system that attempts to encompass all elements of a development into the same time frame. I haven't in these articles yet considered the broader issues that affect industry when it comes to development and deployment of systems. The fact that most companies run (innapropriately) hardware and software together as if they are intrinsically tied in terms of an evolutionary strategy, or that budgets are usually tied to the political landscape as this affects the economy they exist within.
So my argument is that we have a richer roadmap for development that doesn't parcel everything into the same rota of events but appreciates each element for its differences and alots a strategy that encompasses its particular uniqueness.[6]
If anyone has feedback (and until we have a commenting system) please don't hesitate to email me at: m.keating [at] shadowcat.co.uk, if your comments are useful, fun, or just plain interest to me, or if I think will be useful to others, then I will add them to the end of this post, let me know how you would like to be named (anon, nick etc.).
[1]So before a gaggle of teachers gather outside of my door baying for blood or calling me a fascist tool for a totalitarian state, let me point out that it was Bernard Shaw's fault he was a dirty little epigramator. The teachers, educators and bile-slingers who are normally offended by this comment, for shame on you, the man was being satirical, read the rest of the list.Return
[2]Oh I'd like to reference this self-reference[3]Return
[3][Mark Keating, 2009, ibid.] :)Return
[4]You can comfortably assume that I now have asked a lot of questions to which I may not have an answer to. What is even worse is the fact that I am not assumoing there is an answer to them or if they are important. This really is just a discursive article intended to provoke a set of thoughts. It may be in fact careening down a blind alley like a mynock with its testicles on fire (presumably listening to Jerry Lee Lewis and escaping the Millenium Falcon).Return
[5]Though there is strong argument that this is the case anyway and the best you can produce is a tome of best practice and future promise :).Return
[6]I managed to get through both of these articles without mentioning compatibility or the seemingly dreaded backwards compatibility.[7]Return
[7]Crap on a cracker, I just did.Return
Mark Keating is: Managing Director of Shadowcat Systems Limited
Director and Secretary of Enlightened Perl Organisation
Co-Founder/Co-Leader of North-West England Perl Mongers
Work Blog: Mark Keating on Shadowcat
Public Blog: Mark Keating on Vox
LinkedIn Profile: Mark Keating on LinkedIn
My Homepage: Mark Keating's Personal site
