The 100 Things You Must Know To Be Effective In Software Development

This page is a precursor to a book of the same title.  I will add one entry per day. At this point I have identified about 2/3 of the insights to be presented. It will probably take about a week for this format to gel.  But I wanted to create the page and put it out in the public for feedback and to encourage me to keep at it. - Al Shalloway

Software Development has come of age, even if most of those in the industry don’t know it yet.  What do I mean? I mean that we now know what it takes to build quality software, either in an IT or product development shop.  While this collection of insights,

In Kevin Hall’s brilliant “Aspire: Discovering Your Purpose Through the Power of Words” he discusses the phrase sapere vedere which means “knowing how to see.”  I suggest that we must learn the underlying laws of software development so that we can have sapere vedere in our work.  Mr. Hall says that “People without sapere vedere say, ‘I’ll cross that bridge when I get there.’ Those with sapere vedere say, ‘I’ll see that bridge before I get there.’” This can be the difference from trudging ahead by removing impediments and moving fast by avoiding the impediment from being created.   I believe these 100 “things” will provide you with sapere vedere in your software development work.  Our methods shouldn’t be inventions of ours that we use to cope with reality to do our job better.   Our methods should be reflections of reality so that we can work with the laws of software development and thereby work better.

Software Development has come of age, even if most of those in the industry don’t know it yet.  What do I mean? I mean that we now know what it takes to build quality software, either in an IT or product development shop.  While this collection of insights, principles, practices, frameworks, and more isn’t a secret, it’s both disappointing and exciting that very few seem to be aware of them. Disappointing because we (as an industry) would be doing so much better if we all attended to them, but exciting because the potential for huge improvement is right on us.  But we have to take things to the next level.

The first stage of learning is knowing what to learn. While trite, it’s true – there’s what we know, what we don’t know and what we don’t know we don’t know.  This site is a pre-cursor to a book that outlines the (approximately) 100 things that must be attended to to achieve effective software development.

How have I selected these?  Although software development is complex, there are patterns to failure and success in these complex systems.  Not attending to one of the following insights results in a challenge.   We don’t have to wait until we hit it, we can see the problem beforehand by being aware of the laws of software development.  Or, we can just keep our eyes open.  In the same way lights go from green to yellow to red, we leave out one of the insights and challenges will follow.  Does this imply that complex systems are predictable?  No.  It means they have patterns.  There is a difference between micro-predictability (i.e., will the ball land red, black or green) and macro-predictability (more money is staying at the table).  While we may not know the weather today, summer will be hotter than winter.

The first step for an agile transition needs to be an awareness of what we need to learn.  This book is an attempt at that.  While a little information will be presented for each topic, that information will be an overview at best.  But each topic will provide where to learn more.

The book is broken down into 6 sections, each with 15-20 chapters.

“It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so.” – Mark Twain.le

Note: those topics labeled with "<< notes only" are notes for me, not you. Welcome to read, but consider unpublished.

Go to the bottom of this page for how to leave feedback and commit to the 100 in 100 challenge.

The Laws of Software Development


  1. Apply Systems Thinking (13)
  2. Must look at the whole
  3. Local optimizations typically lead to global problems
  4. Attend to flow
  5. How Delays Induce Work (1)
  6. Systems are complex but have patterns
  7. The lean paradigm
  8. How Time and Queue Size Relate
  9. Reinertsens blog

Driving From Business

  1. Drive from business value
  2. There is more than customer value (14)
  3. Business Evolution, not system evolution
  4. Product portfolio management
  5. The importance of not creating interruptions
  6. If you insist on off-shoring, do so in the least damaging manner  << Notes only.
  7. Balance plans with capacity

Management in Software Development

  1. Why Seeing the Value Stream Is So Important (4)
  2. Coordinating Teams With Backlog Management (6)
  3. If you are telling the "chicken and pigs story" you will not scale (11)
  4. Know you are managing time to market & Know How to Do it (15)
  5. Do not use velocity as a whip
  6. Lean management and culture 
  7. The role of lean management
  8. Understand how to manage key personnel 
  9. Understand that it isn't lack of people that's your constraint, it's lack of key people
  10. Use cross-functional teams as much as possible
  11. Dynamic Feature Teams
  12. Managing the work across projects and across teams
  13. Good management is leadership, good leadership includes coaching
  14. Release trains
  15. Key roles needed at scale – the TDM and ADM
  16. Lean Agile Framework
  17. Focus on predictability of production not on feature definition

Iterative Development at the Team Level

  1. Know the Power of Teams (19)
  2. When to use Scrum
  3. When to extend Scrum
  4. When to use Kanban
  5. Extending Kanban
  6. Core teams
  7. Specialization exists, honor it (3)
  8. Managing critical folks in large organizations
  9. Attend to WIP to improve flow & make teams interruptible
  10. Why story points
  11. Why small stories
  12. Know Why and How To Estimate (10)
  13. Time boxing vs flow
  14. Value of swarming – :flow when you can, pull when you must"
  15. Commit to velocity not scope

Agile Technical Practices

  1. Use Acceptance Test Driven Development (2)
  2. Emergent design (7)
  3. Understanding and Achieving Robust Architectures (16)
  4. Programming by Intention
  5. Lessons of Design Patterns (17)
  6. The design patterns you need to know
  7. Separate using from construction
  8. Consider Tests First (20)
  9. Sustainable TDD
  10. How To Avoid Redundancy - Shalloway’s Law and Principle (12)
  11. Encapsulate that
  12. Avoid over and under design
  13. Refactoring
  14. Refactoring to the open closed
  15. Continuously integrate

Transitioning to Agile and learning

  1. Learning What You Don't Know You Don't Know (18)
  2. Recognize the tribal nature of people
  3. Transition organization as a whole
  4. Understand the emotional aspect of change
  5. Do not attempt to jump more than the company can bear
  6. Where to start your agile transition
  7. How Successful Pilots Can Actually Hurt an Organization (5)
  8. How to select pilots
  9. What to look for when determining how you will transition
  10. Why Kaizen is so powerful
  11. Just Saying “Just Do It” Just Doesn’t Do It
  12. The importance of explicit policies
  13. Trim Tabs and Pick Up Sticks (9)
  14. The Technology Gap 
  15. De Bono's Thinking Hats
  16. The Fundamental Attribution Error (8)


Feedback requestedI I am requesting feedback as this site is being written.  Please suggest new topics and ask questions (or refute) presented topics.  However, please do not ask me what a line that does not have a link to a more detailed page means however.  You'll have to wait for the page. :)  Feedback can be given on any of the three groups listed on 

The 100 in 100 Challenge. I'm committing to add one entry each day.  I'm asking people to accept the challenge of reading them.  If you accept this challenge, please enter a comment on the blog that started it all and tell me why you are taking up the challenge - that is, what you'd like to learn.

Al Shalloway

CEO, Net Objectives