Chris Sterling’s Blog

“The team continues to complain about working with that legacy codebase because it has so much software debt. That software debt slows them down in feature delivery and they are wondering if we can push for priority to be put into paying it back some?” asked the ScrumMaster. The IT Development Manager looked distraught about the request. She knew that paying back some of the software debt would be a valuable effort but what would the business say about the priorities? “Tell the team that we’ll start paying back some of the software debt starting in the next release. We must get the current release out the door and a change in priorities won’t allow us to get there.” the IT Development Manager said.

Considering the circumstances I cannot tell an IT manager that this approach is not the right way to go. In many cases the IT manager is not in a position to push for technical priorities even when they will provide value to the business. As teams continue to develop on a system without managing the software debt effectively feature delivery throughput decreases. The following picture shows a team’s feature delivery throughput versus time spent stabilizing each release over time:

There are many reasons for this software debt accrual:

• Pressure of the deadline
• Inexperienced team members
• Specialization
• Over-complication
• Bad design
• etc…

IT management has looked for ways to minimize the effects of software debt. We introduce processes that in theory will reduce software debt but in reality seem not to lessen the effects at all. Tools are introduced that will ease the software development process but we still see similar or potentially new mistakes made by team members. Individual team members are asked to specialize in particular software development disciplines such as Database Administrator (DBA), Quality Assurance (QA), or Business Analysis (BA). Although we do each of these specialized roles more efficiently it seems that the product delivered still is accruing software debt. So what do we do?

It is my experience that teams that adopt agile test and engineering practices within an organization that supports collaboration between business units and development teams are more successful in the containment of software debt. These teams tend to minimize software debt and will at the very least deliver with consistent throughput release after release. In some cases I have seen teams accelerate the velocity of their feature delivery throughput over time.  The following figure represents the problem IT managers have in deciding to manage software debt effectively on existing legacy software:

A team will have to slow their current feature delivery significantly in order to get consistent throughput over time. I would suggest that managing the software debt effectively would be the best decision for a business relying on this software. Software is a valuable asset for businesses that can:

• Reduce costs for business processes by automating significant portions
• Provide information to business quickly so they can make better strategic decisions
• Attain market share providing shrink-wrapped software to meet the market’s needs
• Reduce system decay on existing software assets so they can be used into the future
• and much, much more…

Still, given all of these reasons it is difficult to take on software debt in the wild. We must understand that a typical IT manager has many influences on their decision making, as well:

• Business pressures for a set of features on a certain date for a set cost (The Iron Triangle)
• Expectations of feature delivery based on past software releases
• Unreasonable deadlines due to business issues such as lapsing support contracts and executive management promises
• Perception of their organization and how that reflects on their capabilities
• A compensation plan that does not reward managing software assets for future capability
• etc…

Given all of these circumstances I believe that IT managers are making the best decisions possible. How can we help IT management support our organizational software assets effectively and minimize the effects of software debt? What approaches will allow the software delivery teams to manage software debt while delivering essential features? How can business get more involved and increase understanding of this dilemma that will affect the organization’s capabilities over time? I am interested to hear from anybody who reads this. What are your suggestions?

1 Comment »

A few years ago I was privileged to be on a team with some excellent developers where I currently work, SolutionsIQ. One of whom saw the need to stabilize development on an incredibly unstable codebase with no tests. He came to the team with a proposed tool that he slapped together in his free time. It was a mashup of Selenium and FitNesse along with some modifications to support some special needs we had on the project. His name was Paul Dupuy and the entire team, including Mickey Phoenix, Rand Huso, Jonathon Golden, and Charles Liu, spent some time working on enhancing the tool, now called StoryTestIQ (aka ‘STIQ’), to make it what it is today. Other teams at SolutionsIQ have been using StoryTestIQ, as well, and helping to enhance its capabilities from time to time.

One issue that we have had is that the visual testing portion of StoryTestIQ runs inside a web browser. The security models for each browser is a little bit different but for the most part they restrict cross-site scripting. For most of the projects we have used StoryTestIQ on the customer’s browser was always Microsoft Internet Explorer (IE). Given this constraint we were able to run in a special non-secured mode of IE called HTML Applications (HTA). This mode of IE also has a problem. The browser history is not retained while in HTA mode therefore some JavaScript functions will not work if used in your application.

Recently I have been working on a project that must work in multiple browsers. Also, I have a Mac so the constraint of using IE is not necessarily reasonable without some coaxing. Instead I decided to take on a quick Apache2 with mod_proxy experiment to see if I could serve both StoryTestIQ, which serves its pages from the FitNesse server inside, and the project’s web application server. It worked and so now I will share it with you.

I will assume that you are already using StoryTestIQ and have Apache2 installed already. If not, please make sure each of these run within your environment before moving on. In my first configuration the project I was developing is running on the Jetty web application server on port 8080. I started up StoryTestIQ on port 9999 and left my project’s web application up and running while I configured Apache2. I used MacPorts to install apache2 in the /opt/local/apache2 directory. In my environment the httpd.conf, Apache2 main configuration file, was located at /opt/local/apache2/conf/httpd.conf. In your own Apache2 installation find the default httpd.conf file for configuring the server. Inside the httpd.conf configuration file make sure that mod_proxy is installed and loaded by searching for a line similar to this:

LoadModule proxy_module modules/mod_proxy.so

If you are not currently using mod_proxy then please review their web site to install and configure mod_proxy for your environment. If mod_proxy is successfully installed then you can add the following lines to the httpd.conf file below all of the LoadModule entries:

#
# Proxy configuration for STIQ and local Jetty application
#
ProxyPass         /stiq  http://localhost:9999/stiq
ProxyPassReverse  /stiq  http://localhost:9999/stiq
ProxyPass         /files  http://localhost:9999/files
ProxyPassReverse  /files  http://localhost:9999/files
ProxyPass         /STIQResults  http://localhost:9999/STIQResults
ProxyPassReverse  /STIQResults  http://localhost:9999/STIQResults
ProxyPass         /myapp  http://localhost:8080/myapp
ProxyPassReverse  /myapp  http://localhost:8080/myapp

#
# Rewrite ProjectRoot, STIQ repository main content page, to STIQ server
#
RewriteEngine On
RewriteLog “/opt/local/apache2/logs/rewrite.log”
RewriteRule ^/ProjectRoot(.*) http://localhost:9999/ProjectRoot$1 [P]

There are multiple directories which can be easily proxied using basic ProxyPass and ProxyPassReverse directives. These are /stiq, /files, and /STIQResults. Due to the wiki page URL construction the main content page within the STIQ repository cannot use these basic directives. Instead you must use the RewriteEngine with a rule to map any URL starting with /ProjectRoot* to the STIQ Server. The problem was that the wiki page would ask for a URL such as http://localhost:9999/ProjectRoot.StoryTests and the basic proxy directives would see this as a new URL compared to basic /ProjectRoot. The use of the RewriteRule allows anything that starts with /ProjectRoot to get proxied across.

Once you have these configurations added to the httpd.conf you can restart the Apache2 server. In my environment the command was:

/opt/local/apache2/bin/httpd -k restart

After the web server is restarted you can launch StoryTestIQ inside your browser using a URL similar to this one:

http://localhost/stiq/runner.html?startPage=/ProjectRoot&suite=StoryTests

You’ll notice that this is going through the default HTTP port 80 instead of STIQ’s port 9999. We are now proxied on port 80 to port 9999 for STIQ related URL. You can write automated acceptance tests opening  a URL starting with http://localhost/myapp and it will proxy to port 8080 where your web application is running. Make sure to have all of the port numbers correct in your configurations if your environment differs from mine.

I have also configured a Ruby on Rails application for automated acceptance tests against with STIQ. In that case I had to configure mod_proxy with the following directive adding an application name to the Apache2 URL to proxy:

ProxyPass         /myapp  http://localhost:3000
ProxyPassReverse  /myapp  http://localhost:3000

You can see the welcome page for your application using this basic configuration but once you have any URL locations identified in your web pages that start with ‘/’ they will not be found. In order to support URL which start with ‘/’ you must modify the appropriate environment configuration inside your Ruby on Rails application. The environment configuration are found in the ${project_root}/config/environments directory by default. I added the following to my development.rb environment configuration file which is what I use with STIQ:

# This allows me to run using mod_proxy on Apache2
# Using StoryTestIQ for automated acceptance testing
# It runs in a browser and therefore cross-site scripting is not allowed
# which the mod_proxy allows me to get around by passing both the StoryTestIQ
# server and the application under test through the same root URL
ActionController::AbstractRequest.relative_url_root = “/myapp”

This will cause all requests for URL starting with a ‘/’ to become ‘/myapp/’. This allows them to be found through the Apache2 proxy.

If you are interested in beating the cross-site scripting restrictions of most major browsers for use with StoryTestIQ I hope this blog entry will help you out. This same mechanism could help with other tools out there who have browser restriction issues. Let me know through your comments if this worked for you or if you have any suggestions on modifications that could make this easier.

No Comments »

Agile 2008 was an interesting experience for me. It was the first time that I went to a conference and felt like I knew a large portion of the participants. I am not sure what this means but I had fun meeting up with friends and acquaintances.

Bas Vodde, a Certified Scrum Trainer from Singapore, had mentioned an automated acceptance test framework being developed at Nokia Siemens Networks called Robot during a course we taught together in Los Angeles, CA. He told me this framework would be made available soon as an open source project. I kept my eyes open and not very long after our March 2008 course it was available here. Bas introduced me to Pekka Laukkanen, creator of the Robot framework, and it was a pleasure discussing his vision of where the framework is going in the future. I am testing the tool out for potential use in our organization along with StoryTestIQ, an open source tool put together at SolutionsIQ.

A colleague of mine use the phrase “Pesticide Paradox” to support his point about automating tests. Mickey is a dynamic speaker, great developer, and all around nice guy who presented twice at Agile 2008 on “Narrative Testing: Tools for Story-Test-Driven Development” and “Domain-Specific Testing Languages”.

I presented on “Architecture in an Agile Organization” and a few folks showed up to participate. I thoroughly enjoy discussing architecture and decision-making surrounding it in an agile context. After putting so much emphasis on big design up front (BDUF) it is difficult to understand how we can make incremental steps from an architecture perspective. Also, the Agile Manifesto has a principle:

The best architectures, requirements, and designs emerge from self-organizing teams.

This can be problematic if we do not trust in a team’s capability to make architecture and design decisions. My hope is to give some tools that organizations and teams can use to build this trust.

I did not attend many sessions at Agile 2008. I am not quite sure why this is but I found myself in good conversations and getting involved in the right topics for me. If you have an opportunity to attend Agile 2009 I highly recommend it.

No Comments »

Michael Krigsman provided an interesting variation of why blind dates so often fail and changed blind dates to project plans.

The interesting piece to me is the overlap area identified as “rare”.  I speak to many folks about their project expectations compared to plans and one phrase which comes up often is “well, it worked in [name of] project fairly close to plan”.  The somewhat rare success in planning up front seems to be a beacon for further use of particular project planning tactics.

I am not going to expand right now on this subject but I would like to leave this with something for us to ponder.  How many of your projects actually get even close to original plan expectations?  What methods in planning are actually adding to the success?  What types of projects are finding better success?  Let me know if you have any comments or wish to share your answers with the readers of this blog.

No Comments »