Category: software

Remarks about WordPress Development Lifecycles

This is a set of notes and remarks rather than anything comprehensive or systematic. The main point is learning from the fact that there is a development lifecycle in terms of consuming software products, and make better adoption decisions through a set of heuristics.

By development, we need of course to expand this to encompass what is generally known as design, development, devops, sysops and ongoing maintenance. The key to reducing risk in WordPress development is to understand the lifecycle.


WordPress Development

By WordPress development, we can include all of the following:

  • Selecting a new theme or theme framework
  • Making a choice between plugins
  • Deciding at what point custom development is needed
    • Themes
    • Plugins
  • Hosting decisions
  • Security issues
    • hosting and operating system configuration
    • security plugins
    • secure plugins

Obviously the term development is being used in its very generic sense. Still, we can separate it from marketing and from content, which are the two other legs of the WordPress three-legged stool we use as a platform for publishing.

Development Lifecycle

By lifecycle we understand that there is birth, growth, decline, and death. Development itself can be understood as the building up of something. We usually understand development as a period of time for building and a period of time for maintaining. This is obviously an architectural metaphor. However, it is really not useful or apt when looking at software development. Why is that?

  • Software can be refactored
  • Software can be loosely coupled or integrated with other software
  • Software versions are released over time, which tends to include more features
  • Software can become obsolete when it is rendered incompatible with other systems, software, or coding practices
  • Software can become unusable when new versions introduce new problems
  • Software can become a greater risk to use when it is abandoned by its original developers

Finally there are financial considerations such as when free versions of critical plugins or themes are no longer available, forcing all users to pay or to spend considerable time migrating to others.

Risk Management

All of this comes down to the basic concept of risk management. Risk is danger to an organization, in terms of the likelihood and severity of present or future costs. While deciding which plugin to use for a contact form seems fairly innocent (and generally it is), things like multilingual, ecommerce, or elearning systems require a much greater investment in installation, configuration and maintenance, with much higher switching costs.

Lifecycle Heuristics for WordPress Development

Because a lifecycle deals with unknowns in the future, it is never perfect and there is always risk. However, there are certain heuristics — rules of thumb — that can be used to help mitigate and minimize risk. The following are an assortment of heuristics that, while not always accurate, do help minimize risk.

WordPress Theme and Theme Framework Heuristics

Most themes are not maintained for long. The average half-life of a theme (the amount of time by which the probability of it being abandoned is 50%) is most likely immediately after the first version is released. Many try to minimize this risk by paying for a theme, but the same is true of paid themes.

Theme frameworks have a much longer lifecycle, as they are made for designers and developers who will pay maintenance fees in order to get some stability and continuity. Regular subscription fees are a motivator for theme frameworks to incrementally improve and maintain compatibility with the every changing panoply of plugins as well as WordPress core (which has major releases three times per year).

However, yearly maintenance fees do not remove all risk, and the lack of yearly maintenance fees are not a sign of impending abandonment. Ultimately, one should consider any theme framework from the perspective of the following question:

If this framework is abandoned tomorrow, will it meet my needs and is it worth whatever maintenance I need to do myself, for the next two years or more?

Since a framework will eventually be replaced (i.e., it has a lifespan, and is not immortal), risk management consists of a clear-eyed assessment of the functionality vs. maintenance costs (in time and money) as well as opportunity cost for going with a different system.

Ultimately, one should build one’s own theme and child themes. The risk of course is building something that does not meet present or future needs, and/or is too time-consuming to maintain. Several years working with other themes and theme frameworks for a given website or set of websites are the ideal approach to understanding the design space. Indeed, working with an incomplete or aging theme framework can be extremely informative in terms of producing a set of requirements for a theme and child themes that will provide excellent value for years to come.

Some of the following may help flesh out the requirements from a functionality perspective:

  • No javascript or gracefully degrades without javascript
  • Support for screen reader CSS
  • Responsive design with target viewport dimensions
  • Plays nicely with all current plugins, especially those with important functionality, e.g.,
    • WooCommerce
    • ALO EasyMail Newsletter
  • Can potentially replace one or more plugins where that makes the most sense, e.g.,
    • Custom search and 404 pages
    • Remove author pages
    • Custom templates that display lists of all posts organized by category
  • Single CSS file

WordPress Plugin Heuristics

Plugins are a boon and a bane in WordPress. One needs many of them (some for a single tweak here or there to WordPress Core), they constantly age and require updates, are abandoned, conflict with one another and with new versions of WordPress Core. Here are a few heuristics that might help with risk management:

  • Older, massively popular plugins are in general a better bet (even if abandoned), because the large userbase will come up with fixes when problems arise.
    • There is one huge caveat to this, and that is monolithic plugins that continue to add features. This usually means ongoing problems and the introduction of new bugs. Yoast is the biggest poster child for a very popular plugin that breaks continually over the years.
  • Simpler plugins rather than more complex (best-of-breed vs. all-in-one)
  • Plugins that operate with shortcodes rather than wysiwyg drag-and-drop interfaces
  • Plugins whose configuration is stored properly in custom tables or extending custom posts and metadata
    • Examples include Redirection and ALO EasyMail Newsletter
  • Using custom posts, metadata and shortcodes makes the functionality more abstracted and does not require the front-end to use parameters such as ?variable=value
  • Plugins which, if removed, either degrade gracefully in terms of the content or data left behind, and/or are easy to work with using regex search-and-replace (e.g., unique shortcodes)
  • Plugins which do not have a pro (paid) version
    • Plugins which have a core part that is free and additional plugins that are paid are a better source of stability and risk minimization, as the core part needs to be maintained in order for the paid plugins to remain viable
  • Plugins with active development (even if sporadic)
    • That said, some of the most important plugins I rely on have not been updated for years (occasionally requiring I do a little hacking)
  • Plugins made by a supergenius who uses the plugin themselves (note the supergenius requirement, along with dogfooding)
  • Plugins around which an ecosystem has formed to extend and enhance
  • Plugins that use or can interact with the latest security standards and configurations
  • Plugins where support on is available (rather than requiring using an offsite system for help and support)
  • Ratio of 5 stars to 1 star reviews (should be around 10:1, whereas when it gets around 4:1 this signals poor quality)
  • Retention rate (Active installs / All time downloads)
    • Note that over time this ratio gets smaller naturally, so for very old plugins this doesn’t work, but for 1-3 year old plugins it is a good indicator

In some cases a set of plugins need to be replaced because of a need (or opportunity) for speed and/or security and/or functionality. For example, Postman SMTP allows for OAuth2, a new security standard. But this has knock on effects in that some Newsletter plugins don’t support this, so it would require migrating to a new newsletter plugin. So a final heuristic is keeping up with good coding practices (without simply embracing every new (not necessarily good) idea.


Originally published at


Release Cycles and Lifecycles

Release Cycles and Lifecycles of software (and hardware) are interesting. How these releases are structured, who does them, and the planning and development process is fascinating from a rollout-of-features perspective. Development release cycles can also be applied to services.

Operating System Release Cycles

Of course we know how Microsoft is getting into trouble with their multi-year release cycle. Apple seems to beat them quite handily with a yearly release, but that is about hardware more than anything. My current comment on Apple’s OS is that it is pretty much like Microsoft, in that we get shitty releases, some patches, and then a better version (or not) in a year. Everything post-Lion has been a huge disappointment, little gadgety enhancements notwithstanding. The fact that the designer guy has had a complete run over Safari, not to mention Safari’s lagging technical chops should indicate how the helm of the software shop is undermanned, to say the least.

In any case, the 6-month release cycle of Fedora and Ubuntu is a pretty good timeframe (for an operating system). Of course Fedora server and Ubuntu LTS versions have a longer and different lifecycle due to stability and security issues.

Application Release Cycle

The 4 month WordPress release cycle is good for fairly complex applications (server or desktop/mobile). It should be obvious that bug fixes and point releases should be liberally sprinkled in to keep everyone aware of the relevance of an application (or operating system). They key of course is to provide value (not introduce new bugs), definitely squash current bugs, and of course security updates.

Unfortunately most organizations don’t do this well. Two recent examples spring to mind. CyberDuck’s MountainDuck which was a poor attempt at copying Transmit’s Disk functionality — and broke the base CyberDuck application functionality every other release or so. As well, the OSX implementation of CloudMagic, which also went on a yo-yo of implemented and broken functionality. (CloudMagic is a silly name, and ultimately a failed approach which is to remove information and the advantage of a large screen, essentially upsizing (slightly) the iOS app.)

Release Cycles and Professional Services

Release Cycles can be implemented in ongoing professional services. The key is to provide visible value (even if only conceptual) rather than a monthly task list and invoice. Here is a sketch of how one might approach this, with new and current clients.

  • Begin with a version 0.1 which is a baseline, where we are
  • If one has already been at work for 4 months or so, stretch back that amount of time. (April, August, and December are good months to have releases in.)
  • Next major release is in the next month. Note that a major release doesn’t have to have major changes, just a numbering to put a stake in the ground and indicate a milestone for measurement.
  • Now that there is a release cycle, one can put some structure around that (known process)
  • Finally, add items to the development roadmap which consists of the major releases (and their point releases).
  • Of course weekly meetings, email, chat, and wiki work should always take precedence, but now there is a set of time horizons around which to structure discussions.

Originally published at

Software and Priorities (Open and Other)

Just a quick note about software and priorities. I am continually looking to change the software I use to reach the most desirable set of criteria (if I am using software that does not yet embrace those criteria). Here are the criteria, in alphabetical order:

* Active developer community
* Cross platform
* Extensible (plug-ins, etc.)
* Free
* Functionality
* Large user base
* Open source
* Simplicity
* Stability

There are a few pieces of software that more or less meet these criteria, such as:

* [Apache](
* [MySQL](
* [PHP](
* [Python](
* [Ruby](
* [Firefox](
* [Open Office](
* [Pidgin](
* [Blender](
* [VLC](
* [FileZilla](
* [Gimp](, especially the [GimpShop](
* [MediaWiki](
* [WordPress](

Some software I like to use might violate these criteria, such as [notepad2]( (no development, windows only) and [iconforge]( (not free, windows only), but they are simple and good at what they do, so I stick with them. However, over the long run, I see open source, cross platform as winning. I believe I will be cutting over to Ubuntu around 2009 or 2010. Here are my current reservations:

* [Cinelerra]( is not cross platform, plus drivers!
* Open Office Impress sucks compared with Powerpoint
* [Second Life]( client for linux is in alpha

So, the way I look at it, as soon as I can move over to a new operating system while maintaining my current set of software tools (which have been slowly migrating to linux supported options), then I can make the move.

I look forward to the transition.