Agile in a Flash 52

TDD Process Smells – The Code

Agile in a Flash by Jeff Langr and Tim Ottinger (card #52)

> Not failing first

> No green bar in last ten minutes

> Skipping the refactoring step

> Skipping easy tests

> Skipping hard tests

> Not writing the test first

> Setting code coverage targets

--

Not failing first. It’s tempting to go right for green (passing), but an initial red (failing) test tells you that the test works.

No green bar in last ten minutes. You’ re not relying on your tests anymore if it’s been a while since you’ve seen green. Is it ever a good time to not know whether you’ve broken something? Take smaller steps.

Skipping the refactoring step. It’s a truly bad idea to make a mess “for now” and promise to clean it up in the mythical “later” (Robert Martin has addressed this fallacy in his many keynote addresses).

Skipping easy tests. You won’t save much time by not testing simple code, and you’ll possibly create silly mistakes that go undetected in the code.

Skipping hard tests. Difficulty in testing drives us to reconsider and improve our design (to something that is also easier to test!).

Not writing the test first. TDD requires you to drive your code changes from the outside. Writing tests later makes code harder to test and hard to refactor for testing.

Setting code coverage targets. This is a well-understood failure because of the Hawthorne Effect (roughly, “you get what you measure”). It is better to discourage artificial inflation (gaming) of metrics.

--

“I have not failed, I’ve just found 1000 ways that won’t work.” ― Thomas Edison

~ Remember failure is necessary before people can understand success.

Agile in a Flash 51

Test Double Troubles – The Code

Agile in a Flash by Jeff Langr and Tim Ottinger (card #51)

> Inhibited refactoring

> Tool complexity

> Passing tests that indicate nothing

> Mocking the SUT

> Low readability

> Ambitious mock implementations

> Vendor dependency

--

Inhibited refactoring. Test doubles exploit the linkages between classes, so refactoring class relationships may cause mock-based tests to fail.

Tool complexity. Mock tools have extensive APIs and can be idiosyncratic. It’s costly to understand both the tool and the code it produces.

Passing tests that indicate nothing. Fakes and stubs may not act quite like the classes they replace, leading to tests that pass and code that fails.

Mocking the SUT. Complex setup can bury the embarrassing fact that code we need to be real has been replaced with mock code, invalidating the test.

Low readability. Mock setup can be dense and idiomatic, making it difficult to see what’s really being tested.

Ambitious mock implementations. A fake is an alternative implementation of the class it replaces and can have bugs of its own. Keep your test doubles small and purposed to a single test or test fixture.

Vendor dependency. All third-party tools eventually fall out of favor, replaced with something newer and better. Don’t get stuck with yesterday’s tool.

To remedy most of these challenges, keep your use of mocks isolated and minimal. Refactor tests to emphasize abstraction and eliminate redundant mock detail.

--

“If you could kick the person in the pants for most of your trouble, you wouldn’t sit for a month.” ― Theodore Roosevelt

Agile in a Flash 50

Break Unit Test Writer’s Block – The Code

Agile in a Flash by Jeff Langr and Tim Ottinger (card #50)

> Test that you can call the method at all
> Pick the most interesting functionality
> Pick the easiest functionality
> Write an assertion first
> Rename or refactor something
> Switch programming partners
> Reread the tests and code

--

Software authors can also get writers block. A good trick to beating it is to do some useful programming activity to get the creative juices flowing.

In legacy code, calling a method at all can require considerable setup, mocking, and dependency breaking. These activities get you entrenched in the code and activate your urge to clean up the code base.

Let your curiosity guide you. Test the most interesting bit of the functionality you’re writing. You’ll have more energy to do work that interests you most.

Alternatively, pick the easiest functionality so that you experience some success and build momentum. “Simple is as simple does.”

When writing a method normally (begin-to-end) fails, try writing the assertion first and working backward from there.

If you rename or refactor something, you’ll have your head wrapped around the problem more and end up with a code improvement to boot!

If the flow of ideas is getting stale, “a change is as good as a break,” so switch programming partners.

You may be stuck because you don’t really understand the code you need to change. Help your brain: reread the tests and code that already exist.

--

“Don’t waste time waiting for inspiration. Begin, and inspiration will find you.” ― H. Jackson Brown Jr.

Agile in a Flash 49

Field Guide to Mocks – The Code

Agile in a Flash by Jeff Langr and Tim Ottinger (card #49)

> Test double: Any object that emulates another

> Stub: Returns a fixed value to the SUT

> Fake: Emulates a production object

> Mock: Self-verifies

> Partial mock: Combines production and mock methods

> Spy: Records messages for later verification

--

Test doubles are emulation objects you build to simplify testing. Surrounding the System Under Test (SUT) with test doubles allows you to exercise and observe it in isolation. Otherwise, accessing database, network, external hardware, or other subsystems can slow or break the test run and cause false positives. Stubs, fakes, mocks (partial or not), and spies are nuanced kinds of test doubles. This field guide, based on XUnit Test Patterns, will help you sort out standard terminology (used in many mock tools).

Test doubles have changed the art of test-driving by allowing tests to be smaller, simpler, and faster running. They can allow you to have a suite of thousands of tests that runs in a minute or less. Such rapid feedback gives you the confidence to dramatically change your code every few minutes. But take care; you should do the following:

> Learn to use test doubles, but employ them only when you need the isolation.

> Use a mock tool (instead of hand-coding them) if it improves test quality.

> Learn the various types of mocks summarized in this field guide.*12

> Read Card 51, Test DoubleTroubles, to avoid their many pitfalls.

--

12. If only to avoid being embarrassed by your peers. Or just keep this card handy.

"The secret of life is honesty and fair dealing. IF you can fake that, you've got it made." Groucho Marx

Agile in a Flash 48

Refactoring Inhibitors – The Code

Agile in a Flash by Jeff Langr and Tim Ottinger (card #48)

> Insufficient tests

> Long-lived branches

> Implementation-specific tests

> Crushing technical debt

> No know-how

> Premature performance infatuation

> Management metric mandates

--

Agile’s demand for continual change can rapidly degrade a system’s design. Refactoring is essential to keeping maintenance costs low in an agile environment.

Insufficient tests. TDD gives you the confidence to refactor and do the right thing, when you would not otherwise for fear of breaking existing code.

Long-lived branches. Working on a branch, you’ll plead for minimal trunk refactoring in order to avoid merge hell. Most branches should be short-lived.

Implementation-specific tests. You may want to discard tests, ultimately killing refactoring, if small refactorings breaks many tests at once. Minimize testto-System Under Test (SUT) encapsulation violations, which mocks can create.

Crushing technical debt. Insufficient refactoring creates overwhelming rampant duplication and difficult code. Refactor on every green to minimize debt.

No know-how. You can’t refactor if you don’t know which direction to take the code. Learn all you can about design, starting with simple design.

Premature performance infatuation. Don’t let baseless performance fear stifle cohesive designs. Make it run, make it right, and only then make it fast.

Management metric mandates. Governance by often one-dimensional and insufficient metrics (such as increase coverage) can discourage refactoring.

-- Do not assume you wrote good code or did good refactoring. Test, Test and then test again.

Agile in a Flash 47

Prevent Code Rot Through Refactoring – The Code

Agile in a Flash by Jeff Langr and Tim Ottinger (card #47)

> Refactor only while green

> Test constantly

> Work in tiny steps

> Add before removing

> Test extracted functionality

> Do not add functionality

--

Start with all tests passing (green), because code that does not have tests cannot be safely refactored. If necessary, add passing characterization tests so that you have a reasonable green starting point.

By working in tiny steps and running tests constantly, you will always know whether your last change has broken anything. Refactoring is much easier if you insist on always having only one reason to fail.

By adding new code before removing old code (while testing constantly), you ensure you are not creating blocks of untested code as you work. For a while, your code will be half-refactored, with the code of old and new implementations of a behavior present. Each act of refactoring takes several edit/test cycles to reach a clean end state. Work deliberately and incrementally.

When extracting classes or methods, remember that they may need unit tests too, especially if they expose behaviors that were previously private or hidden. Be watchful of introducing changes in functionality. When tempted to add some bit of functionality, complete the current refactoring and move on to the next iteration of the Red/Green/Refactor cycle.

“Learning to write clean code is hard work. It requires more than just the knowledge of principles and patterns. You must sweat over it. You must practice it yourself, and watch yourself fail. You must watch others practice it and fail. You must see them stumble and retrace their steps. You must see them agonize over decisions and see the price they pay for making those decisions the wrong way.” - Martin, Robert C. (2008) Clean Code: A Handbook of Agile Software Craftmanship. Prentice Hall.

Agile in a Flash 46

Triple A for Tight Tests – The Code

Agile in a Flash by Jeff Langr and Tim Ottinger (card #46)

> Arrange all the things needed to exercise the code

> Act on the code you want to verify

> Assert that the code worked as expected

--

Arrange-Act-Assert (AAA), a simple concept devised by Bill Wake of xp123.com, provides subtle power by helping test readers quickly understand the intent and flow of a test. No more “What the heck is this test even testing?”

In a unit test, you first create, or arrange, a context; then execute, or act on, the target code; and finally assert that the System Under Test (SUT) behaved as expected. Thinking in terms of AAA has direct impact on the code’s visual layout.

The simplest (perhaps ideal) test has three lines, one for each A. Here’s an example where we must verify that the SUT applies late fines to a library patron:

@Test

public void applyFine() {

Patron patron = new Patron(); // arrange the context

patron.setBalance(0);

patron.applyFine(10); // act

assertEquals(10, patron.fineBalance()); // assert

}

You don’t need the comments—the blank lines alone are sufficient.

AAA (also known as given-when-then) isn’t an absolute rule. You might not need an Arrange, and it’s OK to combine an Act and an Assertion into a single-line test.

“Reliability is the degree to which an assessment tool produces stable and consistent results” ~ Phelan, C & Wren, J. (http://www.uni.edu/chfasoa/reliabilityandvalidity.htm)

Testing methodologies:

http://www.guru99.com/testing-methodology.html

Agile in a Flash 45

FIRST Properties of Unit Tests – The Code

Agile in a Flash by Jeff Langr and Tim Ottinger (card #45)

> Fast

> Isolated

> Repeatable

> Self-verifying

> Timely

--

Fast. Tests should be really fast. If the entire unit test suite takes a minute, people will be reluctant to run it. Break dependencies to make tests profoundly fast and small.

Isolated. When a test fails, it should be for a single, obvious reason. A long, complex test may fail in many places for many reasons. Isolated tests can run alone or in a suite, in any order.

Repeatable. Tests can be run in a loop, without intervention. They will continue to fail or succeed until code is changed that breaks them. They do not leave the system in a state that will not allow them to run again.

Self-verifying. Unit tests are pass/fail. No interpretation is needed to determine success. If the test fails, it states why it failed.

Timely. Unit tests are written with the code, not after the code is completed. In TDD style, tests are written first. Your best results will always come from following the Red/Green/Refactor cycle.

Source: Brett Shuchert, TimOttinger

Avoid this: “I don’t have time to write tests because I am too busy debugging”

Another great blog article on this: http://blog.stevensanderson.com/2009/08/24/writing-great-unit-tests-best-and-worst-practises/

Agile in a Flash 44

A Rhythm for Success: The TDD Cycle – The Code

Agile in a Flash by Jeff Langr and Tim Ottinger (card #44)

> Red

> Green

> Refactor

--

Of the agile developer practices, TDD will change your coding approach most fundamentally. TDD is a rhythm that helps you continually keep steady, forward progress. In the TDD cycle, you produce enough test code to fail, produce enough code to make the test pass, and then refactor before writing the next microtest. Red and green are the colors shown by GUI test tools for failing and passing tests.

Red. Newbies commonly make the mistake of not watching tests fail first. The red is essential feedback that the tests are written correctly and recognized by the test runner.

Green. Making the test pass is the part that is obvious; the hard part is that you write only enough code to make the test pass. No more! By limiting the amount of coding, you force the tests to be more complete, you avoid the cost of an over-designed system, and you learn how to incrementally grow behavior.

Refactor. While the test is passing, before anyone can depend on its current implementation, clean it. Rename a test. Improve readability. Extract an interface or a class. Unlike the Green step, there are no limits on the amount of refactoring you can do per step, as long as the tests always pass. Refactoring is critical to survival; it is your main opportunity to ensure your system’s

design stays clean.

“All code is guilty until proven innocent”

Agile in a Flash 43

Really Meaningful Names – The Code

Agile in a Flash by Jeff Langr and Tim Ottinger (card #43)

> Are accurate

> Are purposeful

> Are pronounceable

> Begin well

> Are simple

> Depend on context

> Match name length to scope

--

Are accurate. Do not mislead the reader. Naming a user’s postal code birthDate might infuriate co-workers! Characters like O and l can fool readers into seeing the digits 0 and 1.

Are purposeful. Describe the intended use of a thing, not its origin or composition. Variable names like text and psz lack intention.

Are pronounceable. Pronounceable names are easily recognized and discussed. We want to talk about the code without sounding crazy.

Begin well . Leading differences stand out, but differences in the middle or end of names can be hard to spot.

Are simple. Long names are more descriptive but less distinct than short ones. Encoded prefixes and suffixes make differences between names subtle. Don’t try to cram too much meaning into a name.

Depend on context. The fully qualified name is the real name. The local name is just the nickname.

Relate name length to scope. Names in very small scope (short loops, closures) can be small. Names visible from many places must be extra descriptive.

See Clean Code [Mar08] for Tim’s exhaustive guide to naming.

"What's in a name? That which we call a rose

By any other name would smell as sweet." ~Juliet (Shakespeare)

Agile in a Flash 42

The Seven Code Virtues – The Code

Agile in a Flash by Jeff Langr and Tim Ottinger (card #42)

> Working, as opposed to incomplete

> Unique, as opposed to duplicated

> Simple, as opposed to complicated

> Clear, as opposed to puzzling

> Easy, as opposed to difficult

> Developed, as opposed to primitive

> Brief, as opposed to chatty

--

Working, as opposed to incomplete. A program that works is superior to one that might work later. TDD requires code to work early and often.

Unique, as opposed to duplicated. Many regression errors are the result of improvements to only one version of copied code. Eliminate duplication in TDD’s refactoring step.

Simple, as opposed to complicated. Simple code hides fewer bugs and tends to optimize well.

Clear, as opposed to puzzling. Code misunderstandings generate errors. Use Card 43, Really Meaningful Names, and simple structures to make such errors unlikely.

Easy, as opposed to difficult. Structure and organize code so that it is easy to use. Don’t hesitate to add convenience methods and classes.

Developed, as opposed to primitive. Prefer the clarification and encapsulation of abstract data types to built-in variable types. Primitive obsession muddles the code and can create maintenance nightmares.

Brief, as opposed to chatty. Code should be brief but never cryptic. All other virtues still observed, less code is always better than more.

"Complicated code is infinitely more difficult to maintain and debug than simple code.” 

Agile in a Flash 41

Build Superior Systems with Simple Design – The Code

Agile in a Flash by Jeff Langr and Tim Ottinger (card #41)

> All tests must pass

> No code is duplicated

> Code is self-explanatory

> No superfluous parts exist

--

As far as a prescriptive set of design principles go, these four rules(11) of simple design, listed in order of importance, are the simplest thing that might possibly work.

> Code must work and be demonstrated by passing tests. A great paper model of a design is useless if the software doesn’t work. Use TDD so that you know the code is working at all times.

> Removing duplication is the next most important design activity, because it directly lowers the cost of system maintenance and drives you toward an appropriate level of abstraction.

> Contrary to popular belief, it’s almost always possible to create code that others can understand and maintain—particularly if your TDD-created tests clearly document intended behavior. Maintenance costs rise dramatically with unclear code.

> Finally, YAGNI (You Aren’t Going To Need It) tells us to remove all superfluous features and complexity—anything not needed at this precise moment.

11. Extreme Programming Explained, First Edition

"A simple design always takes less time to finish than a complex one."

- extremeprogramming.org

"A man should look for what is, and not for what he thinks should be."

Albert Einstein

Agile in a Flash 40

Eight Crucial Practices of Agile Programmers – The Code

Agile in a Flash by Jeff Langr and Tim Ottinger (card #40)

> Continuous integration (CI)

> Test-Driven Development (TDD)

> Constant design improvement

> Coding standard

> Collective code ownership

> Simple design

> System metaphor

> Pair programming

--

Agile programmers use these eight practices that derive from Extreme Programming (see Extreme Programming Explained, First Edition) to improve their software development practice. The practices can work individually but have a profound synergy when used together.

A coding standard (see Card 35, Coding Standards) is foundational for working as a team that collectively owns the code. Continuous integration ensures the system is always in working order. You know the system works because it has been built by pairs of programmers reviewing the other person’s work and using TDD (plus automated acceptance tests) to verify that it works. You know the system has a quality design, because the programmers use TDD to continually improve the design (refactor) using simple design concepts.

You communicate these system ideas with your whole team—which includes the business and other nontechnical folks—through use of a metaphor. A metaphor is a shared system vision and language that simplifies decision making and reduces the need for deep-code spelunking. The shopping cart is a common metaphor; you talk about “carts, items, and checkout.” You might end up with what’s

known as the naïve metaphor: “This is a purchasing system, with orders, inventory items, and submissions.” Boring but effective enough!

"Don't practice until you get it right. Practice until you can't get it wrong.” - Unknown

Agile in a Flash 39

How to Stay Valuable – The Code

Agile in a Flash by Jeff Langr and Tim Ottinger (card #39)

> Stay positive

> Stay engaged

> Stay professional

--

Be valuable to your employer, whether times are good or bad and whether you’re talking about your current employer or your next one.

Stay positive. A positive attitude is crucial to building goodwill, inspiring others, and having fun. Staying positive when things are difficult is not just good citizenship; it is leadership.

Stay engaged. You are not effective when you are not participating in the work of the team. Focusing every day is hard, so use pair programming and perhaps the Pomodoro Technique (see Pomodoro Technique Illustrated) to help keep your head in the game.

Stay professional. As long as you are on the job, you are an ambassador of your profession. Learn and model those attitudes, skills, and techniques that improve the quality of work for the team (including customers and managers). As much as possible, be helpful and diligent in your work. Remember

that you are building a reputation, and make it a good one.

"Leadership is lifting a person’s vision to high sights, the raising of a person’s performance to a higher standard, the building of a personality beyond its normal limitations." —Peter Drucker

Agile in a Flash 38

Stop the Bad Test Death Spiral – The Team

Agile in a Flash by Jeff Langr and Tim Ottinger (card #38)

> Only integration tests are written ! Learn TDD.

> Overall suite time slows ! Break into “slow/fast” suites.

> Tests are run less often ! Report test timeouts as build failures.

> Tests are disabled ! Monitor coverage.

> Bugs become commonplace ! Always write tests to “cover” a bug.

> Value of automated testing is questioned ! Commit to TDD, acceptance tests (ATs), refactoring.

> Team quits testing in disgust ! Don’t wait until it’s too late!--

Each misstep with TDD may lead down a bad spiral toward its abandonment.

Learn TDD. Violating cohesion and coupling principles impedes unit testing and promotes integration tests instead. TDD drives a unit-testable, SOLID (OO Design Pattern) design.

Break into slow/fast suites A fast suite runs in ten seconds. Keep the slow suite small. Use a continuous test tool such as Infinitest (Selenium works well too). Keep coupling low.

Report test timeouts as build failures Continually monitor the health of your test suite. If the suite slows dramatically, developers soon skimp on testing.

Monitor coverage Seek coverage above 90% on new code and stable/increasing coverage on existing code. Recast integration tests as unit tests or ATs.

Always write tests to cover a bug Test first, of course. Defects indicate inadequate test coverage. Track and understand each defect’s root cause!

Commit to TDD, ATs, refactoring Do TDD diligently. Many bugs are rooted in duplication that you must factor out. Quality problems slow production!

Don’t wait until it’s too late! If you admit defeat, it may be too late—managers rarely tolerate second attempts at what they think is the same thing.

From experience, Avoid building tests that encompass more than the subject or code tested or the test becomes overly complex and “brittle.”

Agile in a Flash 37

Pair Programming Smells – The Team

Agile in a Flash by Jeff Langr and Tim Ottinger (card #37)

> Unequal access

> Keyboard domination

> Unhealthy relationships

> Worker /rester

> “Everyone does their own work”

> Endless debate

--

Sniff out and correct these smells that prevent successful pairing.

Unequal access. Ensure tight cube setups don’t require one partner to sit behind another. Pairing is two people collaborating, not one watching another.

Keyboard domination. Domination can occur when one partner dismisses the other, verbally or otherwise. A coach (perhaps Cesar Millan) must intervene if the dominated party remains silent.

Unhealthy relationships. Pairs should change frequently enough to avoid stagnation (“pair marriage”). Pair enemies are a more serious problem, requiring remediation or even reorganization.

Worker /rester. Watch for disengaged partners (a second computer is an obvious indicator). Take breaks, switch partners, and coach habitual resters.

“Everyone does their own work”. The whole team is responsible for collaborating (and not abandoning each other) to complete the work. A manager discourages pairing when they hold individuals accountable for tasks.

Endless debate. People unskilled at pair programming will over-analyze how to derive a solution. Any debate longer than ten minutes should be resolved via code. Arguing in code is better than arguing about code.

A relevant quote (source unknown), “If your relationship has more issues than a magazine, it’s better to cancel the subscription”

Agile in a Flash 36

Is Your Team Circling the Drain? – The Team

Agile in a Flash by Jeff Langr and Tim Ottinger (card #36)

> Individual work assignments

> Piles of unfinished work

> Work assignments given under the table

> Empty ceremonies

> Neglecting quality practices

> Guarded speech

--

If a team has had trouble completing tasks well and on time in the past, it will have increased pressure from above. The urge to hold individuals accountable results in individual work assignments. To motivate fervent effort, work is piled on, resulting in piles of unfinished work.

Since outside parties have trouble getting work done through official channels, they find ways to pass work assignments under the table. This makes it less likely that official tasks will be completed (Gerald Weinberg’s Law of Raspberry Jam is “The more you spread it, the thinner it gets”).

Since the team is not truly collaborating, meetings become empty ceremonies. Overloaded team members neglect quality practices (such as TDD, testing, or CI) in a desperate bid to get tasks off their plates. As team members become bitter and disappointed, their public speech becomes increasingly guarded.

The development team needs to be rebooted so it can build a new reputation using an agile work system (we recommend hiring a capable agile coach). It needs a “whole-team” approach, with limited work in progress and no under-the-table assignments. Those in these circumstances are reminded of these wise words: change your organization, or change your organization.

--

Warren Buffet is quoted: "Should you find yourself in a chronically leaking boat, energy devoted to changing vessels is likely to be more productive than energy devoted to patching leaks."

Agile in a Flash 35

Coding Standards – The Team

Agile in a Flash by Jeff Langr and Tim Ottinger (card #35)

> Standardize to avoid waste

> Start with an accepted standard

> Timebox the debate

> Fit on one page

> Revisit regularly until no one cares

> The code becomes the standard

--

“We don’t need no stinkin’ standards!” Yes you do, unless you want your team to waste time with careless, inconsistent effort.

Standardize to avoid waste. Inconsistent code generates silly waste: slower comprehension time, arguments, and rework by annoyed programmers. Worse waste comes when someone misinterprets code and introduces a defect.

Start with an accepted standard. Surprise, others have debated coding standards for countless hours, long before you. Take advantage of existing community or even IDE standards (and save the angst of going against their grain).

Timebox the debate. An initial debate should take no longer than an hour. The goal is to obtain consensus, not to determine the One True Way. Don’t allow wavering from your teammates on standards, only tightening.

Fit on one page. Do not try to build a comprehensive guide to programming. Keep it small, simple, and unambiguous.

Revisit regularly until no one cares. Increment and improve the standard as needed using retrospectives, just as you would any agile product. Eventually the topic will bore everyone.

The code becomes the standard. You will know the style guide is unnecessary when all code looks alike and it all looks good!

-- 
A relevant quote (source unknown); "If you can't be honest or don't have integrity, then you won't have a high standards without good discipline."

Agile in a Flash 34

Collective Code Ownership – The Team

Agile in a Flash by Jeff Langr and Tim Ottinger (card #34)

> Anyone can modify any code at any time

> The team adheres to a single style guide

> Original authorship is immaterial

> Abundant automated tests create confidence

> Version control provides insurance

--

Anyone can modify any code at any time. You may improve any section of the code without wasting time seeking permission. You’re not a cubed individual piling up a code fiefdom, but part of a team collaborating on a deeply connected system.

The team adheres to a single style guide. The points in Card 35, Coding Standards, reduce the wasteful friction of learning a new standard when working elsewhere in the system. A common style guide lets you spend time solving problems that matter. Your IDE might be able to help here.

Original authorship is immaterial. Personal attachment to “your” code provides no additional value when your team all strives toward the same goal of high quality code. Lose the pride over code you just created, substituting enthusiasm for figuring out how to make it even better.

Abundant automated tests create confidence. TDD provides abundant tests that both declare and protect the original programmer’s intent, giving you the freedom to refactor with impunity.

Version control provides insurance. The use of a good version control system means you can return to a previous (working, tested) version of the system, making code experiments affordable.