Posts Tagged - technical-excellence

Agile Principles: Progress Requires Working Software

Working software is the primary measure of progress.

– Principles behind the Agile Manifesto

Pixel perfect design mockups, UML diagrams, detailed user stories, automated tests, thousands of lines of code and hours of discussions. These are just a few examples of the endless amount of stuff we can spend time creating, tweaking, editing, testing and reviewing. However, nothing shows progress quite like working software.

So what is working software? That’s going to be different for every team, but a good starting point might be “software that is deployed to and delivers value to the customer”. This means it might be ugly, imperfect, not-absolutely-intuitive and likely somewhat incorrect and that’s okay; you’re one step closer to making it meaningfully better.

This post is part of my series on the principles behind the agile manifesto. You can find the others here:

More in the Agile Principles Series

Read More

Do You Make This Common Debugging Mistake?

Hi, my name is Clayton and I use ruby-debug. There, I said it. As a matter of fact, I use ruby-debug a lot, I use it too much. I’m not even solving complex problems or debugging nitty gritty internals, I’m just being lazy. Sure, ruby-debug is a really awesome tool, but we abuse the hell out of it. If you’re reading this and thinking “hey, that’s what I do” then you’re making a mistake, a mistake that’s hurting your code.

How Debuggers are Abused

Marking breakpoints and stepping through your code, evaluating each line and variable is a pretty typical practice. There are some developers who literally figuratively could not live without their debugger. I suspect this is most common in languages where IDEs are prevalent, but lets not forget about the modify-refresh-repeat paradigm in the PHP world.

Sometimes, when I come across some unexpected result or outcome, I will immediately add my debugger statement and start stepping through the code line-by-line echoing variables, assignments and conditionals to the terminal trying to track down my problem. Recently, I had a colleague scoff at the idea of not having ruby-debug for their rails project. The idea that we need this tool for day-to-day development is absurd.

Our One Step Program

When you’re testing the logic and/or output of your code with a debugger you’re making the mistake of not writing automated tests.

There are few problems that are solved via the manual and time-consuming process of a debugger that cannot be solved with an automated test. If you’re confused about the output of a calculation or method, write a quick unit test for that method. When the logic of your application doesn’t appear correct based on the input, maybe an integration test is in order to evaluate the flow of your program.

Not only do you get rid of the debugger baggage, you gain all of the other benefits that go along with testing.

BONUS: Excuse Resolution Table

If you’re getting ready to excuse your debugging behavior, check this list of resolutions first:

But excuse, I need a debugger…

Write more tests. Don’t have tests? Quit your job.

Read More