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.

Facebook 25% of all pageviews?

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.

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.

ROI of Agile Development

Scott Sehlhorst at Tyner Blain has added an excellent article on ROI in Agile. Take a read!