Andy Hunt and Dave Thomas wrote “The Pragmatic Programmer” in 1999; it offers a number of insights that are still applicable not only to software development but software entrepreneurship. I have distilled 8 tactics from a selection of 25 tips (out of more than 70 in the book).
8 Tactics For Entrepreneurs From “The Pragmatic Programmer”
Look at a Situation From All Relevant Perspectives;
Listen to All Stakeholders
Be a Catalyst for Change: You can’t force change on people. Instead, show them how the future might be and help them participate in creating it.
Work with a User to Think Like a User
It’s the best way to gain insight into how the system will really be used.Don’t Gather Requirements—Dig for Them: Requirements rarely lie on the surface. They’re buried deep beneath layers of assumptions, misconceptions, and politics.
It’s Both What You Say and the Way You Say It
There’s no point in having great ideas if you don’t communicate them effectively.Make Quality a Requirements Issue
Involve your users in determining the project’s real quality requirements.
You have to clearly understand and communicate “what’s in it for them” which requires you to look at the situation from their point of view and fully appreciate the constraints and incentives they face. It’s not a real plan until everyone is a little unsatisfied but will be better off. Think through your agreements for how each party’s incentives and constraints may change in response to likely and foreseeable events.
Build Models to Improve Your Understanding
Critically Analyze What You Read and Hear
Don’t be swayed by vendors, media hype, or dogma. Analyze information in terms of you and your project.Estimate to Avoid Surprises
Estimate before you start. You’ll spot potential problems up front.
A simple model–be it a diagram on a whiteboard or piece of scratch paper, a spreadsheet, a list of interactions and relationships between different entities in a system–is much more useful than a collection of facts. By all means get the facts, but analyze them in the context of a model that explains current behavior and a coherent explanation of the likely evolution.
Prototype
Use Tracer Bullets to Find the Target
Tracer bullets let you home in on your target by trying things and seeing how close they land.Don’t Assume It—Prove It
Prove your assumptions in the actual environment—with real data and boundary conditions.Prototype to Learn
Prototyping is a learning experience. Its value lies not in the code you produce, but in the lessons you learn.Test Your Estimates
Mathematical analysis of algorithms doesn’t tell you everything. Try timing your code in its target environment.
Whether it’s a new product, a new service, or a new market, find ways to build simple versions to get feedback from potential customers and prove basic feasibility. Once you understand the feasibility and desirability of a new offering you can make an educated estimate of the likely profitability or viability. A rough version that prospects can interact with will provide one or two orders of magnitude more information than any verbal description. And testing it on real data, preferably in a production environment, will tell you more than a dozen conversations around the conference table in your BatCave.
Document
DRY—Don’t Repeat Yourself
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.Abstractions Live Longer than Details
Invest in the abstraction, not the implementation. Abstractions can survive the barrage of changes from different implementations and new technologies.Use a Project Glossary
Create and maintain a single source of all the specific terms and vocabulary for a project.
As important as “rough consensus and running code” is clear documentation of plans, assumptions, problems fixed, approaches considered and rejected. Anticipate the needs of people who have not yet joined the team who will need to understand how things work and why. I am not proposing a “cover your ass” approach as an accepted common source of truth for decisions and the effects and outcomes they were expected to produce.
Anticipate Failure to Mitigate if not Prevent it
Always Use Source Code Control
Source code control is a time machine for your work—you can go back.Design to Test
Start thinking about testing before you write a line of code.Crash Early
A dead program normally does a lot less damage than a crippled one.
Running a diff, having software tools that systematically assess “what’s changed” can alert you to issues and problems you have overlooked and potentially allow you to undo certain problems Keep a log. Think clearly about the implication of a strategy or approach not working. In particular your reputation and social capital is much more fragile and harder to replenish than lost time or lost money. People will always remember if you didn’t care or did not think things through. Define clear containment and recovery plans before trying something new that may have negative consequences.
Be Systematic in Your Thinking and Always Look For the System
Remember the Big Picture
Don’t get so engrossed in the details that you forget to check what’s happening around you.Don’t Think Outside the Box—Find the Box
When faced with an impossible problem, identify the real constraints. Ask yourself: “Does it have to be done this way? Does it have to be done at all?”
It’s rare that optimizing just one part of a system or a situation will yield much benefit without understanding how the different pieces (or subsystems) interact. The flip side is that many constraints we perceive are more due to force of habit, preconceptions, and incorrect assumptions. Clearly defining the “box” and then testing each edge and vertex to make sure it’s a bona fide constraint can often enlarge your understanding of what is truly feasible, yielding a better solution.
“Creativity involves a three-step process. The first step is to identify assumptions that you make which prevent you from seeing the alternatives to the ones that you currently see. These are self-imposed constraints. The second step is to deny these constraining assumptions. The third is to explore the consequences of the denials. Creativity of individuals can be enhanced by practice, particularly under the guidance of one who is creative.”
Russell L. Ackoff, iconoclastic management authority, advocates a ‘systemic’ approach to innovation
Minimize Debt and Shortcuts–In Maintenance, Expertise, Relationships
Don’t Live with Broken Windows
Fix bad designs, wrong decisions, and poor code when you see them.Invest Regularly in Your Knowledge Portfolio
Make learning a habit.Make It Easy to Reuse
If it’s easy to reuse, people will. Create an environment that supports reuse.Find Bugs Once
Once a human tester finds a bug, it should be the last time a human tester finds that bug. Automatic tests should check for it from then on.
It can be hard to admit a mistake, whether in a design or a relationship. But letting it fester is rarely a winning strategy. Maintenance is never exciting that’s why it’s important to minimize the need for it and make it easy for others to rely on proven approaches as template–provided they are still relevant. This can be complicated by the normal effect of innovation and new knowledge to obsolete some portion of your existing expertise and capability set. In times of rapid evolution the discount rate on older knowledge can be surprising steep.
Don’t Worry: You Are Neither Perfect Nor a Failure
There Are No Final Decisions
No decision is cast in stone. Instead, consider each as being written in the sand at the beach, and plan for change.Don’t Panic When Debugging
Take a deep breath and THINK! about what could be causing the bug.
A longing for perfection in your strategy or yourself can lead you to viewing small setbacks as large failures and reject adequate solutions that can evolve over time. Keep a log to give yourself some perspective.
“Our achievements speak for themselves. What we have to keep track of are our failures, discouragements, and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay.”
Eric Hoffer