Techniques of Design Has Become To Be Agile

by davidbernstein on January 25, 2012

Realizing that mastering Agile software development is more than just learning techniques, I am rebranding and changing the name of my company to (drum roll, please)…

To Be Agile

This new name (and website) reflects a new commitment to helping our community, not just do the Agile practices, but to be Agile with everything we do!

I hope you like the new website: I’ve moved all of my blog posts and other resources to it and will continue to update it with new resources and information. I will keep the old Techniques of Design website up for a while but I won’t be updating it. Please update your bookmark and contact information for me:




Thank you!

David Bernstein,



by davidbernstein on December 15, 2011

I remember a poster at my college that said “All great minds don’t think alike but they do make connections.” I think this is especially true in software development where we are all largely self-taught.

When I ask my students what the most valuable thing they got from my training was, I get a lot of different answers such as the design techniques, the different yet highly valuable way of understanding patterns, the focus on quality, but one of the most valuable things developers tell me is the ability to form a common language for design so they can communication with their team mates in higher fidelity.

We desperately need ways to communicate better in software development. Language is vague and the software we write needs to be precise. It is often a challenge to express our design ideas to others and so they are not given the best opportunity.

I think we sometimes get caught in the fear that makes us worry about several things at once. When we have a conversation about multiple things at once it is easy to get lost. I see this sometimes, developers will jump from topic to topic, not really addressing any one of them so no real progress is made. By contrast, when we stay focused and work through each issue, one at a time, we can make a great deal more progress.

When we have disagreements on design approaches it is rarely about the current requirement and almost always about what could happen. But that is anyone’s guess. I try not to engage in what could happen because it is often just speculation. Instead, I draw on good development practices to help mitigate the risk of changing my design later and just focus on implementing the task at hand.

Of course, if I know a feature will be needed soon and it is easy to accommodate it now, I will go ahead and do it, or at least write my code in such a way so it is easy to add later. Remember, Kent Beck says, “Do the simplest thing possible, not the stupidest.”

When I do get into an argument with another developer I apply what I call the ten minute rule. If I can’t convince them of my approach in ten minutes I usually give in to their way. This is because I know it is usually easy to change a design from their way to my way if it becomes apparent that it is better to do so.

Changing a design to accommodate a new feature doesn’t always have to be a huge undertaking, especially if we have unit tests that cover our code, and we build software using Agile practices. I find building software in this way is far more successful and less stressful than trying to anticipate what the customer might want in the future. When we get good at refactoring and see that going from one design to another in many situations can be easy to do, a lot of the fear of having to get it right the first time goes away and development becomes much more fun!


Become a Better Problem-Solver

by davidbernstein on November 17, 2011

Interestingly enough, I do not find many sources discussing problem-solving skills for software development. Most books are concerned with the mechanics of a language or framework and almost every software design book I read teaches a procedure rather than to pay attention to the clues in the problem itself. Certainly, universities do not teach these skills that we are just starting to recognize as highly valuable in our industry. As a result, there is a huge difference in the effectiveness of developers.

Software developers are among the smartest people in the world, no doubt. This is because we are constantly solving new problems. It takes an incredible attention to detail in order to build even the simplest of programs. But intelligence is not enough; we also need skill and strategy.

I’ve made it my professional mission in life to find effective techniques for building software and I’ve amassed a set of techniques that I’ve witnessed expert developers use to their great advantage. I have not only learned these skills but also how to teach them so they become top of mind and used. This is important because you probably already know some of the skills I teach in my classes but if you don’t consciously connect why those skills are important, they will probably not become habits for you and you won’t get the benefit of using them naturally.

Where to start? Start by believing that there are better ways to solve problems. If you don’t then you’ll have no motivation to try. Provide proof to your brain that others have these skills and that the skills they possess are learnable and worth learning. Then ask yourself different questions–questions you haven’t asked before. Focus initially on the reasons and benefits of your goals rather than the mechanistic of how to achieve them. This can help you see different perspectives that can open you up to finding better solutions.


Solutions Thinking

by davidbernstein on October 5, 2011

How we think about a problem has a direct impact on the solutions that are available to us. What is or isn’t possible is oftentimes a fluid thing based on what we know and also what we believe. In software, virtually anything is possible but the level of difficulty often depends on our starting assumptions.

I’ve had the privilege of working with thousands of developers over the last quarter of a century in my career. The difference between a good developer and a super-star developer can be a factor of 100 to 1 (yes, really, I know developers who are one hundred times more productive than an average developer). I don’t think that is true for other professions. For example, I can’t imagine a carpenter being 100 times more productive than his fellow carpenter or a lawyer able to handle 100 times more cases than her colleagues but this can be true for software developers.

If you are a developer then you probably have the experience of thinking about a very difficult problem and then suddenly find a solution that makes the problem almost trivial. If you had this experience then you know there is the potential for huge productivity gains; we just need to have those epiphanies more often.

Flashes of insight may appear to be random but there’re not. There are things we can do to induce them. In fact, I would say that problem solving skills are really the thing that distinguishes great developers from average ones. Once we are able to understand a problem and see its solution the rest is merely typing.


Do You Play All or Nothing?

by davidbernstein on September 27, 2011

Would you pay $10 to spin a roulette wheel with a potential payoff of a million dollars? Maybe so but you probably wouldn’t do it if you had to win 100 spins in a row, right?

Risk is part of life; we have to take them but we want our risks to be calculated. Yet when it comes to software development we often set ourselves up to play “all or nothing”.

On most projects where integration happens at the end of the project we accumulate risk and it continues to accumulate throughout the project. Each line of un-integrated code holds potential risk. We set ourselves up so that every feature has to work on order for any feature to work. One tiny bug can keep the entire system from working. Not even the most hard-core gambler would take a game with those kinds of odds yet we do it every time we embark on a waterfall project. No wonder that most software projects are not successful!

There is a better option.

Integrate as you go. As soon as you have a new bit of functionality that compiles, integrate it, first on your local machine where your core unit tests run, and then on a build server where all the automated tests run. Do this several times a day and you will always have a buildable system. This drops your risk of being able to ship something to close to zero. Maybe you won’t get every feature done by the ship date but you’ll have something and if you plan well then what you’ll have are the most important features.

Maybe this seems obvious to you but in my experience the biggest companies building the most complex systems do not do this. Waterfall projects are still the norm and “integration hell” as we’ve called it is the inevitable conclusion of a waterfall project.

If you still write code the old fashioned way where you have to completely implement a feature before you can even compile then you may as well come to work blindfolded with one hand tied behind your back. The power of your computer is idle, unable to check you work, help you with syntax or verify the code you just wrote will “play nice” with the rest of the code in the system.

We are software developers. Our job is to automate business processes and the first place we should look is to our own work! Don’t set yourself up to fail. Take little wins as frequently as possible by integrating as you go. It will give you confidence and momentum and you will always have something to show for your efforts.


Integrate Early and Often

by davidbernstein on August 25, 2011

A story, use case, or requirement is not done until it is integrated into the rest of the build system. “Well, it works on my machine,” is not a statement we want to hear on an Agile project. A story that is not integrated into the build is not complete and worth zero story points because it may hide significant risk.

When code is not integrated into the build it can hide the worst kind of bugs that only show up when it interacts with the rest of the system. On waterfall projects we do not get to integrate our code until the end of a project, right before we plan to ship—the worst possible time. These projects turn into an “all or nothing” situation and one tiny bug can keep us for shipping anything.

On Agile projects we eliminate risk every time we integrate our code into the build so we minimize the amount of risk we have as we go as we progress through a project. This is why we want a fast and uncomplicated build process, so developers will integrate often. How often? I usually say we should tell developers to integrate their code at least once a day but this is a bit of a trick.

Usually, the last person to integrate their code at the end of the day finds bugs in their code and because they can’t leave while the build is broken they have to stay late to fix it. After doing this a few times developers quickly realize that the sooner they integrate the fewer problems they encounter and so they end up integrating several times a day.

This means we find bugs almost immediately after we write them while the code is still fresh in our minds. Because the time between cause and effect is short we begin to change how we write our code and start adopting better practices. This is one of the main benefits of continuous integration, it shortening the time between writing a bug and finding it.


Don’t Do (Up Front) Design

July 28, 2011

I worked on many projects in my 30 year career as a software developer. I’ve worked on embedded systems, operating systems, collaboration software, downloadable applications, and enterprise applications—the whole gambit. I’ve done coding, testing, managed developers, been a ScrumMaster, Product Owner and virtually every other role on a development team. The thing I enjoy the [...]

Read the full article →

The Scrum Excuse

June 28, 2011

“We don’t need to do <blank>, we’re doing Scrum.” I’ve heard some beginning Scrum teams say this. They think that doing Scrum is their get-out-of-jail-free card, freeing them from doing architecture, design, documentation or even thinking about what they are doing. Compared to waterfall, Scrum is a lightweight process but it is a process and [...]

Read the full article →

Do You Mentor?

May 25, 2011

One of the things that established professions like medicine and law have that we as software developers don’t have is some form of mandatory mentoring. For doctors it is residency, for lawyers it is internships, even carpenters need to apprentice with a master carpenter before they can become a master themselves. But in software development [...]

Read the full article →

Making the Right Tradeoffs

April 27, 2011

Compromises are part of life. We must make tradeoffs if we are going to ship product but we want to make the right tradeoffs and that can only happen when we have information to back our decisions. Understanding good design principles and practices help us make informed technical decisions. The principles give us guidance in [...]

Read the full article →