Different companies have different kinds of issues and ways of managing them, so I probably shouldn’t be surprised there are many software and service solutions available. And as an engineer it’s tempting to fall into one of two extremes: build it from scratch or buy something and deal with it.

Do-it-yourself was my preferred approach as a young and ambitious programmer. After all, what could be better than a custom-built solution? However, within five years of making and maintaining such solutions I found myself in the get-it-and-forget-it camp. Another five years later I think I’ve settled somewhere in the middle.

My first experience with issue-management systems was on-line support forums. These were simple message boards requiring a lot of moderation. Shortly thereafter I was exposed to a somewhat custom, Lotus-based solution. This time though, as a support technician handling the problems. Since the solution required Lotus, and only worked within the network, it seemed ripe for replacement with a web-based frontend. Studying web programming made me eager to try my hand at making something better.

Building custom intranet solutions came next with employment at a company branching out into other industries. It was interesting to see how the various needs could be met with custom software. At first simple comment systems were enough for employees to keep track of their customer complaints, notes, and follow-ups. Of course e-mail and IM were also being used heavily to supplement.

In time, however, maintaining so many different systems became burdensome for only two or three developers. Increasingly I also saw patterns in the various needs that also fit some existing solutions.

One of the first to be used in house was Trac, and it worked well for our needs initially. Integration with software repositories was nice. Some add-on’s for things like discussion boards worked well enough. The wiki, its integration, and its export options were my favorite features. At one point I even used the mantra “If it’s not in Trac it doesn’t exist” in a push to unify the disparate repositories of knowledge.

Over time though it’s simplistic reports and lack of built-in, multi-project support were too problematic. Other solutions were tried with varying levels of success and failure. One of the most lasting was Altassian JIRA and it’s wiki offering. Customization options did not appear obvious or immediately better to me at the time. Though, some in management were more familiar and appreciated it’s built-in flexibility.

Experiments along the way pushed the boundaries of such trackers; pressing them into service as the official source of truth, customer complaint tickets, feature tracking, road-mapping, to-do/task management, time tracking, and discussion. Ultimately I’ve come to realize that specialization is needed; even if it takes the form of creative use of, extension software for, or rethinking about existing solutions. And at times it is better to have many, separate solutions than keeping it all in one.

Makers of software and technology services must walk a delicate balance between allowing users the freedom to enter their choice of input without allowing compromise of the system. Traditionally systems have assumed users have the best of intentions; this can lead to positive emergent behavior and growth. But as more business has moved on-line so have thieves and other malicious users. It’s no wonder that malicious input is now the number one threat on OWASP’s top 10 list.

Water seeks the path of least resistance as it flows, making rivers crooked. Likewise as the volume of user input increases it also seeps into more and more areas of weakness. And as the developers of services address these weaknesses it often adds complexity that bends and contorts their systems. E-mail software has become increasingly complicated because of it how it is used, misused, and creatively adapted.

At times the data itself becomes deformed to fit within whatever bounds cannot be broken, similar to water filling a form. Twitter‘s 140 character limit has led to or expanded creative use of text including: hash-tagging (‘#’), at symbol (‘@’) nicknames, URI shortening services, etc.

Despite the advantages of allowing liberal input my experience has been that it’s usually best to start strict and loosen up later. Trying to deny values or data that people have become accustomed to is a challenge. The push back may be too much to overcome, meaning the producers must live with that data forever or try to slowly deprecate it.

In extreme cases systems are like submarines in the deep sea which must withstand constant, destructive pressures. Without careful management and design user behavior and contributions can become the tail wagging the dog. This can be beneficial in some cases; though, it can also lead to unmaintainable expectations. An example in the larger software ecosystem is seen as the free software movement advances and some users (at times myself included) come to expect software at very low or zero cost despite the costs involved in their production.

What do you think?

As the version numbers of software and services have crept into the public conscience, the influence of marketing has moved into the numbering process. When version identifiers no longer communicate anything besides the passage of time or marketing campaigns they are just vanity numbers.

Identifying versions of software and services can be tricky business with increasingly longer strings of digits, letters, and punctuation. Consider a version such as “1.15.5.6ubuntu4”. Ubuntu or Debian package maintainers may feel right at home, but even software engineers like myself can get lost after the first or second dot.

Software versions often begin innocently enough: “1” being the first official version. Decimal digits afterward indicating incremental change. Changes to the significant digit were often significant, noteworthy changes in the software behavior, capability, and/or compatibility. Sadly I fear the marketing hype that accompanied the Web 2.0 movement and Google’s Chrome browser have increased the popularity of vanity version numbering.

Sequels to movies and games are common, and when you see a number next to the title it provides instant context. You know that there may be some back-story, content, or previous experience awaiting as you encounter the 3rd or 4th release of unfamiliar franchises. While numbers have fallen out of fashion in film and games, replaced with secondary titles, they served their role well enough. And releases within a franchise like Ironman are more individual products than versions of a single application like Internet Explorer.

Regardless, a user seeing “Opera version 15″ might not realize that upgrading from 12 means more than just the usual “better than before”. Version 15 saw Opera radically change in how it displays pages, handles e-mail, and the add-on capabilities available. This release was clearly introducing breaking changes; something I consider the most important thing versions should communicate. Yet their pattern before version 15 led users to believe the first number was not so significant.

Version numbers, or technically identifiers since they’re not always strictly numeric, can communicate a lot of different things:

• Compatibility and incompatibility
• Addition or loss of capabilities
• Tweaks or fixes
• Package information
• Passage of time
• Progress toward the first release (like 0.9 for 90%)
• Revisions internal to the project
• Start of a new marking campaign

I’d argue that compatibility, capabilities, and fixes are the most important; prioritized in that order. Which is why I think the Semantic Versioning concept is necessary. Despite being designed for Application Programming Interfaces, the behind-the-scenes components that make the ‘cloud’ and software tick, it is sorely needed in user-facing products like Internet browsers too.

Semantic Versioning’s goal of clearly communicating to machines and programmers can also help users understand potential consequences once they know the pattern. And it can be done easily, succinctly, and before they actually choose to update or install.

Ironically it’s the API’s which users do not see that tend to be the most semantic or consistent, at least in their end-point URI’s. These often contain the major version number clearly embedded like “v1” in “api.example.com/v1/”. My experience developing API’s has been that only the major version should be embedded in the URI, but minor and patch fragments can be useful for informational purposes.

One interesting hybrid scheme is Java. It’s major and minor version numbers are semantic with major technically remaining at ‘1’. And at least up until version 8, the latest as of this writing, it has remained largely backward compatible with the first official release. The minor version increases as capabilities are added: 1.1, 1.2, 1.3 … 1.8. Yet since 1.2 it has been marketed using only the minor number. Articles referring to “Java 7” or “Java 8” are technically referring to 1.7 or 1.8 respectively. Sadly the patch (a.k.a. update) version for Oracle’s official releases have gotten complicated.

If you are one of those privileged individuals choosing a version number please don’t get caught up in the hype. Let the needs of your users determine what is appropriate. And as I have the opportunity I’ll try to do the same.

Have you chosen a version identifier? Do you have some thoughts to share? If so please consider commenting.

Software add-ons, a.k.a. plug-ins or extensions, offer the promise of more capability beyond the core package. Though the cost for such expandability isn’t free. In my experience they can be both a blessing and a curse.

Add-ons for projects like the Firefox browser and WordPress have benefited both the users and makers. Doing so keeps the core lighter and simpler and without sacrificing the flexibility and customization that have made them so popular. For example, paranoid browser users like myself can supplement built-in features with things like Disconnect or NotScripts.

Once I administered a website using Drupal’s content platform. It was a lot of fun to browse their modules section looking for things that would help enhance the site. However, with Drupal 5 and 6 upgrading meant disabling those modules first, installing the update, then re-enabling them. And some weren’t compatible or didn’t update themselves properly. It was also a manual process, even with the Drush tool helping me along the way.

Drupal began encouraging module authors to offer guarantees they would support the next major version. But I had already been burned. Newer versions may have improved the situation, but a friend and I moved the site to another platform instead.

Add-on advantages typically include:

• Expandability where it’s otherwise impractical (because of the license, platform, etc.)
• Lighter, simpler core
• Customization apart from a vendor’s built-in capabilities
• Allows the core to be free and open while premium features are sold separately

Add-on disadvantages often include:

• Installing, upgrading may be more complex than without
• Add-on interfaces (for programmers or end-users) can be limiting and awkward
• Maintenance of add-ons may lag far behind the core, hindering core upgrades
• Development costs to produce and maintain add-on interfaces and ecosystems
• Additional security risks as the number of vendors involved and attack surface increase

One of the most famous add-ons is Adobe Flash Player. Flash provided a boon to browser-based games which only recently is being overtaken by newer built-in browser capabilities like more advanced Javascript and HTML5 features. It has also provided media playback for video and audio. Yet I have found it to be buggy, awkward, and inaccessible at times.

As a software producer the ability to build upon existing platforms helps avoid building from scratch. Often it’s useful as a means to prototype ideas or experiment. Though, the risk of platform upgrades breaking one’s work is ever present. On one project I found myself spending about 2-4 hours each week keeping some add-ons up-to-date with core changes coming from upstream.

Looking at the big picture my experience with add-on’s has been generally positive. They have allowed me to tailor software for according to personal preferences and needs; often far outside the intent of the original vendor. While the disadvantages have discouraged me from using one platform, they aren’t enough to outweigh the benefits.

How about you? What’s your experience with add-ons, plug-ins, modules, and the like? Please consider commenting.