5 Reasons to Manage Your Solo Project’s ALM Process

So I’ve been developing software on the Microsoft stack for just over 10 years, and training and consulting on managing software development with VS-ALM (a.k.a. TFS, a.k.a. Team System) for just over 4 of those years. But in all time training and consulting, I was working with teams – from small 5 person start ups, to enterprises with hundreds of users, all using Team Foundation Server (a.k.a. on-premises TFS) to develop their methodology and align their tooling with their products.

Never individuals, though.

Over the years, though,  I’ve had the opportunity to fly solo on several software projects, some short lived, some longer, as have other ALM consultants that I know. One thing we all seem to have in common is that, while as ALM experts, we have all of the skills and knowhow to apply our own trade to the software we develop, we seldom – if ever – do so.

The Cobbler’s Children Go Barefoot…

… as the saying goes. It seems that this proverb applies to our profession as much as it does to others. You’ve seen the doctor who smokes, the out-of-shape coach, the technician or plumber whose own wiring or plumbing is faulty, respectively. Perhaps it’s the same. Perhaps its just that proper ALM is more visibly useful when multiple hands are involved and they must all communicate and interact properly with each other, than when one person holds all roles.

Solo projects seem to need no management, I believe they only seem to.

Here’s why:

1. If You Don’t Use Source Code Version Control, You’re an Idiot!

I apologize for the vehemence. Let me rephrase this. If you don’t use some kind of source code version control, you’re an inexcusably dense idiot who deserves what he or she gets when you lose your source code!!!

I guess I couldn’t rephrase it without the vehemence. Lesson learned.

Beyond the fact that having some kind of backup, preferably online, means that even if you lose your laptop, or accidentally delete your source files, you still have a copy of your code, version control means that if you make a mistake, you can still rollback to that point in time and fix whatever you did wrong. Having a historical log of the changes you made to the software can also serve as release notes of sort, and a rudimentary list of the features and bug fixes you have, and even help establish some kind of time line.

Really though, version control is about security for the code – protection against loss and against mistakes. you should use it as frequently as possible.

Note that you do not need to shell out huge amounts of money to be able to use version control. In fact, as in life, so with version management, the best things are free!

I prefer using Git. You can use it locally with any operating system (Windows, Linux, Mac OS), and there are multiple online tools that work and synchronize with Git, all free: GitHub, CodePlex, and (my personal favorite) Visual Studio Online. There are, of course, other version control systems, both distributed and centralized (Mercurial is another DVCS, Subversion is a great free centralized one).

Heck, even use DropBox or some other online-syncing file-storage, just beware that it won’t protect you from deleting your code, nor will it let you rollback – but at least you’

2. Defining (just enough) Work Upfront = Less Code Writing and Rewriting

Much like TDD tends to limit the amount of production-code you write, so does defining your work. In fact what is TDD, if not the definition of a small amount of work that needs to be done to the system, along with a definition of how to know when you’re done? The same holds true for defining a development task, a user story (a.k.a. a product backlog item, or PBI) or a feature; each is an elaboration of the higher level: Feature to user story, to task, to test. When you know what needs to be done, and you know when you’re done, you know exactly what the remaining work is. That saves time.

And let’s be clear. Just enough is key here. Too little, and you’ll rewrite anything that you haven’t properly thought out and planned. Too much, of course, and changes to the reality surrounding the project and your perception of reality will bring rewrite to your plans.

3. Project Planning Makes it Possible to Plan Releases

Unless you are truly working on a hobby for yourself, you still need to be able to answer at least these two questions:

1. When will it be done?
2. What will be done by a certain date?

Without estimating the work you have to do, more so if you don’t even know how much work you have, you simply will not be able to give more than a POOMA estimate.

Note that unless you live alone, you might still need to answer these questions, if only so your partner, roommate or parent will know when you will finally clear the garage (or dinner table) from your junk.

4. Automation Reduces Human Error as well as Manual Labor

Even if you are a solo programmer, two things remain invariably true for you:

1. You’re only human.
2. You’re only one human.

Being only human means that as talented as you may be, you are still prone to repetition based errors. You’ll forget to update the version number, or forget to set the build configuration to Release, or forget to run the tests, or any number of things. When I train new developers, especially in those early days when they feel that the fact that they’re constantly making errors, and more experienced developers must be demigods or some such, in an attempt to reassure them (and lighten the atmosphere), I tell them this:

• There are only two kinds of developers: experienced, and inexperienced developers.
• Inexperienced developers make only two kinds of mistakes: Mistakes born of inexperience, and mistakes born of stupidity.
• Experienced developers make mistakes only born of stupidity

Aside from the fact that this is inherently true (an experienced person, by definition, cannot make a mistake born of inexperience), it is important to note – experienced developers make mistakes!

Computers do not. Ever.

Another saying that I’m fond of repeating, the former statement being a key reason to do so, especially when consulting and or training clients on the use of ALM tools, is to never let a human do a machine’s work (and vice versa). Anything a machine can do, we shouldn’t.

Finally, there’s the fact that any time spent on doing what someone, or more importantly, something (i.e. your computer) could do, is time not spent on things only you can do (i.e. developing the product – which you’d probably prefer to do anyway). Ask yourself this – while you’re manually doing repetitive work – who is coding? Nobody.

This holds true for building, for testing, for releasing and deploying, and basically for anything that you can (and know how to) automate.

In all but the simplest and most straightforward scenarios (usually short-term, one-shot projects), you should find ways to delegate work to a machine.

5. Defining the Work Makes Change Management Easier

It’s all great when you’re hacking away at that pet-project of yours and you’re in the zone, but a week later, a month or even three later, once you start delivering a second or third release of your software, keeping track of what was done, when – not to mention writing release notes, becomes extremely difficult, if you don’t know what your changes are or were. In fact, if you use an ALM tool for tracking features, changes and defects, and associate them with automated builds, you can generate a release notes document automatically with every build, and not have to deal with it yourself.

The other kind of change, is change of management. Today this may be your solo project. Tomorrow, who knows? You may take on a partner, give someone else the code to maintain, or decide to open the source. If the only definition of the work is whatever lies inside that wonderful brain of yours, hand-off will be a bear. Trust me. I’ve had to waste two weeks once receiving a project, and I still don’t know everything about it. Finding out stuff on my own is not the best use of my time. Having a nice set of features, tasks and bugs (past and open both) shortens the time, and makes discovery pains all but gone.

Conclusion

In summary, I’d like to state my opinion that in most (again, all but the simplest and most straightforward one-shot) software projects, proper ALM is as useful and important when flying solo as when developing with a team. Lack of communication issues (though see point #5) are balanced by the increase of work of having to do it all by yourself.

Just do it right the first time. You’ll thank me for it.

Best Regards,
Assaf Stone
Occasional Solo Developer

Technorati Tags: ALM,Software,Development,Testing,Building,Code,VCS,Git,Solo

12 Revs of Software

A Version from St. Service Bus

’Twas the week O’releasing, and all through the teams,
Not a programmer testing, at least so it seems.
The builds barely holding, the crashes abound,
In hopes that some luck, or a safe place be found...

[Enter the choir. You can sing along. You know you want to…]

The Twelve Revs of Software

On the first rev of software, my dev team dropped on me
A piece of software that I can't release.

On the second rev of software, my dev team dropped on me
Two breaking smoke tests,
And a piece of software that I can't release.

On the third rev of software, my dev team dropped on me
Three days till deadline,
Two breaking smoke tests,
And a piece of software that I can't release.

On the fourth rev of software, my dev team dropped on me
Four tests a-failing,
Three days till deadline,
Two breaking smoke tests,
And a piece of software that I can't release.

On the fifth rev of software, my dev team dropped on me
Five bugs regressing,
Four tests a-failing,
Three days till deadline,
Two breaking smoke tests,
And a piece of software that I can't release.

On the sixth rev of software, my dev team dropped on me
Six missing specs,
Five bugs regressing,
Four tests a-failing,
Three days till deadline,
Two breaking smoke tests,
And a piece of software that I can't release.

On the seventh rev of software, my dev team dropped on me
Seven bosses angry,
Six missing specs,
Five bugs regressing,
Four tests a-failing,
Three days till deadline,
Two breaking smoke tests,
And a piece of software that I can't release.

On the eighth rev of software, my dev team dropped on me
Eight devs on sick leave,
Seven bosses angry,
Six specs a-missing,
Five bugs regressing,
Four tests a-failing,
Three days till deadline,
Two breaking smoke tests,
And a piece of software that I can't release.

On the ninth rev of software, my dev team dropped on me
Nine queries locking,
Eight devs on sick leave,
Seven bosses angry,
Six specs a-missing,
Five bugs regressing,
Four tests a-failing,
Three days till deadline,
Two breaking smoke tests,
And a piece of software that I can't release.

On the tenth rev of software, my dev team dropped on me
Ten seconds lagging,
Nine queries locking,
Eight devs on sick leave,
Seven bosses angry,
Six specs a-missing,
Five bugs regressing,
Four tests a-failing,
Three days till deadline,
Two breaking smoke tests,
And a piece of software that I can't release.

On the eleventh rev of software, my dev team dropped on me
Eleven builds a-crashing,
Ten seconds lagging,
Nine queries locking,
Eight devs on sick leave,
Seven bosses angry,
Six specs a-missing,
Five bugs regressing,
Four tests a-failing,
Three days till deadline,
Two breaking smoke tests,
And a piece of software that I can't release.

On the twelfth rev of software, my dev team dropped on me
Twelve months were wasted,
Eleven builds a-crashing,
Ten seconds lagging,
Nine queries locking,
Eight devs on sick leave,
Seven bosses angry,
Six specs a-missing,
Five bugs regressing,
Four tests a-failing,
Three days till deadline,
Two breaking smoke tests,
And a piece of software that I can't release...

Final Round...

He sent résumés, to his team gave a whistle,
“This product is dead”, he said this Fo’shizzle.
If you do it at all, then perhaps do it right.
Happy coding to all, and to all a good night!

 

 

 

 

 

A very special thank you to my good friend Maor, who reviewed, QAed and wrote the first verse of the Version of St. Service Bus.

P.S.

This post was supposed to go up on Monday, before Christmas Eve. Unfortunately, I, too, missed my deadline.

Happy New Year.

P.S. 2

My New Year’s Resolution is Retina.

Technorati Tags: Agile,Build,Test,TDD,Release,Version,Software,Delivery,Revision

Why Should I INVEST in User Stories?

INVEST is a another great acronym from the Computer Sciences industry, Department of Agile (yes, DOA, and I’m well aware – thank you very much); It stands for Independent, Negotiable, Valuable, Estimable, Sized (or Small), and Testable. Those are indeed valuable attributes of User Stories, of any kind of requirements at all, and the acronym itself implies some effort on behalf of the creator of user stories (i.e. the Product Owner), with a potential return on investment.

But that isn’t good enough. A catchy name may be enough for most developers to try something new (seriously, when does a developer ever need a reason to try something new?), but not so for management. To many managers, however, this can sound like Impossible, Not-gonna-deliver, Vague, Everything-is, So-what, and Test-the-whole-goddamn-project!

In this post, inspired by a twitter-conversation I had a while ago, I hope to explain what this INVESTing in user stories really means, and why it is worth doing.

I is for INDEPENDENT

In my opinion, writing independent user stories will be your single greatest return on investment (no pun intended – this time). In one of my recent posts, I described how work items (stories, tasks, features, etc.) are far more likely to complete later rather than earlier if they more than one dependency, while having just a single dependency (i.e. starting the new item is simply dependent on completing the previous one) will  increase the likelihood that it will complete on time.

Of course, most of the work in writing good user stories is in this part as well. You are required to reimagine how you think of your work. You need to do away with layered one-shot thinking that is probably necessary in every industry except software. Since the actual construction of the software is for all intents and purposes near-instantaneous, you can (and should) think about vertical increments of value, when you come up with your requirements. Each such story should be worded so as to be independent of any previous (or forthcoming) stories.

In some cases, you may find it impossible to break a story’s dependencies, no matter how you try. In those cases, try to look at the story with its dependencies as a single story. Find the commonality of them and reimagine it.

To summarize – Independence in your stories will translate directly into increased probability of delivering on time!

N is for NEGOTIABLE

Let’s get one thing clear: This attribute is not a copout for developers! A story’s negotiability does not give developers the right to decide not to do it. The developers do not decide what the story will be, what its scope is, when it will be delivered, and what is required to make it complete. Oh, the developers can and should discuss the story and its impact with the PO, and the PO may decide to change the story based on developer input, but it is ultimately the PO’s right (and responsibility) to make any changes to the story.

The full meaning of negotiability, is that the contents of the story (i.e. scope, priority, requirements) can be changed at any time, from the moment they are introduced, and up until the the developers commit to it (i.e. the beginning of its sprint).

This is perhaps both the easiest attribute to add to your user stories, and the hardest. It is easy, because it requires no extra work from the PO or team. It is hard, because it may require you to let go of any preconceptions you may have of the story (i.e. those you had when you first wrote it). It requires you to allow people to move your cheese.

The return on this investment is quite valuable, however; Your stories will be rejuvenated, and will be more valuable to the customers and user, because they have been recently revalued, evaluated and updated. This attribute is particularly synergetic with the next one:

V is for VALUABLE

You’d think that given the high premium on the time of developers, and the fact that most projects are running late, as it is, it would go without saying that everything we develop is valuable. Unfortunately that is not the case. According to the CHAOS Report, by the Standish Group, fully 64% of developed functionality is rarely or never used!

All of these features have something in common: They were added without any consideration of their value or necessity to the users or the customers!

The valuable attribute of user stories helps reduce these numbers, by making sure that anything and everything the team develops has value to the users. When the PO comes up with a story, and cannot find a way to describe its value, it is possible that there is no value. Our tendency to add these valueless stories to the product comes from the traditional idea that you have to define everything upfront, or it won’t be in the project. Thanks to negotiability, it is possible to focus only on what is valuable.

This attribute also protects the system from developers’ desires to build a framework (we all love developing frameworks – it’s a conditioning or something), or do any work that doesn’t translate into value to the customer. If some technical work is required for some story, add the work as a task to that story, not as a technical story; this will more clearly radiate to management what is required to complete a story, and will give the PO the ability to consider this extra work and its impact when evaluating the story.

E is for ESTIMABLE

There is a lot of good literature out there on how to estimate properly. While there are several, equally viable techniques out there for estimating, everyone pretty much agrees that relative estimates are easier than absolute ones, and smaller items are easier than larger ones. For more info on how to estimate properly, you can read my previous post on the subject, here.

There is more to it, though, than just the techniques. The story should be clearly scoped. There should be a beginning and an end.

Imagine a story such as “As a user, I want a text editor, so that I can take notes”. How much will it take to develop that? I have no idea. If the user only needs a multi-line textbox with persistence capabilities, then I can probably have it done in a few hours (yes – a few hours, because nothing ever takes just 5 minutes!). If the user is expecting RTF capabilities with copy and paste, it’ll take longer, and if he’s looking to give MS Word some serious competition, it’ll probably take a few man-years (just guessing here; It’s too big for me to give a good estimate).

I see estimability as the culmination and grounding of the next two attributes, Size and Testability (see below).

S is for Size

“Sized Appropriately”, or “Small”, as some call it means that the story is small enough to estimate. In Scrum, and other time-boxed methodologies it is expected that the story will be scoped in a way that makes it possible for the team to complete a few of them in one sprint – at the very least, they should be able to complete one story.

This attribute requires the PO to define in detail what it is that he wants the team to deliver. In many cases, the actual user stories that the team works on are the elaboration of the broad scopes defined in the “Epics” or “over-stories” or “super-stories”.

What the PO gains is the ability to release early and often. The team get the ability to create less complex solutions, because the problems are smaller.

Remember, the story should be defined in terms of their business value, not the implementation details! The details are to be left to the developer tasks, and are of no interest to the users or customers.

T is for Testable

Testability basically means that it is possible to test the product to see if it fulfills the requirements of the user story. A testable user story has a finite and measurable set of acceptance criteria, by which it is possible to prove the validity of the product.

This last, but most certainly not least of attributes serves everybody who has a stake in the product:

• By defining the story’s acceptance criteria, the PO has the opportunity to define more specific demands of the story, than what appear simply in the “title” (“As a… I want… so that…).
• Both the Developers and the QA gain an understanding of what the scope of the story is and what it is not, thus reducing a great source of contention about whether something is a bug, or a new feature (if I had a penny…)
• Stakeholders gain an understanding of what they are going to receive by the release.

The acceptance criteria, like the rest of the story, should be worded in the product’s domain language, which means that they should be defined in the users’ terms, rather than the developer / QA terms.

The return on your INVESTment here should be obvious: The PO gains a tighter control of what will be produced, without unnecessarily elaborating on the technical solution, while the developers and QA have a better understanding of what they are required to do.

In conclusion

I think that every part of the INVEST model has value. Stories that you have invested in will be:

• More likely to complete on time
• Current and updated
• Valuable to the customer and / or the users, with less unnecessary technical fluff
• Clearer, with less dissonance between POs, developers and testers
• Less complex to develop, easier to test, and quicker to get feedback as well as quicker to deploy
• Easier to prove and validate and quicker to gain acceptance by the customer / user

That’s all. I think it’s a worthy goal, well worth the cost. What say you?

Technorati Tags: Agile,Scrum,User Story,INVEST,test,estimation

How to Write Automated Tests for Console Applications

I don’t know about the rest of you, but I still find myself writing a lot of console applications. Most of the time these are utilities or services or some kind of customization or process automation scripts. Until recently, if I wanted to write automated tests for these, I would have to separate the business logic from the program itself and test the functions. While this is obviously a good practice for any moderately complex project, it sometimes might be overly complicated for what is needed. Moreover, this doesn’t work for black-box user acceptance tests.

The System.Console Class

In the .NET Framework console apps revolve around, well, the Console class. You get user input with Console.Read() (and ReadLine(), and ReadKey(), and so on). Conversely, you send output to the user with Console.Write() and Console.WriteLine().

So let’s take a look at the code inside the .NET Framework. By the way, I used Telerik’s JustDecompile to browse the code. If you don’t already have a decompiler of choice, I suggest you take a look at it. It’s simple, elegant and free (and no, I don’t own stock).

So, here's the code behind Console.ReadLine():

   1: public static string ReadLine()

   2: {

   3:     return Console.In.ReadLine();

   4: }

And here’s Console.WriteLine():

   1: public static void WriteLine()

   2: {

   3:     Console.Out.WriteLine();

   4: }

As it turns out, Console’s read and write methods are merely pass-through methods that call the same methods on the In and Out TextReader and TextWriter properties (again - respectively).

The text reader and writer classes, as so eloquently put in the class descriptions on MSDN, “represent a reader [and writer] that can read [and write] a sequential series of characters”. Well, that still is more helpful than some descriptions I’ve seen... Anyway, they are the abstract parents of the string and stream reader (and writer) classes. Why is this important? Well, the In and Out properties are by default set to the keyboard input and screen output streams.

Now, if only there was a way to redirect those streams…

Enter Console.SetIn() and Console.SetOut() respectively. Hmm, that’s a lot more respect than I usually show in a blog post…

With SetIn, I can redirect the In text-reader to a StringReader, and with SetOut, I redirect the output to a StringWriter.

I can now, quite easily initialize the string reader to a value that contains whichever input, or set of inputs I want to use, and the console application will read characters or lines as needed. I can then read the output of the string writer, and compare it with expected results.

And the most beautiful part of it is that there is (almost) no need to modify the console application in any way for this to work.

Example

The following example was written in C#, using MS-Test (forgive me) to test the code. The application is a simple one that plays the game 7-Boom (a local variation of the game BizzBuzz). As you will see, except for making the Program class and Main() method public in lines 1 and 3, so that I can reach the code from another (test) assembly, I did nothing I wouldn’t do in any other console application:

   1: public class Program

   2: {

   3:     public static void Main()

   4:     {

   5:         Console.Write("Enter upper limit: ");

   6:         var range = int.Parse(Console.ReadLine());

   7:  

   8:         for (var i = 0; i < range; i++)

   9:         {

  10:             var num = ((i % 7 == 0) || i.ToString().Contains('7')) ? "BOOM" : i.ToString();

  11:             Console.Write("{0}, ", num);

  12:         }

  13:     }

  14: }

And here is a test:

   1: // Arrange

   2: using (var sw = new StringWriter())

   3: {

   4:     using (var sr = new StringReader("100"))

   5:     {

   6:         Console.SetOut(sw);

   7:         Console.SetIn(sr);

   8:  

   9:         // Act

  10:         SevenBoom.Program.Main();

  11:  

  12:         // Assert

  13:         var result = sw.ToString();

  14:         Assert.IsFalse(result.Contains('7'));

  15:     }

  16: }

That’s it! I set the input that the user would have entered in line #7, and redirect the I/O in lines 6-7. All that remains is to assert that the output in line #14 meets the expectations.

By the way, this works exactly the same in Java as it does in C#. The difference is that in Java you will use System.setIn() and System.setOut() to set the PrintStreams (the In and Out properties used in Console.Read & Console.Write).

So now you can write test-driven (and behavior driven) console applications with greater ease.

Hope this helps,

Assaf.

Technorati Tags: Agile,BDD,C#,Java,TDD,Test,Unit Tests

A Software Developer’s New Year’s Resolution

Or: 5 Things You Can Do Today to Improve Your Software Product

New Year’s eve is around the corner. It is the end of this year, and there’s a whole new year full of potential to be better, just waiting to begin. So how can you make it better? If you, like me, are a professional developer, then you can improve your life (and your boss’s and your team’s) by reducing software delivery related stress. Here are 5 things you can do, effective immediately, to make your product better:

1. Make a Version Management Plan

If your version control system is a mess, the first thing you should do is straighten it out. If you are not using one, then you should begin doing so immediately. There really is no excuse not to do so. For starters, there are plenty of high quality tools out there that are open source and free (git, mercurial, and subversion are the most common ones), as well as other commercial tools (I happen to use and consult on the use of Microsoft’s TFS). Either download and start using a free one, or get one that offers a trial period.

If you are using a VCS, but it’s a mess, and you find yourself mired deeply in merge-hell every time you want to deliver your software (internally or externally; it doesn’t matter), then you should straighten it out. Unfortunately, if you have a considerably sized source repository, this may seem as an impossible endeavor. Here’s one way to alleviate at least some of the pains of software delivery, in a few easy steps:

1. Create a new root-level folder named sources. This folder will contain your new source code repository.
2. Create a branch from your current repository, and call it main (e.g. /sources/main). This will represent your latest and greatest version, and should be kept as stable as possible, at any moment. No development will be done on it; you will only merge completed changes into it.
3. Create a branch from main, named dev (e.g. /sources/dev). This branch will be the branch that developers work on to create new features, checking code in and out from there. If there are multiple independent teams, you may have multiple dev branches.
4. Create a releases folder, which will contain release branches from main. Every time you wish to release your software (internally or externally), create a release branch from main (e.g. /sources/releases/1.2).

This is just one possible branching plan. It works particularly well for agile development, where effort is made towards developing as many features as possible before a release, merging them into main when ever they are done, and branching when the iteration is over. Note the following division of work:

• New features are developed only in dev. They are merged back into main when completed.
• Fixes are developed on release branches and reverse-integrated into main, and then back to dev, so that they won’t get lost.

This structure allows you to develop new software and stabilize a release at the same time without one effort polluting another. It is also a step towards being able to release a new version anytime.

If your development and release mechanism is well established, but not suited to fit this branch plan, make one that does work. Just make sure to be able to support feature and fix separation as well as the ability release anytime you need.

2. Automate Your Build

Even if all you do is copy sources from the repository to some drop folder, you have some sort of a build process. Automate it. Even just a part of it. Even just the compilation phase. Every step you let a computer do rather than yourself, is one less step to worry about. If you aren’t already using an automated build tool, you should start now. There are many open source tools as well as commercial ones. Most are powerful enough to suit your needs. Remember – If you can run it from command line, you can automate it as well.

Every time you run the build, you will not only create a deployment package of your system, but you will get a good indication about the health of your product (if the product doesn’t build, you will want to know sooner rather than later). Additionally, you will have the start of a platform for testing the system.

For a synergetic benefit with your versioning plan, schedule the following automated builds:

• Build the software every time you check in changes to your code (on dev or a release branch); most build and VCS tools support this – it is called continuous integration.
• Build the software every time you wish to merge dev to main. It is even better if you require a successful build as a prerequisite for the merge. This is called a gated check-in in many tools.
• Schedule a nightly build on main. This will let you know what the state of your system is. Fix any problems here first. Keeping a healthy build will allow you to deliver software at the drop of a hat. Amaze your PM!

3. Add a Health Report

Even a simple email message to the team in case a build fails will greatly improve your ability to fix problems with your software. Shorter feedback cycles means that you can fix problems when their causes are still fresh in your mind! Let your build system email you if it fails. Almost every system supports it. Conversely, you may wish to post successful build reports to some company wiki. Let everyone know of your successes.

4. Add an Automated Test

While the benefits of TDD as a design mechanism are far greater than just having a suite of tests, we should not belittle the benefit of an automated regression test. Even a simple record & replay automated smoke test, with a black-box test tool will greatly improve your system. Start with a single test that runs through as many parts of your system as you can easily manage. (Note – this might mean you need to add a deployment action to your automated build). Report if it fails. Run it every time you build. The more tests you add, the greater confidence you’ll have in your build system! Maintain your tests; fix any tests that fail due to legitimate changes and remove those that are no longer relevant. You don’t want your system to cry wolf!

5. No Broken Windows!

The most important thing you can do is to make a new year’s resolution that you will not suffer any problem with your software delivery lifecycle to remain unfixed! Once you fall off the wagon, your system will start to decay back to uncontrollable chaos. Think of maintaining your ALM like brushing your teeth. You may not like it but you do it every day (more than once), or your teeth will rot out until ultimately you won’t be able to eat!

In conclusion,

My new year’s resolution is to vigilantly keep my teams’ products “on the wagon”.What is yours?

Happy Holidays, and Happy New Year!

See you all next year,

Assaf.

Technorati Tags: Agile,Build,TDD,Test,Report,Version Control