Reader Charles sends a question I've frequently had when consulting with testing organizations who are weary of having code thrown at them "over the wall."
Charles
From your experience in software, what are some good practices you have found for what is now known as "Unit Test?"
I have mine, I want to see if we have similar experiences.
I also have a motive, I get the opportunity to write our "Unit Test Procedure", so I want to capture "Good Practices" that developers can use.
Ack!--Unit Test Procedure!!! I wish we could have names like, "Menu of Good Unit Test Practices, Choose One or More that Make Sense for your Unit, or Use and Add a New Practice to the Menu of Good Practices (Include Provenance or Example)."
Jerry
Honor Unit Testing
1. Well, that's probably number one, the name and prestige you give to the process. If you belittle it, you will have poor results. If you reward it ... finish the sentence. I don't recall if we even had a name for it in the early days. It was just assumed that any pro would do a damn good job of this activity, not to be embarrassed by unit bugs found in integration test or system test--or god help us, in production.
Build Small and Simple
2. The next most important thing is to design to build in testable pieces. Small as possible, but no smaller. Cleanly structured, with no testing traps like hidden memory that might make the code not really reentrant.
Be Completely Open
3. Next is complete openness, getting as many eyes on it as you could get, but certainly not just one pair.
Test First
4. Today what we did is called Test Before Code, or perhaps Test Before Design. Ideally, we sketched out a set of test cases before putting pencil to coding pad. (We didn't have terminals or PCs in those early days.) These were punched into cards and put in the permanent test case library.
Take Advantage of Individual Skills and Help Each Other
5. After that, I recall things breaking down into tactics favored by each individual. Generally, we unit tested each other's code, and anyone having trouble could and did call on anyone else to help out.
Don't Green Dot
I think if people did these things today, we'd be in a lot less trouble. I know because there are people who do these things today, and they tend to stay out of trouble. On the other hand, people who just throw code at a compile and say "it's unit tested" as soon as they see a green dot, tend to be in trouble all the time.
Comments welcome!
Beautiful prose and insight.
ReplyDeleteA rose by any other name, still stinks just as sweet.
At the end of the day, it always circles back to why do you do what you do.
My favorite is "Test Before Code, or perhaps Test Before Design."
ReplyDeleteI preach it with my customers but often it is hard to sell since what you sell is culture change.
Not only it is hard to change culture, it is also hard to show quick results. That is why many executives do not buy into such apporach.
Both software vendors and customers like to sell/buy tools/products.... selling/buying services is harder i think....
Jerry, what's your advice on how to sell quality more effectively? How do I show quick results to executives once new culture is sold.
Thanks
I believe it is fair to write that I came a generation after Jerry Weinberg. Still, I always tested my code units as best I could before giving them to someone or something else.
ReplyDeleteI think for me, it is because I hate to be embarrassed, look stupid, whatever. It killed me (still does) when someone finds a mistake in my work.
I guess this is some sort of insecurity that drives me to do good all the time. That insecurity can be destructive in many instances, but perhaps it is good in writing and testing code.
Searcher wrote:
ReplyDelete"Jerry, what's your advice on how to sell quality more effectively? How do I show quick results to executives once new culture is sold."
Great question, though sometimes exactly the wrong question. In the case of unit testing, for example, I would avoid trying to sell executives until you have some real experience to show for it. If you look at the principles, yoiu'll notice that there's no real reason to involve execs in any of it. They simply don't have to know that you're doing unit testing differently, or doing it at all.
Do it first, document results, THEN if you wish, go to execs and show them the improvements in their terms, like fewer bugs going forward and shorter, more reliable delivery time.
And, as with all improvements, start the exec involment by asking them what they would consider improvements, then framing your presentations in those terms. For instance, if they don't care about bug counts, leave them out, but translate them into $$ saved or earned.
Hi Jerry and Searcher,
ReplyDeletewhat about that question considered on the lower level, a developer wants to do unit testing as his own initiative, should he "sell" it to his supervisor/tech lead when he expects resistance (like 'we don't have time')? doing tests he're going to increase time of performing single tasks but finally increase quality (and save bug fixing time).
I think it may be reasonable to follow your opinion also on that level. That's developer responsibility to do a good job so he does not need to sell it, just do it.
What's your thoughts? Is relation between tech leads/dev managers and their execs similar to ralation of developers to tech leads or not?
Seeker wrote: "What's your thoughts? Is relation between tech leads/dev managers and their execs similar to relation of developers to tech leads or not?"
ReplyDeleteThey are certainly similar in the dangers of micromanaging. A manager should be first concerned about WHAT employees are doing, NOT HOW they are doing it.
The only time the manager should become concerned with HOW is when and employee's WHAT is not up to a desired level. At that point, the manager's job is to see that the underperforming employee (or team) gets what they need to come up to snuff.
What they need might be resources, training, or motivation. What they seldom need is the manager stepping in and micromanaging the task. That generally makes things worse, at any level.
BTW, if the lower-level employee is always running to his/her manager for approval of ever aspect of their job, then there's another problem.
"I hate to be embarrassed, look stupid, whatever. It killed me (still does) when someone finds a mistake in my work."
ReplyDeleteI know that feeling myself, but gave it up when I managed to truly internalize Carol Dweck's research on mindset. These days, any thinking I do about my programming process starts with the premise that I make mistakes, I always did, and I always will. Really dumb mistakes.
I have somewhere a highlighted quote from Stroustrup about assertions, something along the lines that, of course you would use them only sparingly, not use them on trivial things like checking for NULL pointers. I used to think that way, until I realized the darnedest thing: NULL pointer errors still crop up in my code. So now, I don't try to pretend I don't make mistakes, and you'll find assert(ptr != NULL) is not an uncommon occurrence in my code.
I assume Stroustrup just doesn't get NULL pointer errors in his code. And now, neither do I! I get assertion errors instead, which usually help me quickly locate the bug (and more importantly, help me convince myself my code is correct when I read it).
In the words of philosopher Andy Clark, my brain seems to be bad at logic, good at Frisbee, so instead of imagining that such a talented fellow as myself should not be making simple errors, I try to push my intelligence outside of my skull, into the outside world, with practices such as "excessive" assertions so I can (stealing from Clark's words again) make the world smart so I can be dumb in peace.