• Technical debt: tends to focused on the code and reveals itself in duplication and code smells
• Quality debt: focuses on QA aspects of software development and shows up in growing bug databases and longer regression test runs
• Configuration Management debt: focuses on integration and release management aspects and becomes apparent with extreme branching and inability to recreate environments from scratch
• Design debt: focuses on design constructs of components within an application or enterprise infrastructure and is usually difficult to figure out until you are close to a deadline such handling production load
• Platform Experience debt: focuses on the people in the software creation process and usually involves extreme specialization and waiting on people to finish their part

Without further ado, here are the slides:

Also, here is the picture I use to discuss Managing Software Debt from high level in terms of maintaining and enhancing value of software assets:

To whom it may concern:

For many years we, Chris Sterling and Brent Barton, have worked for SolutionsIQ.  We both have had an amazing time working and establishing great relationships, strategic business capabilities, and successfully supporting SolutionsIQ clients.  We recently decided to follow a passion of ours: creating products. This means that as of October 16, 2009, we will no longer be employees of SolutionsIQ and will begin work under our new company, Sterling Barton.

It is important to let everyone know that this does not mean the end of our working relationship with SolutionsIQ.  We are working diligently to have a partner agreement that enables both of our companies to fulfill engagements together.  It is our expectation that this will be a strong relationship that continues well into the future. Our focus will be to fund our product development through consulting and this means our relationship with SolutionsIQ should be seen as complimentary.

Leaving SolutionsIQ is both exciting and difficult.  We have incredible friends at SolutionsIQ who also challenge us with their insightful perspectives.  SolutionsIQ has proven to be a joyful place to work combined with significant capabilities that go hand-in-hand with great people. This has not changed and we expect this to be continuing into the future and improving with time. We want the bonds we have created with the people at SolutionsIQ to extend past our employment with SolutionsIQ.

Brent, if you didn’t already know, started with SolutionsIQ six and one half years ago. He started the Agile Consulting part of the business four years ago and has shown himself to be a tremendous thought leader and respected individual in the Agile community.

For those not familiar with Chris, Chris started with SolutionsIQ four years ago as ScrumMaster and team member on projects. He joined Brent on Agile Consulting engagements soon after that part of the business started and has also become a thought leader in the Agile space.

With SolutionsIQ, we have both found the freedom and support needed to pursue new business opportunities and raise the presence of the company and ourselves within a larger community.  We are grateful for these opportunities and are happy with where we are today based on these and many other people’s efforts.

As we venture out and build a grass roots business, feel free to contact us.  We are having fun and would love to share more good times together with you.

Sincerely,

Chris Sterling and Brent Barton

sterlingbarton.com

If you are interested in contacting us, you can email us at brent at sterlingbarton dot com or chris at sterlingbarton dot com. If you are interested in hiring us  to support you in Agile adoption, management consulting, and technology consulting please send an email to info at sterlingbarton dot com. Thank you.

My first blog entry back is about the upcoming Pacific Northwest Software Quality Conference (PNSQC) that is happening from October 26-28 in Portland, OR. This conference was highly recommended to me by many people. This year I am fortunate enough to attend, have a paper published for the event, and presenting the paper for 45 minutes during the conference. Here are the details for my paper and presentation:

P-30 Managing Software Debt

Chris Sterling, SolutionsIQ

Many software developers will have to deal with legacy code at some point during their careers. Seemingly simple changes are turned into frustrating endeavors with code that is hard to read and unnecessarily complex. Test scripts and requirements are lacking, and at the same time are out of sync with the existing system. The build is cryptic, minimally sufficient, and difficult to successfully configure and execute. It is almost impossible to find the proper place to make a requested change without breaking unexpected portions of the application. The people who originally worked on the application are long gone.

How did the software get like this? It is almost certain the people who developed this application did not intend to create such a mess. This paper presentation will highlight ways teams can work with stakeholders to manage software debt over the delivery life cycle of the product.

I hope that I am able to see others at this event. If you are interested in attending and would like to get a $50 off the normal conference attendance fee, enter the promotion code “FOA – Chris Sterling” when registering. You can register at the PNSQC web site (http://www.pnsqc.org/2009-conference/registration-information). See you there!

A healthy Product Backlog contains not only new features but also technical requirements to support the next Product Backlog items in priority. The development team is expected to review the Product Backlog frequently to provide cost estimates for Product Backlog items to help the Product Owner prioritize based on both cost and benefit. During the development team’s review they will suggest Product Backlog items that are missing from a technical point of view in the product definition. These technical Product Backlog items will be discussed with the Product Owner so they are able to prioritize them effectively. It is essential that the development team explain why each technical Product Backlog item is important to support other upcoming items. If this is not expressed the Product Owner could be inclined to demote those technical Product Backlog items because the value of them is not understood enough.

When issues are found in the software they usually come in three varieties:

• Enhancement – a suggestion for improving the current state of the software from a user’s point of view
• Defect – a system fault that occurs while using the software
• Fire – a system fault that is inhibiting significant usage scenarios in the software and must be fixed immediately

Enhancements are requests for improvements to the software based on the perspective of the user. These improvements should be prioritized based on their value against all other Product Backlog items. An enhancement and defect issues are hard to distinguish from one another at times but that is fine. Defects are system faults that users are able to workaround but should not be happening from a user experience and/or technical perspective. Since we are able to work around these defects and the development team is able to provide a fix in the next iteration they are placed into the Product Backlog and prioritized against all other Product Backlog items. Fires are defects that cannot be worked around and cause serious problems for users of the software. In healthy software applications, fires should be a rare occurrence. It is important that a fix is implemented right away and may interrupt the work getting done in the current iteration.

Figure: This flow diagram describes how an identified issue is triaged in an iterative and incremental approach such as Scrum. If the issue is an enhancement or defect that can be worked around for now it goes into the Product Backlog and prioritized based on its value. If the issue is a “fire” or defect that cannot be worked around then it must be fixed immediately. The development will put the fire into their current list of work in the Sprint Backlog and figure out how it effects their commitment to deliver on their current iteration.

Defects are captured in bug databases in many organizations. Teams using the Scrum process to manage their software development find themsves in a predicament. Do we continue working from two lists, the Product Backlog of desired features and bug database? Or do we incorporate items from the bug database into the Product Backlog? I suggest all teams should incorporate defects into the Product Backlog. There are multiple reasons to do this:

• Development team does not make priority decisions for the business stakeholders. If the development team decides to work on defects rather than desired features then they are deciding the defects are higher priority than the desired features without including the Product Owner in the decision-making process.
• Minimizes the amount of hidden work done by the development team. By providing visibility into the defects, the development team is being transparent about the state of the software they are working on.
• Provides the Product Owner with an opportunity to prioritize the defect lower. The Product Owner could decide the defect is not important enough to fix at this time.
• Allows development team and Product Owner to design a solution for dealing with defects. From time to time the defect provides insight into a design flaw that the Product Owner would like to improve.

Ultimately, the development is able to maintain alignment with business priorities for the software. Priorities are decided based upon the full reality of the software, new features and defects included.

A single work queue, such as the Product Backlog, provides visibility to the development team about current expectations about upcoming work. The Product Owner should share the Product Backlog with the development team and discuss the direction of the product beyond the next iteration. As the development team gains knowledge about the direction of the product they will be able to provide input into the Product Backlog. This visibility is important so Product Backlog items do not surprise the development team when it is too late to prepare a proper solution.

AgilePalooza is a one day Agile conference on Friday May 29th at the San Francisco State University downtown campus. There will be two tracks: Learning Agility and Advancing Agility.

“Learning Agility” will be presentation style whereas “Advancing Agility” will use the open space format.

Speakers include David Hussman (DevJam), Chris Sterling (SolutionsIQ), Luke Hohmann (Enthiosys), Lee Henson (VersionOne Services) with special guests Ainsley Nies (open space co-facilitator) and Ian Culling (VersionOne CTO). When not presenting for the “Learning Agility” track speakers will participate in the open space.

Space is limited and the cost is low so please register soon if you would like to attend. For more information or to register please visit www.AgilePalooza.com.

Where?

San Francisco State University Downtown Campus, 835 Market Street, San Francisco. (Powell street BART station in the Westfield Center) – Map/Directions

When?

9am-5pm (check-in and continental breakfast starts at 8am)

Cost?

$69

Register here: www.AgilePalooza.com

ISO 9126-1 Software Quality Attributes

Before I knew about this standard I would discuss how different quality attributes are in conflict with each other. For instance, if we write code that is focused on performance we lose some maintainability. It will be more difficult to read code focused on performance because readability will be sacrificed to some extent.

Now that I’ve known about ISO 9126 for many years, I made a simple spreadsheet tool to interview Product Owners, stakeholders, and software development team members with. Here is the Excel spreadsheet form of this tool:

Software Quality Attributes Rating Tool

Although a bunch of smart people have come up with ISO 9126, I found that modifying the software quality attributes rated in the tool worked more effectively with interviewees. This tool is not to decide what software attributes will be present in the software product getting developed. It is used to identify which software quality factors the team should put more emphasis on when making trade-off decisions during the project. Here is a list of the software quality attributes used in the tool:

• Suitability – Functionality is suitable to all end users
• Interoperability – Functionality interoperates with other systems easily
• Compliance – Functionality is compliant with applicable regulatory guidelines
• Security – System is secure: confidentiality, integrity, availability, accountability and assurance
• Maturity – System components are proven stable by others
• Fault Tolerance – System continues operating properly in the event of failure by one or more of its components
• Recoverability – System recovers from failures in surrounding environment
• Understandability – Able to use system with little training
• Learnability – Supports learning of system functionality with little external interfacing
• Operability – Ability to keep a system in a functioning and operating condition
• Performance – Perceived response is immediate
• Scalability – Able to handle increased usage on the appropriate amount of resources
• Analyzability – Ability to figure out how the system functions
• Changeability – Ability to change the system components to meet new business needs
• Testability – Ability to create repeatable and specific tests of the system and potential for some to be automated
• Adaptability – Ability to change out system component functionality quickly
• Installability – Ease of installation and reinstallation
• Conformance – Conformance to industry and operational standards
• Replaceability – Ability to replace system in the future

Using the tool is quite simple:

1. Emphasis Ranking: Have the Product Owner score each of the software quality factors from 1-5 (1 being less applicable and 5 being more applicable) in terms of the software product.
2. Business Stakeholders identify 3 Must Haves – Ask the business stakeholders what are the 3 software quality factors they want most and stack rank them from 1 to 3
3. Software Development Team 3 Must Haves – Ask the software development team what are the 3 software quality factors they want most and stack rank them from 1 to 3
4. Capture Notes about Decisions – Use the notes column to capture any specific decisions about the software quality factors that would help the entire software product team come to consensus.
5. Discuss Must Haves across Groups – Get the Product Owner, business stakeholders, and software development team members together to discuss and come to consensus on which software quality attributes they will focus on for this project.

Please let me know how you use this tool. There have been many teams that have taken up this tool and found it to be helpful for communicating what is most important from a software quality attibutes point of view in the project. Hope it does the same for you.

I don’t believe that this entry will solve the question but I hope to at least give some focus for teams who are dealing with the structural integrity of their applications. First off, a definition of “architecture”:

architecture: noun – “the art or practice of designing and constructing…” or “the complex or carefully designed structure of something” or “the conceptual structure and logical organization of a computer or computer-based system”

Each of these definitions interests me but to put them to practice is quite difficult. They are left to interpretation about what is design, construction, structure, conceptual, and logical. Earlier interpretations of this term interpreted these to mean the high-level structure, architectural style, and finally the stuff that is too expensive to get wrong.

It seems to me that my interpretation is a bit different. Working with tools, practices, and processes over the past 15 years has guided me to a different conclusion. I believe that architecture is how it is SAID:

Structure – how the pieces (components) create a solution (application)
Alignment – the degree to which the application or enterprise structures align to current business objectives and strategy
Integrity – the components that provide stability to the structure (application or enterprise) (ie. automated tests and builds, service-level agreements, network infrastructure, etc…)
Design – a way to conceptually communicate the planned or implemented structure of a component, application, or enterprise (ie. system of names, XP practice of Metaphor, information radiators, etc…)

Using these as the basic building blocks for teams to focus their efforts can be helpful.

The structure is the reality of the solution’s construction. If the structure is too brittle or complex to support future needs then the structure is not sound. If you have been in the software development industry for even short period of time you have probably seen applications that are too brittle or complex.

If the application or enterprise structures are not aligned with current business needs then the value of those structures have deteriorated. We sometimes keep a specific architecture and force-fit new business needs into it because it once was the right architecture to have or we paid a bunch of money for it. Continual restructuring of our architecture to meet today’s business needs is important.

Providing supports to our structure allows for it withstand changes in the environment such as new business needs and updates in technology. Automated tests and builds help us keep the structural integrity of our applications intact while these changes are introduced into our applications and enterprise.

Communicating the conceptual structure of a component, application, or enterprise is important because it is common for new people to work on them and for those structures to interact with other components and applications. Getting someone up to speed on a component or application involves verbal, tactile, written, and visual examples. Much of what is needed can be kept in or close to the codebase along with conversations with existing developers. It is important to understand how components and applications are currently structure conceptually so we can discuss their interactions with other components and applications. For instance, should we connect via library, SOAP, RPC, or REST?

When I think of application architecture I want to focus on just a few principles:

• Application architecture is about changeability, not longevity
• Application architecture decisions should be made closest to where they are implemented as possible
• Application architecture design is not only about our ability to design a solution but also knowing what components, applications, and solutions already exist
• The value for change in a component’s, application’s, or enterprise’s architecture is directly proportional to the cost of not addressing

If the structure is not able to change as the needs of our business change then the solution will become a liability. If someone other than those who are constructing components and applications are deciding on architecture decisions then there will be important information lost in translation between the two. If we keep using the same design hammer (ie. always using 3-tier or IoC for everything) then we are not allowing the strongest solutions to emerge. The value of architecture can usually be described by the cost incurred if it is not taken care of.

Well, let the onslaught of comments commence. I have put out my ideas on architecture. There are many more out there to discuss and I am sure I will hear some of them. I will finish this entry with a quote from Martin Fowler’s “Who Needs an Architect?” article:

“I define architecture as a word we use when we want to talk about design but want to puff it up to make it sound important.”

SD West 2009 Conference & Expo
March 9–13
Santa Clara Convention Center, Santa Clara, CA
http://www.SDExpo.com/

I’m pleased to announce that I’ll be teaching the following session at SD West 2009:

“Managing Software Debt: Continuing to Deliver High Value as Systems Age” on Friday, March 13th from 3:30-5:00pm

SD West is where the software development community gathers to learn about the latest business-critical technologies, network with peers, connect with innovative vendors and get inspiration from industry visionaries. The comprehensive conference program covers today’s most important topics including cloud computing, concurrent programming, dynamic languages, agile processes, security, testing and much more.

Super early bird conference discounts of up to $400 expire Friday, January 16.  As a speaker, I can also offer you an additional $100 off the VIP Pass. Simply register at http://www.SDExpo.com with the code 9ESPK to get your discount.

Check out all the excellent educational opportunities SD West 2009 has to offer at http://www.SDExpo.com.

I look forward to seeing you in Santa Clara!