Most everything in writing software is about finding balance and making the right tradeoffs. We must understand the impact of our decisions on our work and seek to minimize cost while maximizing value. Sometimes we have to write a crappy implementation to get it to our customers but let’s acknowledge that we are doing it …
Continue reading “The Habit of Quality”
Read MoreWhy do some teams adopt an agile methodology and become wildly successful while other teams adopt agile and fail miserably? What is the difference? In order for software development to be successful we must “build the right thing” and “build the thing right”. Agile strives for both but without understanding the goals and how agile …
Continue reading “Why Agile Fails”
Read MoreI don’t believe in silver bullets for software development. Building software is very creative and I don’t think we can do it by just following a prescribed set of steps without thinking about what we are doing. And thank goodness. I don’t want to be in a field where I can go on automatic. I …
Continue reading “Why Agile Works”
Read MoreAgile methodologies seem to be taking root in recent years as more and more organizations realize that iterative development done correctly is a highly efficient way to build software. As I see agility gaining popularity I can’t help wondering what the next ten years will hold for agile development. I just returned from Agile Open …
Continue reading “2020 Hindsight: The Next 10 Years of Agile Development”
Read MoreFor many people their perfect day involves lounging on a beach somewhere tropical sipping a drink with a paper umbrella in it. That’s nice but my perfect day is somewhat different. Earlier this week I was teaching an Advanced Software Design class at Microsoft and it came close to being my perfect day. I love …
Continue reading “My Perfect Day”
Read MoreLast month I wrote an “Agile Tip of the Month” for the Agile University Newsletter. For those who don’t read the newsletter I thought I’d post it here: The creative genius working long hours churning out code that only he can understand; this is the cowboy coder. How did he get here? How do people …
Continue reading “The Vanishing Cowboy Coder”
Read MoreDecide what to do, figure out how to do it and then do it well. These are the three essential steps we perform over and over again in TDD. Each step is different and requires us to focus on different things. Separating out these steps helps us focus on each one at the right time, …
Continue reading “Reflections on the Three Steps of Test First Development”
Read MoreHow much code coverage should we have? I say 100%. Do we really need to test getter and setter methods? No and yes. We don’t need to verify the trivial behavior of getters and setters but it can be valuable to have a test for them so that their existence is specified. Likewise, I have …
Continue reading “How Many Tests Are Enough?”
Read MoreIf I get stuck and I don’t know how a complex algorithm should work I’ll write a test for an error case. Then I’ll write a test for the simplest non-error case I can think of and return a hard coded value. Then I’ll write another test case and see if I can figure out …
Continue reading “Triangulation”
Read MoreThe Denver ASDE class 12/1-3/09 went really well. In addition to developers, we had a program manager in the class who loved it. She said, “Software managers need this kind of training so they can communicate better with their developers.” Here are a few more comments from students: “Determining when to apply patterns and which ones to …
Continue reading “Agile Software Development Essentials class in Denver a Success!”
Read MoreKermit the Frog used to say that it’s not easy being green and he was right. In TDD we want to stay in the green as much as we can. When our tests are green life is good. Turning the red bar green can be easy at first but keeping it green can be very …
Continue reading “It’s Not Easy Being Green”
Read MoreI’ve already written about the importance of getting to the red bar and the value of a failing test but once we get the red bar we want to move on and get to the green bar as soon as possible. In fact, turning the red bar green, which is really what TDD is all …
Continue reading “Green Bar Guilty Pleasures”
Read MoreMany important things happen getting to the red bar. In a test first approach where we write our test before we write our production code, we define the method signature before we build its implementation. That means we are thinking about how to call a method before it is written. This reinforces designing to interfaces …
Continue reading “Celebrate the Red Bar”
Read MoreDon’t we get the most value from our tests when they fail? We may wear our seatbelt every time we get in the car but when we get into an accident and use our seatbelt is when we are most grateful for having it. This is also true with tests. It is not until a test breaks …
Continue reading “When Are Tests Most Valuable?”
Read MoreRarely is failure a good thing in life but in test driven development a failing test can be a very good thing. Many TDD developers dread the “red bar” but it is really worth celebrating and here’s why. Developers are often under the mistaken impression that TDD is about getting to the “green bar”. This …
Continue reading “In TDD Failures Can Be Good”
Read MoreOk, I get it. We’re all busy and we don’t have time to read long articles. That’s why I’m offering a new category on my blog called Bits and Pieces. They are few short paragraphs that get right to the point and offer some key distinctions for software developers in bit-sized chunks. There are also …
Continue reading “Bits and Pieces”
Read MoreImagine what would happen if you went to the gym every day, five days a week, 8 hours a day for years and years but only exercised your left bicep muscle. Your left arm would be huge in proportion to the rest of your body. This is what we do as developers. We exercise the …
Continue reading “The Visualization Muscle”
Read MoreMany people who do not write code think that software engineering is akin to civil engineering but is this an accurate metaphor? Software is built in virtual space and the rules of virtual space are different than the rules of physical space. In civil engineering the waterfall method works well; they plan, do and then …
Continue reading “Not Like Civil Engineering”
Read MoreSometimes I’ll ask my students if they think that commenting code is a good thing or a bad thing. Some people laugh. “Of course it’s a good thing,” they often say. But is this universally true? When I worked at IBM back in the ‘80s we had a programming standard that said every line of …
Continue reading “Code Comments: Good or Bad?”
Read MoreFor a good part of my early career as a software developer in the 1980s I didn’t really seriously consider the maintainability of the software I wrote. I was just concerned with getting it to run. Soon after that I would focus on trying to make it consume as little space as possible and to …
Read MoreI am kicking off this season’s VersionOne webinar series with a talk called Writing Quality Software on Wednesday, June 3rd at 12:00 pm Eastern Time (9:00 am Pacific Time). I’m excited because I believe that code qualities are at the core of good software. Here’s a description: Being non-physical, software quality is very different than …
Continue reading “Webinar: Writing Quality Software – June 3rd, 2009”
Read MoreIn order for agile projects to thrive they must embrace constant change by building software that is resilient to change.
Read More