Just Telling Teams to Self-Organize Doesn’t Work
“Continuous attention to technical excellence and good design enhances agility,” is one of the principles of the Agile Manifesto. In retrospect, at their ten-year reunion, at least some of the original authors of the Agile Manifesto felt they didn’t state this strongly enough. I believe technical excellence doesn’t just enhance agility, it enables it. Cobbling …
Continue reading “Just Telling Teams to Self-Organize Doesn’t Work”
Read MoreBe Anthropomorphic
I have had the good fortune of working on two dolphin research projects in my life so far. Dolphins are highly intelligent and their brains are, on average, larger than ours. I like to say that I have the privilege of working with the two most intelligent species on the planet, dolphins and developers. When …
Continue reading “Be Anthropomorphic”
Read MoreHow Open-Closed are you?
Of the handful of programming principles that I live by, the Open-Closed Principle is perhaps the most important. I consider the Open-Closed Principle to be the central goal of all software development and what we should be striving for when doing development, beyond just getting our features to work. I was talking with Jim Shore, …
Continue reading “How Open-Closed are you?”
Read MoreThe Single Responsibility Principle
The Single Responsibility Principle says that any entity, whether a class, a method, or a module, should have a single responsibility. But what is a “responsibility” and how big is it? Is a feature a responsibility or a task or what? I like how Bob Martin defines a responsibility. He says any entity such as …
Continue reading “The Single Responsibility Principle”
Read MoreDon’t Test Private Methods
I often get the question when teaching developers test driven development (TDD), “How do you test private method?” The short answer is you don’t, but there’s also a longer answer that Michael Feathers gave in his book, Working Effectively with Legacy Code. Certainly, you could test private methods, and I’ve seen developers do all sorts …
Continue reading “Don’t Test Private Methods”
Read MoreMore Reasons Why Agile Works
Clearly, the success rate of Agile projects is higher on average than Waterfall projects. I propose that we can trace some of this success back to technical practices. In Waterfall development, there was no incentive to write good code. Developers got once chance to write a feature and once it works the feature was never …
Continue reading “More Reasons Why Agile Works”
Read MoreGo Deep Rather than Wide
When defining, building, and testing a system, we can go deep or wide. Deep means taking a vertical slice that provides functionality across layers of a system, end to end, which enables a feature. For example, we may enable a user to log in, which would include the client-side UI all the way to the …
Continue reading “Go Deep Rather than Wide”
Read MoreDon’t Write for Reuse
Reuse. This was the promise of object-oriented programming. Back in the early 1990’s we were told to move from C to C++ because it promoted reuse. That was wrong. The way to reuse code is through delegation, by calling a piece of code. Delegation has been around since assembly language so OO languages didn’t introduce …
Continue reading “Don’t Write for Reuse”
Read MoreWhat Makes a Good Test?
Many developers assume they know how to write a good test, but in my experience few developers really do. They test units of code rather than units of behavior and their tests become implementation dependent and break when the code is refactored. Rather than providing a safety net for developers to catch errors when refactoring, …
Continue reading “What Makes a Good Test?”
Read MoreIs Priority Best for Ordering a Backlog?
When I was first introduced to Agile I had a hard time understanding how to order the backlog. Agile says to do the most important, the most valuable work first but I used to think that was overly simplistic. If I’m building a house I shouldn’t build the master bedroom first just because that’s where …
Continue reading “Is Priority Best for Ordering a Backlog?”
Read MoreDon’t Show me your Private Parts
What’s a private method, why use them? Their purpose is to hide implementation details, the way we accomplish a task. We generally don’t want to share these details so we limit its scope and who can call it. Use private methods to share common implementations so a service can have different APIs for different client’s …
Continue reading “Don’t Show me your Private Parts”
Read MoreThe REAL Difference between Agile and Waterfall Development
What’s the real difference between Agile and Waterfall? Is it short iterations, standup meetings, having a ScrumMaster, or what? Clearly, there are many differences between Agile development and Waterfall development. Agile involves less planning and more feedback but those are not the major differences from Waterfall. Some people will tell you that it’s a “mindset” …
Continue reading “The REAL Difference between Agile and Waterfall Development”
Read MoreWhat Mr. Robot Says About Bugs
Sometimes we act as if bugs just appear in our code on their own, but we all know that’s not true. The bugs in my code were written by me. I didn’t mean to write them. I didn’t want to write them. But I did anyway. I remember when I first heard Al Shalloway refer …
Continue reading “What Mr. Robot Says About Bugs”
Read MoreWhat Managers Must Understand
Back in the 1990s, I was teaching a class at IBM’s wildly successful Cottle Labs in San Jose, CA. It was mid-week, halfway through the class, which had been going really well up to that point, when the students coming back from lunch looked like a train had hit them. Moments before they had just …
Continue reading “What Managers Must Understand”
Read MoreIdeal Days Aren’t Ideal
I consider myself a supporter of the #NoEstimates hashtag. It’s not that I think estimates are evil, it’s just they’re often unneeded or misapplied. If the effort to estimate a task is equal to the effort required to complete the task then is an estimate worth it? Estimates can be useful for measuring capacity or …
Continue reading “Ideal Days Aren’t Ideal”
Read MoreRequirements Aren’t Required
In traditional software development, up to half of all development time is spent writing, maintaining, and interpreting requirements. Even more than bugs, requirements are the single largest time sink in developing software. But what’s the alternative? How will developers build what the customer wants if they aren’t told what the customer wants? The full answer …
Continue reading “Requirements Aren’t Required”
Read MoreBuild Once Then Enhance
In his book *Mythical Man-Month,* Frederick Brooks says to build a system “three times” by designing, implementing, and testing software. But this approach tends to amplify our mistakes rather than allow us to learn from them. It’s based on the false assumption that we can articulate a system’s behavior in the design documents with sufficient …
Continue reading “Build Once Then Enhance”
Read MorePlaying All or Nothing
Let’s imagine that I run a roulette table with a one-dollar minimum bet. According to http://wizardofodds.com/games/roulette/ the odds are one in thirty-seven on a single-zero wheel that your number will come up. Vegas would pay back accordingly, so if you bet $1.00 on 18 and the little ball lands on 18, the dealer hands you …
Continue reading “Playing All or Nothing”
Read MoreBeyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software is Here!
I can’t begin to describe how excited I am to announce the release of my first book! Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, published by Pragmatic Bookshelf, is based on my decades’ worth of hands-on experience as a software developer, consultant, and educator. I have seen all …
Read MoreSeven Strategies for Continuous Delivery
Continuous delivery is the single most important step in agility. Regardless of whether you do big releases or not you should always build software incrementally so it is always in a releasable state. Why? Because the only way to know if code will work in a system is to test it in the system. This …
Continue reading “Seven Strategies for Continuous Delivery”
Read MoreSeven Strategies for Creating Better Names
Naming is a central part of programming and vitally important. Everything has a name and the name we give something should reveal something about what it does. The difference between good names and bad ones is a key factor in the maintainability of the software we write. Here are seven strategies for creating better names. …
Continue reading “Seven Strategies for Creating Better Names”
Read MoreSeven Strategies for Solving Problems Test-First
Using tests to drive development in TDD concertizes abstract requirements making them easier to understand and work with. This is a very powerful way of solving software problems while at the same time creating maintainable code. Here are seven strategies for solving problems test-first: 1. Think outside-in Before solving a problem we must first understand …
Continue reading “Seven Strategies for Solving Problems Test-First”
Read More