Written by James on
Wednesday, 21 of November ,
2007 at 7:49 am
Today I was reading about the medical practice of triaging and thinking about how it relates to software development. A software development triage is a common practice for projects in trouble. So how does one set-up a successful triage for their project?
What is a triage?
A triage is a way of rationing limited medical resources, typically in the event of a disaster. The purpose of a triage is not “normal” medical treatment, which seeks to help and heal everyone receiving treatment. A triage is setup to let people die by intentionally denying them treatment so that others more likely to survive can receive treatment. The result is a net gain in the number of lives saved.
What does this have to do with software development?
For a failing project, a triage is setup to let features, requirements, and bug fixes “die” so that others may be implemented. The importance of the task-at-hand is secondary to the probability of success.
This can sound counter-intuitive: Why would you complete less important tasks and let more important tasks die? Two reasons:
- You will have tangible results, and more of them.
- It will force stake-holders to increase the probability of success for the tasks most important to them, which means that more tasks can be completed.
How does a software development triage work?
Just like with a medical triage, tasks are “tagged” to indicate their priority, based on their likelihood to succeed.
- Tasks that cannot realistically be completed within project constraints (time, quality, budget), get marked and left to “die.”
- Task that can be completed within project constraints, but are at high risk failing get immediate attention.
- Tasks that can be completed within project constraints, and are at moderate to low risk of failing get prioritized accordingly and receive attention after the high-risk (but possible) tasks.
Once a triage is setup, it is important to constantly monitor it. Tasks “left to die” may receive the resources needed, and tasks that were once low risk may suddenly become high risk (if this happens often, consider a reverse triage).
Just as a medical triage consists of controversial and difficult ethical decisions, a software development triage will consist of similar business decisions. It is therefore a politically difficult thing to do, so be sure your project is truly in need.
Once the project is back on track, the triage should be ended and regular development should resume. Just be sure that “regular development” is not what created the need for a triage in the first place!
Category: Best practices
Written by James on
Tuesday, 18 of September ,
2007 at 8:33 am
Build automation is the foundation of continuous integration. Continuous integration helps to identify problems quickly - sometimes immediately - before they delay your project. Whether a continuous integration build is executed immediately upon check-in or scheduled to run nightly, at the heart of it lies the automated build process. (For an excellent, detailed article on continuous integration, see Continuous Integration on Martin Fowler’s website).
So how does one create an effective automated build process? Just like any other project, stay agile: start with fundamental tasks, then add complexity based on the needs of the project. Don’t get stuck creating the Ivory Tower of build processes.
Start with the Basics
The most fundamental steps of an automated build process are:
- Get the code.
- Compile the code.
- Report what happened.
Between compile the code and report what happened, some choose to add deploy; however we’ll cover that in the next section, Baby Steps.
Get the code. Most version control tools, such as Subversion, are relatively easy to automate. Early versions of your build process will probably check-out the most recent version of the code from the trunk. However, as the process continues to develop, it may look to specific build branches in the version control repository or to specific revisions. Be sure that your script checks out all the code needed to successfully compile, including any shared libraries. If supporting shared libraries is too much of a chore, be sure to look into the practice of using externals (don’t just make copies of everything!).
Not using version control? Well you should be.
Compile the code. This is the most basic test of your code - if it doesn’t compile, it’s just text. When scripting this part of the process, keep in mind the correct build order, compiler options, and other switches (is this a debug, test, or release build?). For example, you probably want to enable detailed logging in test builds and probably always want to build the installation project last.
Report what happened. Some choose only to report errors, quipping “no news is good news.” This is true until you discover there was an error sending out error reports. So I recommend reporting everything that happens, even if it’s just to say “everything went well.” The report its self can be in the form of an email, an update to your projects Wiki, an entry in your tracking system, or all of the above. (To give an interesting example, I once saw a traffic light being used - red for complete failure, yellow for warnings, green for success).
Unless your project takes a long time to compile, these three basic steps probably won’t save you a lot of time. However, they do lay the groundwork for the more time-saving features that are further discussed below.
Baby Steps
Once the basics are done there are a few simple, arguably fundamental, features that should be added to the process to save amazing amounts of time. Some of these essential tasks are:
- Unit test
- Document
- Deploy
Unit test. If you are, or want to be, an Agile team you have probably already implemented unit tests using JUnit, NUnit, or a similar framework. If you are not unit testing, pick up one on of the Pragmatic Unit Testing books to find out what you’re missing and how to correct the situation. If your unit tests are already automated via a framework, simply call them during the build process. Make sure to be aware of tests that will interfere with external environments and only call such tests when it is safe. The XUnit frameworks have ways of categorizing and tagging each test and groups of tests, so identifying the correct tests to execute should be an easy task.
Document. If you are using a tool such as Javadoc, NDoc, or SandCastle then your automated build process is the ideal time to extract documentation from your code. Documentation extraction can be a lengthy, boring process that utilizes a significant portion of your CPU so it’s great when it can be done automatically for you on another machine or at least while you’re away getting coffee.
Deploy. This can be as simple as copying files to a “latest version” directory or, as your build automation script evolves, can become a full-blown installation complete with test data generation. Better yet, several installations could be created to represent common [test] environments. In some instances “deploy” is actually a live deploy; I’ve most commonly seen this used for content-only updates to websites.
Taking it to the Next Level
By now your build process should be helping out a lot: Developers are spending less time trouble-shooting and more time coding and QA is spending less time setting up environments and more time testing. So what next? Here are some ideas:
- Expand what you already have
- Get the timing right
- Enhance communications
Expand what you already have. Just keep improving what’s there, adding a tweak here and a nudge there to the existing build process. Improve reporting by hooking up that traffic light or updating that dashboard. Expand testing by adding all of your automated test suites (stress tests, integration/system tests, etc.). Continue to improve the deployment process by introducing virtualization, generating random test data, or synchronizing development, test, and production environments.
Get the timing right. As you expand what you already have, the build process may begin to take too long. You will also notice that not everything your build process does needs to be done every time. This is the time to start separating out different “types” of builds, and executing them when necessary. For example, a unit-test build can probably run on every check-in or several times a day; however a build that runs stress tests may need to run nightly so that humans aren’t bothered by bogged-down systems. This may also be the time to move to a build-server if you haven’t already.
Enhance communications. Have your build-process update your project repositories (version control, task tracking, wiki, calendar, and so on) with information from the latest build. For example: if bug-fixes have a “Pending Build” status in your task tracking application, your build process should mark them as “built” and forward them on to QA for verification. For milestone builds, you may want to automatically tag the code. If three builds fail in a row, a meeting could be automatically scheduled. You could add a code churn report to the project wiki.
Get the idea?
It’s OK to Have Fun
From traffic lights and cha-ching! sounds to text-messages indicating that it’s been a week free of build failures and it’s time for pizza and beer; it’s OK to have some fun with your build process… and it’s much easier when that process is automated.
Category: Best practices, Agile, Automation, Version Control, Quality Assurance, Continuous Integration
Written by James on
Monday, 2 of July ,
2007 at 12:28 pm
The following list of tools are useful for practically every software development project - onshore or offshore, distributed or local. Often, however, these tools are overlooked and a lot of time gets wasted trying to solve problems that could have been solved or mitigated by good tools. Let’s take a look at an overview of these time and headache saving tools. Follow-up articles will explore best practices about each tool more in depth.
Version Control
Imagine having a time machine for your project, allowing you to go back to any point and time and see exactly what the project looked like - the tests, the documentation, the code, the databases - everything. Even better, this time machine would let you change the past and investigate alternative futures by creating parallel time lines which could then be merged together! This is not fantasy or a scene from Back to the Future, it’s version control. It seems fundamental, but there are still many large software projects out there not using version control. Probably the best version control system available is Subversion.
Project Task Tracking Tools
How much smoother would your project be if bug reports, feature requests, and other “to do” items for your project suddenly stopped falling through the cracks? Stop scribbling notes on napkins and trying to sort through multitudes of email. Just put everything in one of the many (seemingly thousands) of well-design tracking system out there. A good tracking system can accept requests via email, allows assignment of tasks, and let’s you easily set priorities - even on multiple projects.
Test Automation Tools
Wouldn’t it be nice if, at the push of a button, you could execute every single test written for your project at super-human speed? While you went and got coffee? That’s what test automation tools can help you do. Of all the different categories of automated testing, unit testing is perhaps the most fundamental. Start there, and work your way up to more complex tests.
Build Automation Tools
Imagine always knowing, with confidence, how the changes from this week affected the changes from last week. Imagine if the latest features of your software were built and tested by the time you woke up each morning, before you even knew you’d have to give a demo that day. If you were making use of one or more good build automation tools, you could have that.
Wiki
Wikipedia has managed to document the majority of human knowledge in a vast online database. Case an point: every external link in this article is to Wikipedia. Wouldn’t it be nice if your project’s documentation was that good? If a bunch of anonymous internet users can do it, so can your team of professionals.
Category: Best practices, Agile, Automation, Version Control, Quality Assurance
Written by James on
Monday, 21 of May ,
2007 at 9:25 am
Is design dead? The short answer: no. The long answer is in this classic article by Martin Fowler. It covers misconceptions of where design practices fit into XP.
It’s a long article and if you need to read it but don’t have time, consider the irony that you do not have the time to read articles which will save you time. Then make time.
Some of the key points are:
- Design only as far as it is useful.
- Treat a design as a “sketch” - not a decision set in stone.
- Don’t be afraid to throw out some or all of a design.
- Code should be comprehensive, design documents should cover only what is most important.
- Designers need to be coders.
Category: Best practices, Agile
Written by James on
Friday, 11 of May ,
2007 at 8:35 am
Communication issues abound in the corporate world. With offshoring, such problems can become exaggerated to the point of exasperation: Not only can you not work with your team face-to-face, but there are timezone differences, and language barriers can cause misunderstandings and frustration.
It does not have to be this way. Here are some simple tips to use when communicating with an offshore team. Combine them with other good communication strategies, and your offshore endeavors will be as efficient as any.
When on the phone… Speak slowly. Verify that the listener understands you. Enunciate. Try to minimize your accent if you have one. Some people have a tendency to shout when speaking to someone with an accent, try to avoid this.
When sending emails or IMs… Use good netiquette (don’t type in all CAPS, use excessive punctuation, etc). Be forgiving by assuming a helpful tone even if it is not apparent – it is probably cultural, not personal.
When instant messaging… Send complete sentences. Not. Fragmented. Messages. That. Must. Be. Pieced. Together.
When communicating requirements… Explain “what” and “why” – not “how” a feature should be implemented. Do not assume that the offshore team has the industry or internal system knowledge that your employees take for granted.
When asking for help… Often, offshore team members will make every effort possible to help you with an issue or to understand how something works. Do not over rely on the helpfulness of the team, as it does take away time from other duties. Make sure that any questions you have for them are complete, and well thought out.
In general… Be concise. Avoid idioms. There is typically no need to use simpler words. Do not be afraid to ask that a difficult sentence be reworded, and be patient if asked to do the same.
If you feel that “best” practices aren’t giving you the best results, you may want to consider bringing in a third-party to aid in identifying and solving problems with communication. Art of Progress has consultants available; email artofprogress@artofprogress.com for more information.
Category: Best practices, Offshoring