Steve Poling
Member for
8 years 7 monthsWriting software well is a real joy. I am interested in how Software Engineering can become a serious professional discipline and the methods for most effectively organizing the work. I successfully developed software using the "waterfall" but I got over that foolishness when I learned I'm not God. This started me doing prototyping. Now I think that "wicked" problems mandate an agile approach, but not cowboy coding. The approach is mandated by the problem. If it is completely understood, a BUFD waterfall is optimal. Otherwise an emergent design via agile is indicated. I am interested in the concept of "technical debt" as a metaphor for communicating the trouble you borrow when you cut corners. The catastrophic behavior of avalanches is another apt metaphor for troubled codebases.
Specialties: Cryptologic mathematician, speech recognition, digital signals processing, artificial neural nets, digital typesetting, financial software, object oriented development, test driven development, agile methods
All Articles by Steve Poling
All Stories by Steve Poling
|
When a Number Is Not a Number: Benefits of Random Test GeneratorsWe like to hope that we will consider all possible situations when devising our tests, but it’s all too easy to overlook the unusual cases. That’s the benefit of random test generators. We might feel comfortable after testing a few dozen test cases; these tools generate hundreds. With more stuff getting tossed at the wall, there is a greater likelihood that something interesting sticks. |
|
Testing a Software RewriteSuppose we’re looking at a system rewrite where the stakeholders have none of the original engineering documentation. (This isn't surprising; documentation becomes obsolete—or even misleading—as the system changes, and corresponding docs don't get updated.) What can we do? Here are some tactics to use—and risks to anticipate—when testing a system rewrite. |
|
Reduce Technical Debt by Using Unit Tests as DocumentationTechnical debt is an inevitable side effect of legacy code. Some code can (and should) be pruned, but institutional memory fades—what if there's a reason certain lines were included that may not be immediately obvious? Done right, unit tests can serve as documentation. Later on, these tests can illuminate what the developer was thinking when they created the code. |
|
When the Code Is Too Obvious to CheckHow many times does something seem too obvious to check? Most of the time this normal human response is a handy shortcut. Your brain tries to save you time—but you can’t always trust it. If your code malfunctions, each of those "too obvious to check" thoughts will bias your thinking about what caused the malfunction. We have to commit up front, before our thinking crystalizes, that the code will have to prove to us that it is correct. |
|
A Case for Test-First DevelopmentYou may feel you don't have time to write unit tests, but you really don't have time not to. Steve Poling makes the case that writing tests first not only will yield better code, but will help you get that code working right sooner. Here's how using a test-first approach changes your thinking about coding, lets you see mistakes immediately, and helps you create more testable code. |
|
Learn More from Tests That Stray off the Happy PathUnit tests exercise various paths through your codebase. Some are happy paths where everything you expect goes right. These tests are boring. The interesting tests are the ones where your code goes hurtling off the happy path. The trick is to capture the diversity of a multitude of unhappy paths without needlessly duplicating unit tests. Here's how you can improve the quality of your unit testing and fix it more effectively. |
|
Exposing False Confidence in Your TestsTesting can't tell you what's wrong with your code. It can only show what is not wrong with it. And though we cannot possibly conceive everything that might be wrong, it's important to stray from the "happy path." We need test cases that present bogus inputs and assert that they raise exceptions. That's how we can replace our false confidence with true assurance. |