#thecleancoder

In the final chapter of The Clean Coder, Uncle Bob discusses the education (or lack thereof) that we receive in programming university courses and how the burden of responsibility to guiding new software developers to maturity will fall to senior developers in the form of mentorships. He uses the example of doctors within the medical field who, after completing school, go through several years of rigorous mentorships (residency) and being supervised before applying for board certification. Given that software runs much of the world today, some of which can be life threatening if done improperly, why aren't software developers required to go under a period of training and supervised practice as well?

According to Uncle Bob, an ideal software apprenticeship will be structured as follows, starting from the top level:

Masters

Programmers who have been in the industry for typically 10+ years and have worked with several different kinds of systems, languages, and operating systems. They know how to manage projects and lead teams, and may have a management position while still remaining technical through studying, practicing, doing, and teaching.

Journeymen

Trained, competent programmers who have an average of about five years of industry experience and are knowledgable about current technology. They typically aren't well versed with many different kinds of systems and languages, but are working towards learning more. They are supervised by masters or senior journeymen and their code is often closely supervised and scrutinized. As they gain experience, the level of autonomy grows.

Apprentices/Interns

University graduates start out as interns or apprentices. They are mentored by journeymen and are very closely supervised. Journeymen assign readings, exercises, and practices to apprentices and they review their progress and provide feedback. Disciplines are learned and reinforced and the foundations of values are created. Apprentices should last about a year and if the apprentice has successfully completed the apprenticeship and the masters approve of his/her accomplishments, the apprentice becomes a journeyman.

Long gone is the notion that programmers work in dark corners by themselves while they type away on the computer. Nowadays, programmers are expected to communicate and collaborate with team members to get projects done. In The Clean Coder, Uncle Bob discusses what it means to be a team member and ways to collaborate with others.

The first responsibility of the professional programmer is to meet the needs of his or her employer.

As programmers, we should know the business side of the projects we're working on. It doesn't mean that we need to know every single thing about the business, but we should at least have a deep understanding of the business goals. This means that we'll have to work with people like managers, business analysts, testers, and other team members to truly understand why we're writing code and how the business will benefit from it. According to Uncle Bob, the worst thing a professional programmer can do is to bury himself in solitude without understanding the business. It is our job to keep the business running, and thus our responsibility to take the time to understand it.

Professional developers do not prevent others from working [on] the code.

So what does it mean to be a part of a team? Generally speaking, most of us like to work alone and that's fine. There is a time and place for working by yourself. However, when you're working in a team, you cannot put a shield around your code and refuse to let anyone else touch it. The team should own all the code. Learn from each other by working on the system together as a team. Collaborate by pair programming because as the saying goes, "Two heads are better than one." Pairing is the most efficient way to solve a problem, share knowledge with one another, and review code.

Team members should also sit around a table facing each other, and not in separate corners wearing headphones. While it may sound nice to put on some music and work on some code, you won't be contributing to the team. Work with each other so that you can talk to one another and help those who look like they're having a difficult time with a problem.

Programming is all about working with people.

It takes time to form a team, and when team members form relationships and learn all kinds of things about one another, the team begins to gel. While it may take quite some time for a team to truly mingle and become a solid unit, patience is not gone unrewarded. A well gelled team will plan things together, solve problems, and just get things done.

Professional development organizations allocate projects to existing gelled teams, they don't form teams around projects.

In these next two chapters of The Clean Coder, Uncle Bob provides tips and techniques to meet deadlines while staying cool under pressure. Often times we set deadlines as commitments, and unfortunately not all commitments are carried out on time. This failure in keeping your promise is the source of nearly all distrust in any relationship, whether it be professional or personal. So how do we effectively come up with a deadline for our projects? Since problems can arise at any time, they can throw off deadlines to extend far longer than originally projected. To meet target dates, we really need to think of them more as estimates.

Businesses like to view estimates as commitments. Developers like to view estimates as guesses.

Professionals don't make commitments because they know there is always some level of uncertainty with every task. Because businesses need deadlines in order to plan ahead, they rely on the developers to commit to a target date. Professionals draw a clear distinction between estimates and commitments, and will only accept commitments when they are absolutely certain that the task can be carried out. Typically, this is not the case, and the professional will instead provide a trivariate analysis - an estimate of three numbers:

Optimistic Estimate - A wildly optimistic estimate, of less than 1% chance of occurrence, which can only be achieved if absolutely everything goes right.

Nominal Estimate - An estimate with the greatest chance of success.

Pessimistic Estimate - A wildly pessimistic estimate, also of less than 1% chance of occurrence, which takes everything that could possibly go wrong into consideration.

Given this set of estimates, we can find the expected duration of the task to be as follows:

E = (O + 4N + P) / 6

The standard deviation of the expected duration of the task is described below:

U = (P - O) / 6

This number is the measure of the amount of uncertainty a task entails. Using probability distribution to determine a realistic estimate is a good way of factoring in any unexpected issues that may arise during the task as this number considers both best-case and worse-case scenarios. Professionals are very careful to set reasonable estimates despite the pressure to try to go fast.

Techniques

Uncle Bob introduces several techniques to incorporate your team in determining realistic estimates.

Flying Fingers - A technique that's been mentioned in a previous post. Team members sit around a table and tasks are discussed. For each task, the team is asked for optimistic, nominal, and pessimistic estimates by raising their fingers based on how long they believe the task will take. If everyone agrees, then they go onto the next task. If there disagreement, then they continue discussion until an agreement is reached. Simultaneity of revealing fingers is very important in this technique as peoples' minds can be swayed based on what they see other people do.

Planning Poker - Systematically equivalent to flying fingers, except team members are given a hand of cards with different number on them. Members choose a card that matches their estimates, and sets the card faced down on the table. When everyone has decided, the cards are simultaneously revealed.

Affinity Estimation - All tasks are written onto cards, without any estimates showing. Team stands around a table with cards spread out randomly, and members sort the cards relative to one another. Tasks that take longer are moved to the right, and smaller tasks are moved to the left. This method is done in silence, and any member can move any card at any time. If any card is moved more than n times, the card is set aside for discussion. Eventually discussion of the order of the tasks begin, and lines between the cards are drawn to present bucket sizes. Traditionally, five buckets are drawn in a Fibonacci sequence.

While these techniques aren't the only methods to determining estimates, they are methods that have been proven to be effective in creating practical estimates.

The Law of Large Numbers

Estimates are not error-free and when facing a large task, it is often beneficial to break the task into several smaller tasks to minimize error. An implication of the Law of Large Numbers suggests the following:

If you break up a large task into many smaller tasks and estimate them independently, the sum of the estimates of the small tasks will be more accurate than a single estimate of the larger task.

While doing this still won't guarantee an error-free estimate, it is good practice to break the tasks up to better understand the task as a whole and to uncover any surprises that may arise.

Pressure

The business will always want commitments because they want to eliminate risk. We are honor bound to help the business find a way to meet commitments. However, we are not honor bound to accept the commitments.

So how do you avoid pressure? Business may be down your neck about having this and that done and you're stressing out. The best way to stay calm under pressure is to avoid the situations that cause pressure. Unrealistic commitments thwarts the goal of eliminating risk, so accepting them just does a disservice to both the business and you.

You may be tempted to rush and drift away from your disciplines and beliefs to meet deadlines. Don't! In doing so, you'll only cause messes that will only create more pressure down the road. You can avoid presure by keeping your system, code, and design as clean as possible by sticking to your disciplines at all time.

You can't always avoid pressure though, and it's important to handle pressure appropriately. When faced with pressure, don't panic. Manage your stress, think the problem through, and work at a reasonable and steady pace. Rushing will only drive you deeper into a hole. Communicate with your team to let them know that you're in trouble. In doing so, you can receive help from others and they won't be greeted with any surprises.

The only way through the pressure cooker is to rely on what you already know works - your disciplines.

Again, trust your disciplines. There is never a time to question or abandon them, and they are there to guide you through times of high pressure. Finally, get help! Pair with your peers to help you think of helpful ideas, point out any mistakes, and help you keep focused to drill through your program.

Given that you spend the standard eight hours on a workday to be productive, how do you use this time wisely? Time management has always been a bit of a struggle for me as I'm sure it is for many people, and in this chapter of The Clean Coder, Uncle Bob discusses different types of meetings and ways to effectively manage time.

Meetings

There are two truths about meeting.

Meetings are necessary.

Meetings are huge time wasters.

Often these two truths equally describe the same meeting.

Professionals should be aware of the high cost of meetings and the importance of their own time. Because there are two truths to every meeting, it is crucial to plan ahead and figure out what meetings don't have a significant benefit to attend by knowing what will be discussed. Uncle Bob advises to decline any meeting that doesn't require your attendance as your projects hold the utmost importance. Likewise if you do find yourself in a meeting that isn't beneficial to you, find the best opportune time to politely leave the meeting.

Uncle Bob also introduces a few types of meetings that are part of Agile development: stand-up meetings, iteration planning meetings, and iteration retrospective and demo meetings.

Stand-Ups

Stand-up meetings require the participants to stand while the meeting is in session and have each person answer three questions:

What did I do yesterday?

What am I going to do today?

What's in my way?

Since starting my apprenticeship, I've participated in stand-ups everyday at 11AM to answer these three questions. Initially I thought it was an odd thing to do, but as the days went by my perception of stand-ups has changed into thinking that it's a great way of facilitating communication amongst team members and identification of issues before they become too problematic. Since I'm the only apprentice in Los Angeles so far, I feel like my participation in stand-up meetings doesn't contribute much to the team, but I can definitely see how beneficial it is to the craftsmen to have a quick formal meeting at the same time everyday to communicate with one another.

Iteration Planning

Iteration planning meetings are conducted to select the backlog items that will be executed in the next iteration. Estimates should already be done for each item and acceptance tests should already be sketched out. Uncle Bob states that these meetings are difficult to do well, and suggests that they should take no more than 5% of the total time of the iteration.

Iteration Retrospective and Demo

Conducted at the end of each iteration, retroactive (retro) meetings are meant for team members to discuss what went right, what went wrong, and actions to make these wrongs into rights. Stakeholders then see a demo of the newly working features to provide critique and feedback to the team members. I sat through a retro meeting today where the craftsmen discussed and listed the happy faces (right), frowny faces (wrong), and action items to turn those frowns upside down. It was cool to see that each participant had a say in how they thought the iteration went and to see how they came up with solutions to each issue.

Pomodoro Technique

Uncle Bob also talks about one effective time management technique that I've actually used for some time called the Pomodoro Technique. The instructions are pretty simple and are laid out below:

Set a timer for 25 minutes, or one tomato.

Let nothing interfere with what you're doing.

When time's up, stop what you're doing immediately, deal with any interruptions that occured during the tomato, and take a short five minute break.

Repeat. Every fourth tomato, take a longer break of 15-30 minutes.

For the sake of brevity and saving time, I'll be bunching up the summaries of chapters 7-8 into one post since they both have to do with testing.

Acceptance Tests

In this chapter of The Clean Coder, Uncle Bob explains who should be involved in acceptance tests, what they are, when they should be written, how they should be done, and why this all matters.

Who Should Write Acceptance Test?

Ideally, stakeholders and QA collaborate to write the tests and developers verify them. In this way, (all) ambiguity is removed from the requirements and everyone involved understand the plan for system behavior.

What are They?

By definitions, acceptance tests are tests written by the collaboration of the stakeholders and programmers in order to define when a requirement is done. Everyone has their own definition of "done-ness", but Uncle Bob suggests that doneness is achieve when these three conditions are met:

All code is written

All tests pass

QA and the stakeholders have accepted

When Should They be Written?

According to Uncle Bob, the first few acceptance tests should be ready for the first iteration. By the midpoint of the iteration, all acceptance tests should be ready.

How Should They be Done?

Acceptance tests should always be automated. You create a set of automated tests that meet all of the conditions above; and if they pass, then you are done with that particular feature.

Why are Acceptance Tests Important?

When multiple parties are involved in the creation of a system, there is bound to be miscommunication and ambiguity. Acceptance tests exist to eliminate these issues by formally presenting the requirements that specify system behavior from a business standpoint. The audience of these tests is the business and the programmers. They are not to be confused with unit tests, which describe the lowest level of structure and are meant to be writtten for programmers only.

Testing Strategies

The image above represents the Test Automation Pyramid which illustrates the kinds of tests used during development. In addition to unit tests and acceptance tests, there exists higher-level tests to prevent QA from finding any errors and bugs in the system. Because QA work with the stakeholders to create automated acceptance tests that specify the requirements of the system and employ exploratory testing to characterize the true behavior of the running system, it is the responsibility of the professional programmer to ensure that QA finds (asymptotic) nothing.

Unit Tests

Written by programmers for programmers, unit tests specify the system at the lowest level. They provide nearly 100% true covereage of the code and assert its behavior.

Component Tests

Acceptance tests, as described above, are on this level of the testing pyramid and are written against individual components of the system. A component test wraps the component and tests that the output matches the input. Any other components are decoupled from the test using mocking and other appropriate techniques. These tests cover approximately half of the system.

Integration Tests

Used only for larger systems and typically written by system architects, integration tests ensure that all components are properly connected and can clearly communicate with one another. These tests are typically not executed as part of the Continuous Integration (CI) test suite, and are instead run periodically as prescribed by their authors.

System Tests

System tests execute against the entire integrated system and ensures that the whole system is wired correctly. Written by system architects and technical leads, these tests are written in the same language and environment as the integration tests and are executed rather infrequently. Because system tests ensure proper construction of the code, they only cover roughly 10% of the system as the behavior of the components of the code has already been tested by the lower levels of the pyramid.

Manual Exploratory Tests

Manual exploratory tests are human-driven and explore the system for unexpected behaviors while confirming the expected. These tests are not to be automated, and provide the assurance of knowing that the system behaves under human operation.

Doing your daily job is not practice - it's performance.

Practicing programming is definitely something I need to do more. Before I opened this book, I foolishly thought that just doing my daily tasks were sufficient enough to be considered as "practice". I never really thought of programming practice as the same thing as the way musicians and performers practice, but it really does make sense. These people practice on their own time and consider work time as performances, why should I think any differently?

There are several different ways to practice programming:

Kata A precise set of choreographed keystrokes and mouse movements that simulates the solving of some programming problem. The kata serves not as a practice of problem solving, but to practice the movements to make them automatic and instinctive so that they are there when you need them.

Wasa Also known as ping-pong. Two programmers choose a kata. One programmer writes a unit test, and then the other must make it pass. Switch roles and repeat.

Randori Similar to wasa, but with many people. With a screen projected on the wall, one person writes a test and then sits down. The next person makes the test pass and then writes the next test. Repeat.

Open source Broaden experience and diversify tool/skill set by contributing to open source projects and using tools and languages that aren't familiar.

The concept of test-driven development (TDD for short) is very foreign to people like me who just wrote code without tests. There are three laws of TDD:

You are not allowed to write any production code until you have written a failing unit test.

You are not allowed to write more of a unit test than is sufficient to fail - and not compiling is failing.

You are not allowed to write more production code that is sufficient to pass the currently failing unit test.

Rinse and repeat into a cycle that, according to Uncle Bob, is about 30 seconds long. It seems weird to write failing tests first before writing actual code, but after Dave had asked me to try my hand at writing a few tests after I had already written my Tic-Tac-Toe code, I began to see why testing first is necessary. Before getting into the why, here are a few benefits of TDD:

Certainty If you make any changes in your code and all tests still pass, you can be nearly certain that the changes made have not negatively affected other parts of your code.

Low Defect Injection The number of bugs and issues remain low as you add to and update your code.

Courage Gives you the confidence to change code and eliminates the fear of breaking it. Regularly cleaning and fixing your code makes it become simpler and easier to maintain/extend.

Documentation Unit tests are essentially the user manual to your code. For anything you need to know how to do, there will be a unit test that describes it in detail.

Design Forces you to think about good design and isolate/decouple functions so that you can write tests.

Design was the biggest reason why I thought testing first is crucial. Writing tests for my Node class wasn't all too bad, but once I started getting into the more complex functions like those in my Board class, things started to get difficult. I had no idea how to start writing tests on a lot of functions because there were too many dependencies on other objects and functions. I read about stubs and mocks, but everything flew over my head. In the end, I couldn't completely finish writing all of my tests and I knew it was because I was attempting to write them after I wrote my code. The problem was that I was just writing these tests to get them to pass, and I didn't have to think about the design and flexibility of the code. As Uncle Bob put it, the tests you write later are defense, and the tests that you write first are offense. Testing first ensures that your code is dynamic and future proof to any changes or additions that will eventually be made.