It is not commonly understood how software development projects moving forward as fast as they can and sometimes do, can be in direct conflict with their actual rate of adoption, not to mention their commercial delivery to market.
This post outlines the differences between short- and long-term commitments, and how the distinction can be used to form complementary facets of a project, rather than remain in perpetual conflict.
Generically speaking, the result of a single iteration of an agile development methodology should result in two things;
- A known, established and verified upgrade path from the previous iteration,
- However slight an increment in product value.
In contrast to the moving target as outcome of iterations in projects using the agile methodology with its virtually inherent unpredictability, businesses sign contracts with promises, including but not limited to;
- A version of the product that is both quality-assured and stable — meaning there are no surprises at the end of consuming a stream, meaning neither pleasant nor unpleasant surprises,
- Support for that version for a much longer period of time than the original outcome of any one particular (group of) development iterations,
- Incremental updates to support sustainability of the product, be it bug fixes or incremental enhancements,
- Service level agreements guaranteeing turn-around time-lines,
- A competitive value proposition based on the aforementioned parameters,
- Services including but not limited to development of customizations, training and consultancy,
- The next version of the product meeting all facets of the current version of the product.
There are a few additional aspects I could go in to that need to be omitted for genuine Free Software ISVs, such as licensing and exclusivity, as I consider both to be strong-arming a competitive edge, or bullying.
Short-term Commitments
A short-term commitment is a predictable time-line with an established amount of investment in which the product value can incrementally be increased with a known value.
We can state with a degree of certainty that these commitments are relatively small compared to a contractually obligatory commitment to paying customers, to support their deployment for up to 72 months, or 6 years.
We can also state that the goal with short-term commitments is an increase in product value, and that the motivations for development partaking in short-term commitments prioritizes the incremental enhancements sorted by descending value increment.
As such, short-term commitments are made with an eye on the future — research & development prototyping something, for example.
Long-term Commitments
A long-term commitment is a period of time often spanning multiple years, during which promises need to be delivered on.
These promises have been made to oneself, a community at large and paying customers. These promises include hard targets (contractually obligatory facets) and soft targets (the next generation of a product stream). They will have to be kept though — as such long-term commitments are made with an eye on the past, including tomorrow, aka. the future past.
We can state with certainty that very few developers are interested in, and even fewer capable of, both the development of the next generation of the product and maintaining up to 6 or 7 legacy versions. We can also state an ability to support and troubleshoot a set of often ill-articulated symptoms remotely is quite a different discipline.
It is not easy to establish how much costs are to be associated with long-term commitments ahead of time, albeit there are models to estimate such costs.
One method to reduce such costs (and therefore better predict real costs within a smaller margin of error) is to ramp up quality assurance. It is, proverbially speaking, making sure your customers do not have to pick up the phone at all and therefore reduce the support cost while demonstratively increasing the value of the KSP.
Quality assurance however still spells a certain degree of uncertainty in real cost, and is another long-term commitment — except when it is automated and frequently executed, preferrably as early as possible.
Customer, Product or Business Value?
If you were to entertain only short-term commitments, the product value would be unjustly biased toward customer value as a means to achieve business value.
Customer value however is often perceived rather than real, as customers will think the world of the feature they request be included — an absolute necessity, can’t work without out. Ultimately, it morphs the product toward a collection of complex features that are not generically applicable to most or all consumers of the product.
Product value needs to be understood to mean generically applicable functionality, or high-value functionality applicable more selectively. This implies that functionality applicable more generically is multiplied the product value of implicitly, albeit by an indeterminate factor. It would therefore be prioritized accordingly.
When a project deliberately pursues the implementation of more specific functionality, this should be considered a matter of strategy, such as opening up entire market segments, target audiences and industries.
For the real punchline, let’s look at business value. In a genuinely Free Software ISV business, there’s little distinction between product value and business value.
For all considerations development, future and short-term commitments, the business value of the product can only rise if the product value itself rises. In other words, if the product’s business value, so does the product value itself. If the product value rises, so does its business value.
To put things in perspective, draw a distinction between the business value of the product, and the value of the business.
Linking It All Up
The long-term commitments predicate that the result of short-term commitments come with a meaningful degree of certainty and confidence.
That is to say, very, very well verified.
Provided “very well verified” translates in to actionable items, continuous integration testing is used to establish what score such certainty and confidence may translate into — as early on as possible.
Allowing for the different stages of a single iteration in development means that this must be seeded correctly in order to acknowledge or decline the bar to delivery has been surpassed.
This strongly suggests the process used for development teams is Test-Driven Development, which would certainly increase the certainty on correct input to the development process earlier than a retrospective-based feedback cycle on having missed the mark, and increases certainty and confidence on the result of an iteration as well.
To prevent source code management from containing tests failing as a result, we can bring mandatory code review in to play.
kanarip 
One thought on “Short- vs. Long-term Commitments”
Comments are closed.