If you have heard of XP, you probably think of Test-Driven Development and Pair Programming, two of the most challenging XP practices both in ideology and in execution. You may not know it, but even if you have never even attempted these two contentious practices, your software team is probably already doing several of the other practices. Here are the top three I suspect you are already doing.
Read MoreNaming is one of the most difficult tasks of development. My last team debated names of things because communication is crucial, but it is a challenge. Naming a paradigm, pattern, principle, namespace, class, variable, or whatever is an attempt to communicate with another engineer about a broader set of related ideas using a condensed term. Computers don't care what you name things in your code; It all becomes binary once it's compiled anyway.
Read MoreI carried this new found love of unit testing with me to each new workplace. I taught the passion and associated skill set to whichever colleagues would listen. At my last workplace, I declared myself the _Unit Test Evangelist_ and taught my team everything I knew, and together we improved on the knowledge and skills I brought with me. We had great philosophical discussions on how to think of approaching legacy code with tests, and what kind of tests were the most important to write in various situations.
Read MoreI have incredible respect for the individuals on my last team, so I became actively excited when the opportunity arose to disagree. I knew my teammates would listen to and try to clarify my ideas, and I would afford them the same dignity. The result of such a debate rarely ended in us agreeing on my or anyone's idea as it was originally presented. The process of clarification and debate would polish each idea until one was clearly the best idea given what we presently knew.
Read MoreThe spirit of the phrase, "Fail faster" is simple: In order to find success, you need to get through the necessary failures quickly. Getting stuck on a failure, or giving up after a failure means you've stopped actively failing, which means you can't ever hope to succeed.
Read MoreOne of the reasons I'm so attracted to this philosophy is that it applies to far more than just software engineering. This principle has been championed by the greatest social activists in history, and ultimately is the way forward in times of risk or threat.
Read MoreSince my MockBridgeConsole exposes me ways to observe method call counts, I simply write an assertion that I've called the PressGreenButton() method once.
Read MoreThat team was the most high-performing team I’ve ever been on… We saw many other benefits, but the bottom line for the business is that we built valuable software much faster.
Read MoreThe value of knowing how to get started testing cannot be understated. Once you build a little momentum, each successive test is a little easier to write.
Read More