Playing Dumb isn’t Agile
I believe that Agile software development is ideal for discovering what really needs to be built and to build it in a way that it will last, but I don’t believe that Agile is required on every project. There are many kinds of projects and many reasons for not doing Agile. I’ve written quite a …
Continue reading “Playing Dumb isn’t Agile”
Read MoreBuild What Users Want
Our users are only human and its human nature not to always know exactly what we want. I realize that sometimes we have to build software on specifications and all the requirements are needed to be identified upfront. But statistically, it is rarely the case that all requirements are needed. It turns out that nearly …
Continue reading “Build What Users Want”
Read MoreAggregation or Composition
I often get questions when I teach object-oriented programming about the difference between aggregation and composition. These are two relationships that are easy to confuse. Aggregation in the UML class diagram is represented by an open diamond whereas composition is represented as a closed or filled-in diamond. Related to this is the “uses” or “depends …
Continue reading “Aggregation or Composition”
Read MoreThinking with Objects
It took me more than a decade of doing object-oriented programming-and then teaching it-before I really started to understand the subtle power of using objects, and how to create behavior through the interaction of objects rather than through program logic. I struggled for many years with how to explain this different way of thinking. It’s …
Continue reading “Thinking with Objects”
Read MoreCommit Frequently
One metric that I think is most important to look at during an Agile transformation is the frequency of commits that developers make due to the build. This gives us a huge amount of information about several important things. First and foremost, it indicates the amount of friction in the build and how much work …
Continue reading “Commit Frequently”
Read MoreKeep Defects from Escaping
Toyota did not start out as a car company. They started by making industrial looms for the creation of textiles. They became a leading loom manufacturer by building looms that required minimal human intervention because they recognized that an operator’s time was expensive. If one operator could run a dozen looms instead of just one …
Continue reading “Keep Defects from Escaping”
Read MoreWhy Why
In my last post, I discussed barely sufficient documentation and I said that the best place to express what the code is doing is in the code itself. But there is another form of documentation that we often overlook. It’s actually the most important kind of documentation yet we rarely devote even a sentence to …
Read MoreBarely Sufficient Documentation
In Agile, when we say “barely sufficient documentation,” we’re not referring to user documentation. User documentation has been notoriously bad throughout the entire history of the software industry. As an industry, we must do much better with user documentation than we have in the past, but this post is not about user documentation, it’s about …
Continue reading “Barely Sufficient Documentation”
Read MoreTake Your Caller’s Perspective
As software developers, many of us have been trained to dive right into implementation. As soon as we learn about a problem, we think about how to code a solution. But this is not always the right approach. Sometimes, it makes more sense to step back and look at the big picture, to try to …
Continue reading “Take Your Caller’s Perspective”
Read MoreSlow Down to Go Faster
I know it seems like a paradox but often we have to slow down in order improve our productivity. We need to step back and look at what we’re doing and see if we can find more effective ways to meet our goals. A NIST study (http://www.cse.psu.edu/~gxt29/bug/localCopies/nistReport.pdf) showed that over 80% of software developers’ time …
Continue reading “Slow Down to Go Faster”
Read MoreChangeable Code
So, what are the practices that support changeability in code? There are surprisingly few, and I’ve written about them extensively here in this blog, in my book, and I discuss them in detail in my courses: inject dependencies, embody the SOLID principles, keep code quality high, and understand design patterns… There’s a lot to it …
Continue reading “Changeable Code”
Read MoreDoing More of What We Love
Developers love writing code. It’s what we’re good at. It’s what we do. But all sorts of things get in our way: Meetings. Reading and interpreting specifications. And the worst time-sink of all—debugging. Most of us would rather do anything other than debugging, but that’s where we end up spending a lot of our time. …
Continue reading “Doing More of What We Love”
Read MoreDon’t Be Scared to Touch Legacy Code
As Frank Herbert said in Dune, “Fear is the mind-killer.” He could have been talking about legacy code. As soon as we fear touching legacy code, we won’t do it. As a consultant, I know that merely giving my clients tools and techniques for working with legacy code isn’t enough, I also have to help …
Continue reading “Don’t Be Scared to Touch Legacy Code”
Read MoreFlying Blind
The way most software is developed—designing entire programs on paper and then typing them into a computer in their entirety before they run—is like flying blind. Software is virtual. We can’t see it or touch it. The only feedback we get is when we compile and run our program. But on a Waterfall project that …
Continue reading “Flying Blind”
Read MoreChange Your Mind, Again
When I was a kid I was told that it was a woman’s prerogative to change her mind. For some people, though, changing your mind can be seen as wishy-washy. We like to stand by what we say. We like to be right. But giving yourself the freedom to change your mind is one of …
Continue reading “Change Your Mind, Again”
Read MoreThink Small
The key to unlocking agility is to think small. The whole purpose of building software in time boxes is to help us get better at scope-boxing, which is working in smaller pieces—breaking large tasks down into smaller tasks. I’m not a big believer in using story points. It’s better to be able to break down …
Continue reading “Think Small”
Read MoreDomain Language
Software is a model. We’re used to thinking of models as physical models that occupy space, but software represents a different kind of model, not a physical model but rather a behavioral model. Behavioral models take place in time rather than in space. You can think of them as black boxes where some input comes …
Continue reading “Domain Language”
Read MoreWriting Good Tests
As Misko Hevery, the author of AngularJS, says in his outstanding Google Tech Talk series “Clean Code Talks,” most developers assume they know how to write a good test but they don’t. Knowing how to write a good test is paramount to being successful with TDD. Tests must be unique, expressive, and independent—easier said than …
Continue reading “Writing Good Tests”
Read MoreEarly Automation Experiences
We didn’t do a lot of automated testing as an industry back in the late 1980s, but I did. I was working for IBM on one of the first hypertext implementations, which later became HTML. Our authoring system created very complex data structures that required us to do extensive testing to validate they were correct. …
Continue reading “Early Automation Experiences”
Read MoreChangeability
What does changeability mean in the context of software? Software is soft so shouldn’t it all be changeable? Not exactly. It turns out we have to build changeability into code, but this is rarely done. To do this we have to understand the nature of software and the nature of change. Software doesn’t behave like …
Continue reading “Changeability”
Read MoreAn Object Model
If you were to draw out all the objects in your system and their relationship to each other at runtime, that would be a graphical representation of your object model. Object-oriented programming is about modeling the behavior of entities. It is a programming paradigm that, when used correctly, helps us build resilient systems that are …
Continue reading “An Object Model”
Read MoreAcceptance Criteria
Acceptance criteria are simple tests to tell us when we’re finished implementing a feature. Knowing when we’re done building a feature is extremely important to developers because we’re not always sure how robust a feature should be. We don’t like it when our code breaks in the field so we want our code to be …
Continue reading “Acceptance Criteria”
Read More