Technology Intersection Blog Home

Technology Intersection Blog
Can your Enterprise Afford to Ignore Agile Development? Print E-mail
Written by Bruce R. Copeland   
Tuesday, 12 May 2015 10:12

I encounter plenty of companies (large and small) that are still trying to decide about agile software development. Does it really work? We already have software that works; why change? Agile software seems to require so much engagement between business product people and development teams. Is this really necessary? Can it work for us?

I get it—Change is Hard. So let's look at these questions.

Does it really work? Of course it really works! Agile software is smaller, simpler software with faster development/modification/improvement cycles. Agile (and closely related Lean and Iterative) development strategies have significantly higher success rates and lower failure rates than traditional development strategies. This has to be an improvement.

We already have software that works; why change? This is a complex matter that could change over time. Your software may meet the expectations of your business products people, but this doesn't guarantee that your IT people are happy with it. Complex software is difficult and expensive to maintain on the backend, and getting ever more so. Consider also the longevity of the software engineers that produce and maintain your software. Top-notch software engineers know the world is migrating to agile. They are already learning (or have learned) agile. You will not likely be able to retain them if they do not get a chance to exercise and demonstrate their agile skills. Likewise if your existing talent leaves, you will have great difficulty attracting top-notch replacement talent if you are hiring them to do old-school development.

Understand too that agile does not necessarilly mean throwing out all your legacy code. In several cases, I've had pretty good success using agile strategies to refactor legacy code. Often anywhere between 30% and 70% of legacy code and legacy logic can be re-used (but maybe only in small chunks).

Agile software seems to require so much engagement between business product people and development teams. Is this really necessary? Well, umm... YES. This is actually true for software development in general. The top six contributions to software project failure are incomplete requirements, lack of user involvement, lack of resources, unrealistic expectations, lack of executive support, and changing requirements. All but one of these reflect some form of inadequate engagement between the business products people and the development team(s). Software developers and business people tend to have very different cultures and experience. Business people typically have insufficient knowledge of backend requirements and the details of design, and software engineers often have a poor understanding of user experience. This is precisely why top-down, 'my way or the highway' approaches to software development usually fail. The only way you really get past the developer/business culture clash is to have developers and business people working shoulder to shoulder daily. Agile has this kind of engagement built in.

Can it work for us? Every situation is different (or as we often say in the software world: 'the devil is in the details'). It is perfectly normal for an enterprise to customize agile development for its particular needs. For example, agile development usually produces only lite documentation. This is sufficient for most purposes. However if you need specific kinds or levels of documentation content, you might want to establish software coding policies to guarantee that the necessary documentation content is produced. Adapting software development for your specific needs is an important job that requires a good software architect. But this is true for both traditional software development and agile development.

Agile development is probably exactly what your enterprise needs. But don't spend too long deciding about agile. Chances are your competitors are already making the switch.

A New Raspberry Pi 2 Running Ubuntu 14.04 LTS Print E-mail
Written by Bruce R. Copeland   
Monday, 04 May 2015 13:19

A few weeks ago I received a new Raspberry Pi 2, complete with case, 32 GB (class 10) SDHC card, 5V/2A power supply, and Edimax EW-7811UN USB wireless dongle. The Pi 2 is an ARMv7 quad processor system with 1 GB of RAM. This is comparable to most better smartphones and tablets, but about 20-fold slower than the 8GB Intel i7 system I routinely use for high-end software development.

Most Raspberry Pi users find it easiest to begin with the basic Raspbian linux distributions available from the Raspberry Pi Federation. However I've been using diverse unix/linux systems heavily for more than 16 years. Currently all the computers in my company run either Ubuntu 12.04 LTS or Ubuntu 14.04 LTS. It is significantly easier to administer systems that mostly utilize the same packages and tools. Also the Ubuntu long term support (LTS) feature has been invaluable on several past occasions when we were involved in complex projects and wouldn't have had time to upgrade other shorter-lived distributions nearing their end of life for security support. Ryan Finnie has recently provided a nice build of Ubuntu 14.04 LTS for Rasberry Pi. So it made sense to start with Ubuntu 14.04 LTS on my new Raspberry Pi.
Doing More with Modules in Joomla 1.5 Print E-mail
Written by Bruce R. Copeland   
Monday, 16 February 2009 14:50

Modules can help solve a wide range of problems in a web site that uses Joomla, but many Joomla site designers do not really know how to fully utilize modules. Eight months ago when I began designing the CyberSym Blogs site, I had some definite ideas about what I wanted. At that time I was fairly new to Joomla, and Joomla has a rather long and steep learning curve. Nevertheless after one somewhat false start, I managed to come up with a reasonably straightforward Joomla 1.5 design for the site.

A few things have however been headaches. The default Joomla 1.5 Syndication module doesn't allow customization to give any feed URI besides the root web site address, and a multi-blog site needs to have different blog feed addresses for different blog sections of the site. Moreover the CyberSym Blogs use burned feed URIs (e.g. ) which are different from the blog web site addresses.

As it turns out, each separate blog section on the CyberSym Blogs site has its own template. A lot of Joomla geeks would therefore simply suggest hard coding the necessary link into the <head> section of each template. So for Technology Intersection, the template index.php file would contain

<link href="" title="Technology Intersection Blog" rel="alternate" type="application/rss+xml" />

somewhere between <head> and </head>. This works, but suppose I don't want the link (or some other code) showing up on every page of the section? It happens I also spend a fair amount of time posting comments on other people's blogs. This is good blog practice, but only if you can establish a recognizable presence on other sites which points back to your own blog (branding). A really good way to achieve this is to use your own blog site as a provider link for OpenID (see e.g. Sam Ruby's "OpenID for non-SuperUsers"). To accomplish this I need to have OpenID server and delegate links in the <head> section on the main page of certain blogs. I do not want those links on all the other blog pages of each blog section. So how to do this? Joomla Modules, of course!

Modules are central to Joomla. Each menu has a module; there is a login module; there is a module for most popular articles, etc. Part of the power is that you can configure each module to work or show up on only those pages you want. Most of the time you position these modules somewhere visible on your page(s) by choosing from one of the roughly 6-20 locations predefined for whatever template(s) you are using (e.g. TOP, LEFT, USER3, etc).

There are many different kinds of modules in Joomla core and you can install additional modules as part of various Joomla extensions. To see all the module possibilities you have currently, go to Extensions/Module Manager in your Joomla administrative backend and select New. You will see a list of all the different kinds of modules. If you know how to write html or javascript (or if Google or some other site has provided you with script for a widget or a service), the Custom HTML module is especially powerful. You can select a new Custom HTML module, give it a name(title), select a Position from the list, use the Menu Assignment to specify the page(s) where the module will be used, enter whatever html code or javascript code you need in the Custom Output at the bottom, and then save it. The box with the feed button and different chicklets on the right of this blog's articles was done this way. [By the way, some editors available for Joomla do not play nicely with script that you may include in your html. An effective way to handle this problem is to create a new administrative login that has no assigned editor and use that login whenever manipulating script in a module.]

Some of you may not realize it is possible to define and use new module positions. Want a banner at the top of your blog article area? Find a line like <jdoc:include type="component" /> in the <container> section of the index.php file for your template, and insert a new line

<jdoc:include type="modules" name="componentbanner" style="xhtml" />

just before it. Next go to the Module Manager in your Joomla backend and create a new Custom HTML module. In the combo box for Position, type in a new position called componentbanner. Put the code for your banner in the Custom Output window. Now you have a banner in your new COMPONENTBANNER module position. This is all you need to do for templates you are using yourself. However to save headaches down the road, it is a good idea to put a line


somewhere below <positions> in the templateDetails.xml file for your template.

This approach is not limited to visible positions on your pages. Herein lies the solution to my feed and OpenID links problem mentioned earlier. In the <head> section of the template index.php file for each of my blog sections, I put a line:

<jdoc:include type="modules" name="pagehead">

(Because the <head> section doesn't contain visible layout, the added line doesn't include style="xhtml" the way it does for a new module position in the visible part of a template.) I then created Custom HTML modules positioned at PAGEHEAD which have the appropriate code for the feed for each blog section. I also created different modules for each of my OpenIDs that have the appropriate OpenID server and delegate code. These OpenID modules also appear at module position PAGEHEAD but only on the specific pages I want to use as OpenID links.

There are myriad other variations on where and how you can use Joomla modules. You can even get modules into your articles (see How to include modules in content item for Joomla 1.5.x). Maybe these ideas will help you solve some of your own site design headaches.