Symbolic links for WinXP
Hurrah – symbolic links have arrived for WinXP; via Junction.
C:>junction.exe c:Test c:WINDOWS
Thanks for this great tip Nick
Try/Catch for SQL!?
Thanks to Nick Sertis for this trick – who knew TSQL could do try/catch statements!
Very useful when you need to write data manipulation scripts for production databases.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | BEGIN TRY
BEGIN TRAN
--Some SQL
COMMIT TRAN
END TRY
-- Catch the errors on the inserts
BEGIN CATCH
ROLLBACK TRAN
SELECT ERROR_MESSAGE()
END CATCH |
For a software craftsman, reducing technical debt should be as much of a habit as typing
Filed under: Refactoring, Software Craftmanship, Technical Debt
I was involved in an interesting group discussion with fellow craftsmen yesterday on Technical Debt at the 2009 Software Craftsmanship conference.
The question put to the group was: “How should a team make time to reduce technical debt?”
I was interested that there was a totally unanamious response – “You shouldn’t”. “You should be doing tiny pieces of technical debt reduction all the time”.
Previously I have advocated creating technical debt reduction stories, and trying to schedule those into the iteration plan. People thought this was in principal the wrong strategy; and indeed in my experience this approach doesn’t work.
The group felt that in general tackling technical debt reduction though large scale refactorings was the wrong approach – rather a craftsman should be making incremental improvements every time they touch the code.
Bob Martin’s Boy Scout Rule: – check in your code a little cleaner than what you checked out – encapsulates this principal. Its the little refactorings that you make – removing a tiny piece of duplication, changing a variable name to better reveal intent; extracting an expression into a intention revealing method – that, over time, result in a clean, maintainable code base.
In a way, this is similar to implementing the “Fixing Broken Windows Theory” in software development. The theory is that having a zero tolerance attitude towards the little things makes a huge impact on the so called “bigger” things.
Its perhaps easier understood if you consider what happens if you don’t care about the little things. Its about the attitude – if I couldn’t care enough to clean up a messy bit of code; will my team mates care about a few broken tests? If its okay to have a few broken tests; then it’s probably okay to ignore some bugs. If its okay to ignore bugs; then who really needs to care about well defined acceptance tests? And if the team doesn’t care about precise acceptance tests; why should the business care about unambiguous requirements. You get the picture.
Its the little things, added up, that result in technical debt reduction.
