TID: Test-If-Development (A more pragmatic TDD)

The moment you need to introduce some if-logic into a method, you jump over to write the test, but not before.  This approach argues it is unnecessary overhead to write the test before you create the method because the method could be absent of any conditions, in the case it is comprised of calls to other methods.

Example - not needing a test

void populateContactInfo() {
   populateName();
   populateAddress();
   populatePhone();
}

Example - needs at least 2 tests because there are 2 branches of code

void populateContactInfo() {
   if (hasName) {
       populateName();
   }
   else {
       populateDefaultName();  
   }
   populateAddress();
   populatePhone();
}

The phrase Test-If-Development has one other benefit.  That is,"If" you are doing "Development", you "Test". Period.

Read More »

Programmer Productivity Hypothesis

Based on my observations and experience, I believe the following to be the business case for paying down Tecnical Debt.

• The acronym "DRY" stands for Don't Repeat Yourself. 
• Code Coverage means the lines of code exercised by automated tests.

DRY code yields full percentage gains in productivity.

If you have 100% duplicated code and clean it up to 0% (purely hypothetical) then your productivity improves by the same 100%. In other words, what took a team of 8 now takes a team of 4 because the amount of code to wade through is half. If your team did 16 points per sprint, they can now do 32.

Thus,
PRODUCTIVITY = MAX_PRODUCTIVITY * (1 - DUPLICATION)


Example: Team currently does 20 points, has 30% duplicate code. Their maximum productivity is...
     20 = MP * .7
     MP = 20 / .7 = 28 points
   This means the team could work on lowering duplication from 30% to 0% to bring up their productivity from 20 to 28.  Now size what kind of effort that would take to reduce duplication in order to make the right business decision.


Code Coverage yields half percentage gains in productivity.

If you have 0% Code Coverage and write unit tests so that it reaches 100% (purely hypothetical) then your productivity improves by 50%. This is due to the fact that while unit tests reduce defects and rework, it creates more code to maintain. In other words, what took a team of 8 now takes 6 because you can modify code, refactor safely, and add tests more easily. If your team did 16 points per sprint, they can now do 24.

Thus,
PRODUCTIVITY = MAX_PRODUCTIVITY * .5 * (1 + CODE_COVERAGE)

Example: Team currently does 20 points, has 30% code coverage. Their maximum productivity is...
     20 = MP * .5 * (1 + .3)
     MP = 20 / .65 = 30 points
   This means the team could work on increasing code coverage from 30% to 100% to bring up their productivity from 20 to 30.  Now size the effort it would take to write that many unit tests in order to make the right business decision.


Please let me know your thoughts.
.

Read More »

Presentation - ATDD Survival Guide

Download the presentation here: Slide Deck

Abstract:

Learn how to implement Acceptance Test Driven Development on any technology platform… even yours! Come for Engineering tips and Business Acceptance Tests tips to avoid a tangled mess.  See how ATDD can fit into your process.

Read More »

Presentation - Agile Points FTW!

Download the presentation here: Slide Deck

Abstract:
Why estimate in Points instead of Hours? Come learn how playing poker can give you more productivity at work and eliminate those wasteful estimation processes.

Read More »

Presentation - Hudson/Jenkins: Beginner to Expert

Here is the presentation I gave at COJUG

• "Hudson/Jenkins: Beginner to Expert" - slide deck lives on SkyDrive


• Corresponding demo - lives on github

Abstract:
Come learn appropriate practices for Continuous Integration in an Agile age. Jenkins (a.k.a. Hudson) is a flexible CI solution. I'll walk us through its simple setup, show some of the plug-ins, and then dive into leveraging Jenkins for a multi-application, enterprise solution. I think you'll see that Jenkins can not only perform the CI duties of build with unit tests, but can also serve as a dashboard for numerous deployment and automated tasks.

.

Read More »

Explaining 'Agile Coach' in Social Circles

It was hard enough for me to explain my job before, when I was an IT Consultant. Half the time I'd say things like: "Well there's my software development job for the client... Then there's the company I work for..."
Now that I am an Agile Coach, it's even harder to explain, and I see people tend to shutdown when I try - i.e. it's too fuzzy and unfamiliar for them to ask any follow-up questions. As a result, sometimes I just resort to saying, "I'm a Software Developer." Problem is, that implies two things, neither of which are true in my case:

1. That I am a computer programmer writing software.
2. That I sit in a cubicle all day, getting my "Nerd" on, and not interacting with people.

---

Here's my latest thought on Explaining 'What I do as an Agile Coach' to Social Circles (i.e. non-IT people at parties, family events, etc.)

1. I teach IT people on Teamwork.
   - It used to be people sat in front of their computers all day in offices or cubicles (like "Office Space"). Now we stick teams of 10 in a room and make them collaborate and design together. Software Development is a very creative process so we often have toys and colorful rooms like an Art Studio.
2. I teach IT people about being Transparent. (and honest and realistic)
   - Since we're typically a bunch of engineers - not the most social animals - we are not very good at communicating with the business and users of the applications about issues and progress of their new features of their website or mobile app.
   - So it sounds like Kindergarten, but we write the features on index cards or post-its and stick 'em on a wall. And we talk about them everyday and have demos on work-in-progress frequently with anyone who cares.
   - There are people committing to deadlines and I try to ensure that expectations are realistic given the challenges of creating something that's never been done before.
3. I teach Managers to Trust.
   - As you can imagine, the transparency thing only works if you have upper management bought-in and trusting that their people are doing the best they can given the circumstances.
   - So instead of managers telling the people under them what to do, I teach them about "servant leadership" which completely reverses their thinking.
   - Instead of command and control, micro-management, I coach the Managers into asking the Teams things like, "What do you need from me today to be successful?" or "How can I help you?". It flips the organization upside-down and the Team begins to feel empowered to work better. They have the full support of their Managers to unblock issues for them and now everyone can work toward the same, common goal of creating a better - and more profitable - company.

Read More »