we have all met the programmer, hobbyist, or client who appears n multiplied by nine, divided by five and plus thirty-two years after and changes and in a different temperature scale
I don't like to argue with programmers about programming decisions. I even less want to argue with package and release managers on a matter of schedules, especially when a cursory glance tells me that they excel in experience at this to me by a factor that can only be expressed as a power. But on a recent trawl through the blogsphere I read an article that I have no huge issue with in regards to its rules regarding road mapping features and deprecation of invalid code, but I do have a concern with it in regards to its lack, to my mind, of support and education & research.[1]
Support
There is always a problem with support. How long do you support something you created? When do you cancel support for something that is deprecated or refactored? Why should we carry people who not only can't be bothered to be modern,[2] but don't want to pay or be concerned with on-going change and evolution but expect you to be concerned with supporting their archaic or anachronistic possession.[3]
The answer is that there is no clear answer. The issue with support is always going to be a complex one which isn't helped by the fact that the length of support is intrinsically linked to what you are in fact supporting. But these are just an initial thought (and hopefully not a knee-jerk reaction).
How do we treat people who require support? They may be active contributors to projects. To some they may be indulging in a favourite deprecated module snippet, but they may also be maintaining complex legacy systems that are difficult or expensive to replace? Do we tell them to force an upgrade that may be costly or impossible to achieve? And if he cannot do we simply say tough, or we're sorry, or employ a bunch of us to refactor/rebuild your codebase?
How do we sell to clients and industry the idea that unless they engage not only in continuous software integration (which is no bad thing), but rolling support, especially if our time periods are very short. The notion of refactoring, deprecating and advancing code as a major release on a quasi bi-yearly schedule (for complex bases and larger projects) is fine. But the thought of a potential[4] two-years support for a feature that you may have in your codebase is not bad per se but gives off potential warning signs to industry. Business doesn't like the thought that something they develop one day has the 'potential' to be out of community/industry support in less than two years.[5]
Consider this economic situation and answer me this question, would you spend money on a piece of code that may be unsupported before a recession is over? Because a vast number of people would not. They may be willing to invest in new technology or innovation to help with their business but not at the risk of it being invalid and expensive to continue to use over a short budgetary period. Even though this is not what is being suggested that is the perception that is gained when we have such a short support period.
Now, quite rightly, businesses should also be expected to pay for this level of support. The standard thought to this is that some well-known developers, or companies, are going to end up supporting and patching older systems and rightly earning a living from it. This situation exists and will continue to exist. But what about the notion of businesses supporting the community? How about we consider persuading more businesses to allow their developers to contribute to projects and modules they use in their working life and to do this while they are at work. How about if a company pays for documentation patches and code refactors for the *whole* community. That is a form of payment that benefits us all.[6]
Businesses, specifically medium to large enterprises, are often retiscent to change as it is expensive and probelmatical. They are also, conversely, the strength behind a lot of innovation and change. Small companies can, for want of a better word, be more *agile*, but they don't always have the resources for long-term investment that brings about substantial alteration of culture. There are always exceptions to this broad statement but major changes do not occur until a company has affected a certain portion of a culture. This does not happen in the short term, and any culture that ignores the slug-factor of larger enterprise may find itself relegated to niche waters.[7]
If we are going to have clearly defined software development periods with a road-map for development and a schedule for deprecation then that gives a positive boost to the future of a project. But, to my mind, unless we understand that the support period, especially for industry and large projects, has to encompass a plan to have support hooks in place both in the community and in our development road-map for a much longer period than that release/deprecation cycle we will encounter issues.
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] By now there are some who may know have guessed the article that
inspired this post and may wonder why I haven't posted this on that
blog as a comment, or made a reference to the original here. Well the
answer to that is simple:
a. The principle issues raised in that blog I am not actually discussing here;
b. I respect the person's opinion and stance and don't wish to appear
negative especially since I have discussed the article with
intelligent people (who are programmers) whose opinion I respect and
who have helped me to gain a better understanding of the broader
issues that article is addressing.Return
[2] Whatever the hell that means.Return
[3] And we have all met the programmer, hobbyist, or client who appears n multiplied by nine, divided by five and plus thirty-two years after and changes and in a different temperature scale, demands some help without any thought of remunerative action and is indignant if you aren't fully compliant (there are no Shadowcat clients like that, though, they're all lovely :) ).Return
[4] I want to highlight that this is 'potential', it would be supported for a year after deprecation and any feature not deprecated would have continuous support, this goes without saying but is clarified here.Return
[5] While fully supporting the idea that they are 'cutting-edge', 'progressive', 'evolutionary' or 'modern' (see above).Return
[6] Note that we, and many companies like us, already do support the community in this fashion. Also our clients are often willing to contribute some, or all, of the development time they pay us for into returning innovation into community modules we use. My point is that we need more of this and to target it as a positive feature of using open source code.Return
[7] This is really skimming the surface of this argument and because of that it is at best shallow in some of its conclusions, and at worst just plain wrong. I don't disagree with what I have said, I just haven't covered what I am trying to say well enough. But it serves as an introduction to an area of thinking not the conclusion of a thought process.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
