Don’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 MoreSeven Strategies for Building Smaller
Big tasks are hard to work on. When we break a big task down into smaller tasks they become much more manageable. Suddenly, insurmountably large tasks become manageable as a series of smaller tasks, each of which is easily achievable on their own. Building smaller simplifies tasks making them easier to define, create, and verify. …
Continue reading “Seven Strategies for Building Smaller”
Read MoreSeven Strategies for Vanquishing Waterfall
What makes a software development project Waterfall and what makes it Agile? Different people answer this question differently. For a lot of teams, Agile is having a daily stand-up meeting and working in two-week sprints. For other teams, Agile is doing all of the practices in Scrum, Lean, and XP. Which is right? I say …
Continue reading “Seven Strategies for Vanquishing Waterfall”
Read MoreSeven Strategies for Fostering Innovation
True innovation means pioneering into territory no one has ever been in order to discover something new. Not everyone can do this but fortunately for the rest of us some can. Still, it can be helpful to find ways of supporting innovation. Here are seven strategies for fostering innovation. 1. Believe it’s possible There’s a …
Continue reading “Seven Strategies for Fostering Innovation”
Read MoreSeven Strategies for Growing as a Software Developer
People end up as software developers from a variety of backgrounds. Regardless of how we became software developers, if we want to stay on the leading edge of the industry we must be constantly learning and growing as developers. Here are seven strategies for growing as a software developer. 1. Do your own project Having …
Continue reading “Seven Strategies for Growing as a Software Developer”
Read MoreSeven Strategies for Fixing Bugs
Bugs are the bane of the software industry. They can be difficult to find and costly to fix. How we deal with bugs has a big impact on our software development process. We can use bugs to show us ways of improving our process so that similar bugs aren’t created again. Here are seven strategies …
Continue reading “Seven Strategies for Fixing Bugs”
Read MoreSeven Strategies for Burning Down Risk
Developing software is risky and expensive. Software is formless and hard to understand. Subtle interaction can cause software to affect seemingly unrelated components. A good development process focuses on mitigating risk by finding problems early, before they become showstoppers, and while there’s still time to resolve them. 1. Integrate continuously Creating a system that can …
Continue reading “Seven Strategies for Burning Down Risk”
Read MoreSeven Strategies for Measuring Value in Software
Software is different from tangible goods and it must be measured differently. The tasks that developers do are different from day to day, so we can’t directly measure productivity in any meaningful, normalized way. I often advise teams not to measure velocity because it can send the wrong message and give management the wrong goals. …
Continue reading “Seven Strategies for Measuring Value in Software”
Read More