The Software Management Blog

Continuous Integration Refcard

This week DZone publishes a new refcard on Continuous Integration patterns and anti-patterns. Paul Duvall of Stelligent, also co-author of Continuous Integration: Improving Software Quality and Reducing Risk, presents a set of tried and tested patterns that can help avoid the pitfalls of CI in the enterprise.

From the DZone website:

Continuous Integration is the process of building software with every change committed to a project’s version control repository. This DZone Refcard will walk you through 40 different Patterns and Anti-patterns associated with CI and expands the notion of CI to include concepts such as Deployment and Provisioning. The end result is learning whether you are capable of delivering working software with every source change.

One of the things I like about the DZone refcards is how much information they can pack in such a small package. Whenever I find myself looking for some piece of quick information it is always easy to reach to a refcard before picking up the big book. And the best feature? These puppies are free. I can’t believe DZone is not charging for this information.

Deployment Automation Webinar from XebiaLabs

The guys over at XebiaLabs are hosting a webinar on how to automate the deployment of J2EE applications down to a few mouse clicks.


Date: January 21th, 2010
Time: 10:00 AM EDT
16:00 PM CET
URL: http://www.xebialabs.com/do-you-want-deploy-your-enterprise-java-ee-applications-no-more-a-few-clicks

XebiaLabs provides the new generation intelligent deployment automation software solution for your mission critical applications. Deployit offers end to end deployment automation for IBM WebSphere,Oracle WebLogic, JBoss and Apache.

In this 45 minute webinar you will discover how system administrators and developers can speed up deployments, eliminate configuration errors and gain a complete overview and full control over the middleware environment.
Save costs, reduce errors and improve quality.

Announcement: 64clicks is Online!

Finally, after months of hard work, I am happy to announce that 64clicks is officially launched! Many thanks to all employees of Red Black Tree, business associates, interns, friends and family members for their help during the incubation period of this exciting start up.

64clicks is a new Web 2.0 marketing agency specialized in helping small and medium-sized businesses maximize the revenue from their websites. They specialize in digital campaigns that include search engine optimization, pay per click marketing, social media networking and web design for succcess. The goal is to help businesses connect with prospects and convert them into customers. Because no matter how great their product may be, if nobody knows about them, they does not exist.

Nuff marketing. You can check it out for yourself at 64clicks.

Provisioning CouchDB with EC2 - New Video from Andy Glover @ Beacon50

Andy has a new video on Provisioning CouchDB with EC2 - @ Beacon50. Great introduction to everyone who’s new to the subject.

Facebook 25% of all pageviews?

CI in a Box

Unless you’ve spent the last several years in a cocoon you have noticed the trend of everything IT-related moving to the cloud. It’s the new SOA. No, it is the new black. Whatever it is, it is creating a fertile environment for traditional tools and techniques to find new homes in the cloud. And it is cheap.

Here is a good example: Continuous Integration. Yes, it is that “box” in Bob’s office that spams your mailbox with stack traces every day. And yes, it is “easy” to stand-up. Of course after the equipment requisition form, the turf war, the operating system, the users, JDKs, the home and backup folders, the CI server software… you get the picture.

And that’s where the cloud shines. One can create and remove instances of pretty much any environment in (almost) an instant - cool! For an effective CI environment what’s needed is the prepackaging of a CI server and the backend wiring to the cloud. Using a tool such as CI in a Box dramatically shortens the time needed to stand-up a CI instance. Currently it uses Hudson, which also happens to be my server of choice, despite recent outages of hudson.dev.java.net.

Being fairly new, the CI in a Box website has good documentation to get anyone started, although a more detailed knowledge of the principles of CI may be required for effective project setup and management.

I am excited about this promising project and I’ll be following their updates in the weeks ahead.

Hacker Halted Conference

Ever got hacked? I have.

You’ll recognize someone who’s gone through the hell by how seriously they take security… after the fact. No blame here - running a small business is not easy. In fact, truly yours is as guilty as everyone. I got hacked not just once, but twice in the past three years. So, how do I stay safe? What are my options?

I can hire a company to do outside testing, or penetration testing, but that’s one-time and will only discover pieces of the problem. And, likely, it will cost. I am small business owner and a guerrilla entrepreneur, i.e. I know that if its important I will eventually have to learn how to do it myself, for cheap. At least, until I can afford to hire proper “security guys”. So, training then, but cheap.

I stared looking into training options and I ran into the Hacker Halted Conference which starts in couple of weeks. I found out bunch of classes offered as part of the conference. My guerrilla gut knows there are hidden deals somewhere, so I continue on…

More research reveals these classes:

Secure Coding & Application Security - E|CSP
Start Date/Time: Sunday, September 20, 2009 8:30 AM
End Date/Time: Tuesday, September 22, 2009 5:30 PM
http://www.hackerhalted.com/LiveTrainings/tabid/94/ModuleID/541/ItemID/10/mctl/EventDetails/Default.aspx

Register by Sep 10, 2009: $2,299 per student
Register from Sep 11, 2009: $2,499 per student

ITIL V3 Foundation
Start Date/Time: Sunday, September 20, 2009 8:30 AM
End Date/Time: Tuesday, September 22, 2009 5:30 PM
http://www.hackerhalted.com/LiveTrainings/tabid/94/ModuleID/541/ItemID/18/mctl/EventDetails/Default.aspx

Register by Sep 10, 2009: $1,399.99 per student
Register from Sep 11, 2009: $1,499.99 per student

Prices look OK, but here is the kicker - they are delivered by Insyte, a local training company based in Alexandria, VA. Now, I am really interested - I like doing business with local companies. So, I give them a call and I get this deal:

Here’s what’s FREE:

For ALL registrants of the ECSP or ITIL class at Hacker Halted Academy 2009, they will take away 5 specials as follows:

1. Complimentary Conference Pass worth $1299
2. Full Access to ALL open sessions of the conference from Sep 23 - 25, 2009
3. All lunches and coffee breaks provided during the training and conference (Sep 20 - 25, 2009)
4. Attend a choice one of the 3 following one-day training seminars on Sep 25, 2009, covering the following topics:
   a. Identifying Threats and Deploying Countermeasures
   b. Incident Response: Principles of Incident Handling - this one is for me!!!
   c. Virtualization Security: Threats Exposed
   *These workshops are worth $599. Not bad.
5. Free Certification Training Courseware and Exam Voucher! Choose from one of the following:
   a. EC-Council Certified Secure Programmer (ECSP)
   b. EC-Council Certified VoIP Professional (ECVP)
   c. EC-Council Disaster Recovery Professionals (EDRP)
   *These official electronic courseware and Prometric Prime Vouchers are worth a combined total of $900! ($650 for courseware + $250 for voucher)

If you need more information call 703-535-8600 or visit http://www.insyte.us

Until next time, stay safe.

Agile and Documentation

Someone asked a question about how an Agile book recommended bare minimum documentation and how the idea of the index cards as means of documentation felt a bit “weird”.

I couldn’t agree more. Index cards as the only or primary way for documentation is a recipe for disaster. The Agile manifesto, as outdated as it is, emphasizes working code over documentation. People have misinterpreted it repeatedly for minimal or no documentation. The latter takes away the power of things written down and agreed upon by everyone.

As a SCRUM Master and Agile coach, I manage multiple teams with 60-70 stories per iteration and 5-7 iterations per release. There is no way in the world that I, or anyone else on my team, will spend time digging a cabinet of index cards to find out about the details of a story that happened 3-4 months ago. It just won’t happen.

Instead, we’ve been gradually transitioning to using a modern WIKI, like Confluence to capture and manage requirements. Among other things, Confluence provides excellent traceability and version control through a very usable diff utility. Requirements and stories captured in Confluence are always current and open to the entire team. This includes people that may not be interested, aware or involved with the creation of index cards, but whose knowledge of the requirements is nevertheless critical for the success of the project. Combined with SCM labels and release notes, any person on the team is always 100% sure what’s in Production, what’s in Testing and what’s currently being developed.

Interaction Patterns: Tester finds bug!

Consider the following scenario, which probably happens hundred of times every day: Tester finds a bug! That’s great, or really bad, depending on where you look at it, but that’s not the focus of this blog entry. We’re interested in what happens next.

In the less-optimized team, the following sequence, with some variations, may start happening:

1. Tester: Umm, something looks fishy…This might be a bug.
2. Tester: Trying again…yupp, the same thing! This must be a bug.
3. Tester: Let me check the requirements document before I write the ticket.
4. Tester navigates to the root of the version-controlled documentation folder.
5. Tester is savvy, so she gets the latest documentation from the repository. This takes a while. She takes a coffee break.
6. Tester comes back from the coffee break. Opens the requirements document in Microsoft Word and looks-up this particular piece. Locating the exact location in the use case document takes a while, because the document is long.
7. Tester: Argh, this requirement document is a joke! Will these guys ever get it right?
8. Tester: It really does not say much about this thing, so I am going to write the ticket anyway. At least someone will take a look at it.
9. Analyst (next morning): QC found a bug, let’s triage it so it gets assigned to someone quickly.
10. Dev Manager: OK, let’s assign it to Developer.
11. Developer (after a day, two): Umm, something looks fishy…This might not be a bug.
12. Developer: Let me check the requirements document.
13. Developer navigates to the root of the version-controlled documentation folder.
14. Developer is savvy, so he gets the latest documentation from the repository. This takes a while. He takes a coffee break.
15. Developer comes back from the coffee break. Opens the requirements document in Microsoft Word and looks-up this particular piece. Locating the exact location in the use case document takes a while, because the document is long.
16. Developer: Argh, this requirement document is a joke! Will these guys ever get it right?
17. Developer: OK, here it is - says nothing about this thing. So, it is not a bug.
18. Developer: I am going to reject it and add the comment “Coded per requirements”.
19. Tester (next morning): My bug got rejected!
20. Dev Manager: Can three of you get together and talk?
21. Tester, Developer, Analyst (analysts’ desk, the next day): Let’s open the document.
22. Analyst navigates to the root of the version-controlled documentation folder.
23. Analyst is savvy, so she gets the latest documentation from the repository. This takes a while. All take a coffee break.
24. Everybody come back from the coffee break. Open the requirements document in Microsoft Word and look-up this particular piece. Locating the exact location in the use case document takes a while, because the document is long.
25. Analyst: Is this the right version? I remember deleting these several lines.
26. Analyst: Let’s get version history. Yes, looks like it was updated six weeks ago. So, where are my changes?
27. Analyst: Oops, I forgot to export it from DOORS/ClearCase and check in to the version control system. What’s coded and tested is really not what the business needs right now.
28. Everybody: Rinse and repeat.

Does this ever happen in your project? I’ve seen it more often than I care to remember and despite that it seems trivial, changing behaviors takes time and perseverance.

What would a highly-effective team do in this situation? Let me attempt to construct an non-exhaustive list of things. This is just one way of achieving efficiency; there are probably infinite number of ways.

First, the team starts with a long-term vision and focus on people, practices and tools. Hire the best people, train them in cross-functional environments and create a reward structure which takes into account individual contributions in addition to team achievements.

Second, [over time] the team accumulated a list of practices and follows them.

Third, it uses tools that support the team practices.

So here is a version of the same sequence in a highly-efficient team, and somewhat shorter:

1. Tester: Umm, something looks fishy…This might be a bug.
2. Tester: Trying again…yupp, the same thing! This must be a bug.
3. Tester: Let me check the requirements WIKI page before I write the ticket.
4. Tester navigates to the root of team WIKI server. Performs a search and the requirements page comes-up first.
5. Tester: Himm, this requirement page has changed 134 times since last year. I wonder which one I am testing.
6. Tester performs another search, this time for the release notes. The search is based on the SCM label dropped to the QC environment. The release notes has an automatically-generated list of requirement numbers along with versions. Cool!
7. Tester: OK, so I am looking at the right version. Still, the requirement sounds ambiguous.
8. Tester chats with analyst in the hallway. Analyst stops by her desk and takes a read at the open WIKI page.
9. Analyst: Yes, this requirement stinks, I am sorry. Let’s edit it together here to add the clarification.
10. Analyst edits the page. Saves it in a new version with the comment: “Adding more clarity to BR:982. No coding required”. Analyst maks this as “Minor change”, so no new version of the page is created.
11. Tester: Thank you for the clarification. This is not a bug.

Now, does this happen in your project? Are there ways to optimize this even further? Probably yes.

What’s Test-Driven Development, anyway?

It still amuses me, after such a long time, to listen to people equating TDD to unit testing. But wait - in conversations and public forums, I’ve seen TDD and JUnit used interchangeably. Nothing wrong w/ the framework, of course. Plus, we know Kent Beck is working hard on v 4.7, so many new cool features are in the pipeline. But, whatever happened to the “other” tests - acceptance, functional, integration, database, performance, security and the myriad of special testing methods? From a value point, one can make the argument that automated acceptance tests are more effective in some cases than unit tests. Or, that functional tests can provide a better overall warm and fuzzy, if you need a little confidence before a release. Maybe, one [all-inclusive] test method is what we need to clear up the confusion