Bad Code, Craftsmanship, Engineering, and Certification

At QCON 2010, Robert Martin gave a talk about Bad Code, Craftsmanship, Engineering, and Certification. Uncle Bob started the talk by showing an example of bad code which consisted of two massive classes with hundred of methods. He asked why do we write bad code that we know will impede us? And wondered if it is due to deadlines, laziness, boredom, or job security. Bob stresses that the way we go fast as professionals is to do the best job we possible can. He encourages us to wear a green band on our wrist that symbolizes a commitment to write the best code we can at all times.

Uncle Bob then makes the following recommendations:

1.      Apply the boy scout rule: Always leave the camp ground cleaner than the way you found it. That is, whenever you work on a class or function, spend some extra time to refactor it and clean it a little.

2.      Apply Extract till you drop: Function size should be small. Keeping extracting until you can no longer extract the function. This takes all the concepts in the function puts them in well named places.

3.      No argument is the best argument. Functions should have the smallest number of arguments possible. Try not to exceed 2 arguments. Do not pass Booleans as arguments; instead create two well named functions.

4.      Use long names to be as descriptive as possible.

5.      Avoid duplication. Do not copy and paste.


Next Uncle Bob goes over the Software Craftsmanship Manifesto which states:

1.      We value not only working software but also well crafted software

2.      Not only responding to change, but also steadily adding value.

3.      Not only individuals and interactions, but also a community of professionals.

4.      Not only customer collaboration but also productive partnerships.


He then covers the disciplines that the manifesto is based on. These include:

1.      TDD – verifies that our code works and also makes it possible for us to refactor and constantly improve the code over time.

2.      CI: Use tools like Hudson, CruiseControl, Bamboo, and TeamCity. If the build fails, immediately fix the build.

3.      Pairing: If you don’t want to code pair, at least make sure the team is communicating, sharing and working closely together.

4.      QA should find nothing

5.      Have pride in workmanship

To convince others, the best thing you can do is do the best job you can and be a role model. Soon others will observe that you are outperforming the rest and will realize why.

Uncle Bob next covers the engineering practices of small cycles feedback, source code as the design, and design patterns. He wraps up by discussing certification and how they over promise and under deliver. Instead he recommends actually talking to potential new hires and have several team members talk to them as well. Let them show you code samples. Ask for references and check those references.

This presentation is available on InfoQ at http://www.infoq.com/presentations/Robert-C.-Martin-Bad-Code

Sustainable Test Driven Development

At QCON, Steve Freeman gave a talk on Sustainable Test Driven Development. Steve show examples of bad tests and gives us advice on how to write good tests that make development easier and easy to maintain. Steve recommends the following:

1. Test Readability: Make sure the tests are readable.

2. Test features and not implementation: Do not write a test for each method in a class, but instead write test for specific features and behaviors.

3. Use helper messages to remove noise and be more expressive.

4. Use self describing variables.

5. Use test data builders that fill in defaults for values not specified.

6. Test the what not the how.

7. Always add message in the assert to explain the test.

8. Overload toString to get descriptive error messages.

9. Specify precisely what should happen and no more.

10. Avoid brittle tests like hardcoding values. For example, when trying to assert for auto-incremental id values, simply test that the value got incremented instead of asserting against an actual value.

11. Only enforce order of methods when it matters.
Steve concludes that tests are code too. They need all the same care and attention given to code. Tests need to focus on what matters. We should value expressiveness over convenience and make sure the tests are readable. If a class is hard to test then it’s a clue that our code is too complex.

This presentation is available on InfoQ at http://www.infoq.com/presentations/Sustainable-Test-Driven-Development

You Say Tomato, I Say Pomodoro

The Pomodoro technique (Italian for tomato) is a time management technique created by Francesco Cirillo. The technique uses a timer to break down periods of work into 25 minute intervals separated by breaks. It is based on the idea that frequent breaks can improve mental agility.
The technique uses a form of timeboxing and relates well to Scrum and other agile methods. The process is as follows:

1.    Choose a task to be accomplished
2.    Set the Pomodoro to 25 minutes (the Pomodoro is the timer)
3.    Work on the task until the Pomodoro rings, then put a check on your sheet of paper
4.    Take a short break (5 minutes is OK)
5.    Every 4 Pomodoros take a longer break

Splitting Stories

Mike Cohn provides guidelines on splitting stories in his books Agile Estimating and Planning as well as User Stories Applied. Stories need to be split as they rise to the top of the product backlog and near implementation. Some reasons for splitting a story are:

1. Size – Too big

• a. Cannot give an accurate estimate: A story needs to be more manageable and enable a more accurate estimate.
• b. Cannot fit into an iteration: If for example an iteration is 1 week long and the story in longer than a week then it needs to be split to fit into the iteration.
• c. Cannot fit into what’s remaining of an iteration: A team has already committed to 38 story points and there is still room for a 2 point story but the remaining stories are 3 story points or more.
• 2. Dependency: A story is dependent on another story. This makes it hard to give a correct estimate. The story needs to be split where one story handles the dependency and the others handle the specifics.
• 3. Risk: A story is complex and risky. The story needs to be split to create a spike story which is experimental in nature and its main goal is to gain technical knowledge.
• 4. Compound: A story contains multiple sub stories that are large enough to stand out on their own.

Some of the techniques for splitting stories include:

• 1. Along data boundaries: For example, separate local requirements from international requirement, or handling one type of credit card from another.
• 2. Operational boundaries: This typically is done along CRUD boundaries where for example a story is split into 3; one to create an entity, one to retrieve and update an entity, and one to delete an entity. Another example might be separating a story into search which simply return search result count and then search display which displays the actual results of a search.
• 3. Cross Cutting Concern: Features that effect multiple aspects of the application like security, logging, error handling can each be separated out of main functionality features. For example, a screen that will have different menu options or links based on the login user’s credentials. This security specific feature can be split from the main functionality of the screen.
• 4. Performance constraints: Functional requirement from non functional requirements can be split into separate stories. For example, a feature can be enabled without caching and then another story can handle caching specifics.
• 5. Priority: Within a story, there might be multiple priorities. For example, a login story might have different priorities for authentication than for handling error conditions like locking out a user after multiple logins.

It is important to not split stories into tasks like design, code front end, code middle tier, code back end. It is almost always better to deliver a cohesive subset of all layers of a feature than delivering all of one layer as a standalone. Having the entire backend ready without a corresponding GUI is not very useful, but having a feature that allows the user to add an entity through the GUI and have it persisted is functionality that can be useful and provides some value.

Finally, there might be cases where we might want to combine many small items onto one larger story. For example, bug reports can be combined into one Fix Bugs story.

Scrum and Kanban

Henrik Kniberg and Mattias Skarin compare Scrum and Kanban in their book “Kanban and Scrum – Making the Most of Both”.

Scrum consists of
Small cross functional self-organizing teams
Time boxes for the Sprint, Release Planning, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective
Artifacts: Product Backlog, Sprint Backlog, Release Burndown and Spring Burndown.

Scrum requires small cross functional self-organizing teams. Each Scrum team is composed of a product owner, a ScrumMaster, and the team. The Product Owner maintains and prioritizes the product backlog in a way that maximizes value of the work performed by the team. The team works in short fixed length iterations and consists of developers with all the necessary skills to deliver the committed to features by the end of the iteration. The Sprint starts with a Sprint planning meeting to produce the Sprint backlog from high priority feature in the product backlog. This is followed with daily work on small concrete items from the Sprint backlog, and ends with a Sprint Review to demo the deliverables as well as a Sprint retrospective to review the process. Everyday the team also has a Daily Scrum meeting to ensure progress towards the Sprint goal and update the Sprint Burndown chart. A release planning meeting is held before the start of each release to estimate and prioritize features to be included in the next release. After each Sprint, the Release Burndown chart is update to show and track release progress. Throughout, the ScrumMaster ensures that the process is understood and followed and removes any impediments to the team’s progress.

Kanban is based on limits on Work in Progress. It uses a visual control mechanism (Kanban Board) to track work as it flows through the various stages of the value stream. The board tracks states like to-do, in development, in testing, completed, etc. Each state has a limit on the number of items that it can hold. Work is split into pieces and progresses through the workflow however no items can proceed unless there is enough capacity in the next state. Lead time or cycle time is constantly measured and optimized to make it as small and as predictable as possible. Kanban does not prescribe artifacts and team composition like Scrum does. Kanban leaves everything open. The only constraints are visualizing the workflow and limiting WIP.

Henrik summarizes the similarities and differences as follows:

	Scrum	Kanban
Delivering releasable software early and often	“potentially shippable” at end of each Sprint	Scheduled or on demand
Transparency to drive process improvement	Product Backlog, Sprint Backlog, retrospectives	Kanban Board
Pull Scheduling	Items are pulled from product backlog at beginning of each Sprint	Items pulled when a slot becomes available
Iterations	Timeboxed iteration prescribed for Sprint, Release Planning, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective	Timeboxed iterations optional. Process can be event driven instead of timeboxed. Each meeting can occur at different times.
Resets	Sprint Backlog/Scrum board is reset after each Sprint	Kanban board is persistent
Item Size	Items must be broken down to fit into 1 sprint	No sizing requirements
Estimation	Estimation prescribed	Estimation optional
Prioritization	Prescribes a prioritized backlog	Prioritization optional
Commitments	Team commits to specific work in an iteration	Commitment optional.
Process Improvement Metric	Based on Velocity	Based on Lead time
Artifacts	Product Backlog, Sprint Backlog, Release Burndown and Spring Burndown prescribed	Kanban Board
WIP Limits	Indirectly based on what can fit into a Sprint	Directly based on limits set for each stage in the workflow
Responding to change	Cannot add items to an ongoing iteration	Can add new items whenever there is capacity
Team composition	Cross-functional teams prescribed	Silos and specialist teams allowed
Ownership	Sprint backlog is owned by one specific team	A Kanban board may be shared by multiple teams
Roles	3 roles: Product Owner, Team, ScrumMaster	No roles prescribed

Henrik and Mattias recommend you not limit yourself to one tool. Mix and match as needed based on your organization's circumstances.

The 10 Commandments of Brainstorming

Josh Linkner put out some rules on brainstorming:

1. Thou shall not judge: Keep the ideas flowing. You can evaluate or rank them later.

2. Thou shall not comment: There are no silly, stupid, nor outrageous ideas during brainstorming.

3. Thou shall not edit: Keep the ideas coming even if they are sloppy. You can clear them up later.

4. Thou shall not execute: Do not jump to implementation.

5. Thou shall not worry: Every idea matters. Don't be fearful to throw them out there.

6. Thou shall not look backwards: Don't hold back because previous ideas where not adopted.

7. Thou shall not loose focus: Stay on track and move unrelated topics for later discussion.

8. Thou shall not sap energy: Stay engaged and energized.

9. Thou shall not compare: Even if ideas appear similar to others, write them down and keep moving.

10. Thou shall not make funny at others' expense: Do not laugh at ideas that come out.

The full article is available on Forbes.com at http://www.forbes.com/2010/04/20/brainstorming-ideation-ideas-leadership-managing-innovation.html

Determing Velocity

In his book Agile Estimating and Planning, Mike Cohn explains that there are 3 ways to determine a team’s velocity:

1. Observation: Run a couple of iterations and observe the team’s actual velocity.

2. Historical data: Use historical data from previously run similar projects with the same team.

3. Forecasting: Estimate the team’s velocity by following these steps:

• a. Determine total hours available per iteration. Assuming a 2 week iteration then there are 80 hours per iteration (8 hours/day * 10 calendar days = 80 hours). For a 6 member team this becomes 6*80=480 ideal man hours.
• b. Assume a focus factor of 50%. This takes into account time spent in meetings, sending emails, answering phone calls, preparing for presentations or demos, etc... 480/2=240 hours.
• c. From the product backlog, pick stories of various sizes (2, 3, 5, 8) and expand them into tasks. In this case it is not necessary to pick stories based on priority. Instead try to find a representative set of stories (different complexity and varied topics.)
• d. Estimate the tasks and repeat until you have enough tasks to fill the team’s capacity of 240 hours.
• e. The team’s forecast velocity is the sum of the selected story points.

Your 1st option should always be to use observation. However, if you do not have the time to run a couple of iterations, then choose historical or forecast velocity but remember to always switch to the actual observed velocity after completing a couple of iterations.