TDD is hard. It is also really, really valuable. My friend Mark Levison provides ideas and advice on overcoming objections and dealing with the technical and organizational challenges associated with TDD.
Monthly Archive: January 2009
Understand objections. They exist for a reason. Understand the reasons, and find solutions to those issues. Dismiss the reasons, and you will not gain traction, you’ll gain obstacles.
Jay Flowers has the goods.
This article starts off with an amusing anecdote about over-engineering, and then provides a bunch of insights into the usefulness of Apache Tomcat as a low-cost, lightweight servlet engine for your J2EE apps. Then he talks about something he wrote to help maintain Tomcat servers. Anyways, if you’re looking to simplify your web stack, consider …
See here for the start of this series. Imagine you have a small number of customers, possibly one. And, you have essentially zero competition. That is to say, not only do you not have other organizations offering competitive products, your customers don’t really have effective alternatives other than to work with you. Even better is …
Glen Alleman has an interesting post, where he devalues Unit Testing, in favor of testing requirements. I wonder what he thinks of Behavior Driven Development tools, such as EasyB. Those would seem to be a closer fit to what he’s looking for.
These aren’t earth-shattering insights, but it’s nice to have some reminders of how to make the whole bug tracking process a little easier for everyone involved.
Click here for the whole series Would you use a Ferrari to haul your big bags of mulch for your garden? Would you use a bulldozer to excavate the fossilized bones of a rare dinosaur? Probably not. Those aren’t the right tools for the jobs. Agile development techniques were designed as a way to “optimize …
I’m seeing a lot of people opining on the limitations of Agile. I believe that this is a good thing, because every philosophy/methodology needs to spend some time in self-reflection. First, the general principles: . Some projects have lots of change requests, some have very few. . Some projects have lots of competitive threats and …
Cleaning out my to-read lists – this is a paper/tutorial from November on agile architecture. I looked through the list, it seems similar to what I would do myself as an agile architect, although the article is more thorough than I would usually be. I don’t know that it necessarily defines an ‘agile’ architecture – …