Sometimes you can’t make the project not suck right away. You need to do a pre-unsucking project to figure out the actual unsucking.
Oh my. Here’s a Project That Sucks. It sucks so much I seriously don’t (yet) know how to make it not suck. How crazy is that?
Good thing I that Making It Not Suck isn’t the immediate task. My job now is Figuring Out How It Might Potentially Be Made To Not Suck. In other words, it’s a pre-desucking evaluation. The deliverables: one report with a recommended technical process, and one report with business recommendations.
Continue reading “What to ask first”
When developing iteratively, what exactly constitutes premature optimization? When doing the simplest thing that could possibly work, what does it mean to “work”?
A couple of weeks ago, a question turned up on the BaseCamp site we use to coordinate one of my projects. One programmer asked what we thought of a certain calculation he was setting up on the database. It had to do with accumulating “rating” points of an item in a tree-shaped threaded discussion.
Continue reading “The W part of DTSTTCPW”
You probably can’t impose unit testing on a whole system all at once. But you probably can increase the portion of the code under test a little bit at a time. When you’re busy but need to make small changes, consider Sprout Method (59).
I am trying, with only partial success, to apply what I’ve learned in Working Effectively With Legacy Code by Michael C. Feathers.
Feathers is a huge advocate of test-driven development. He puts it out there on page xvi: “Code without tests is bad code.” He defines “legacy code” as, strictly speaking, any code that isn’t already under unit tests. At first it struck me as a funny definition, because obviously lots of code is written today–even by me–without unit tests, and how can it be right to refer to software nobody’s even thought of yet as “legacy”? But for purposes of the book it works.
Continue reading “Code Farming: Sprouting Some Methods”
Today, it’s more about programming .NET with an Access database. Last time, I explained the unique way Access handles JOIN. This time, let’s talk about a syntax error that masquerades as a missing parameter.
Continue reading “Programming with Access? Know this about "No value given for one or more required parameters"”
How can you run tests on something where the “output” is the motion of a sensor arm, or the “input” is a stream of weather data?
I learned an interesting, although in retrospect somewhat obvious, technique from Michael Feathers’s great book, Working Effectively With Legacy Code.
Suppose you have a class that can’t be unit-tested in any automated way because it has side effects or requires user input. Or, in the case of my application, it drives hardware that I don’t actually have readily at hand. NUnit and the like provide input to methods and test the resulting output. How can you run tests on something where the “output” is the motion of a sensor arm, or the “input” is a stream of weather data?
The short answer is that you really can’t, but that shouldn’t stop you from setting up unit tests.
Continue reading “Mock me to my (inter)face”
Another late night at the Old Programmers’ Club. This time, Tony and The Smartest Guy I Know talk about how Microsoft ruined the static keyword.
Last night I regaled The Smartest Guy I Know, as well as drsweetie’s high school pal Tony, with tales of how Kids These Days Don’t Know Anything and Nobody Does Things Right. It was a scene to warm the bitter soul of any software curmudgeon.
“So there I was,” I began, “optimizing the heck out of an ASP.NET application…” And my audience groaned–although I’m still not sure whether it was because they know how the story simply had to end, or because I was the teller and they couldn’t be sure that it would ever end. Because my stories get to be like that sometimes.
Continue reading “At the Old Programmer's Club”
You never need to compare to true.
I spotted this in some ASP.NET today:
if (confirm("Are you sure?")==true)
You never need to compare something to true though:
if (confirm("Are you sure?"))
And the whole if-boolean-then-boolean construct can be refactored out:
return confirm("Are you sure?")
It’s less to maintain, less to look at, and simpler to understand. That is all.