I’m bettin’ u already got some code. If yer a geek in a substantial code base in an org w/more than a half-dozen other geeks, i’m bettin’ u already got a lot of code. In your team’s head, if not somewhere on an out-of-date piece of paper, there is a picture of "our code". I want to draw a box somewhere where there’s room in that picture, and I want to label it "rigorous". Let’s call it the rigorous playpen. […]
The Rigorous Playpen See Full Post
Companies spend a great deal of time and energy seeking to get their teams synchronized. Several forces motivate these efforts. It’s worth taking a second to look at these. One force: the belief that synchronization provides steering points. The notion here is that since we’ve just synchronized, now is a good time to react to the market and adjust the direction in which the project is headed. Second: the belief that no given team is able to do all the
Sync Points Reduce Our Trade’s Effectiveness See Full Post
If u think the semaphore mechanism in your library works, then test to the level of setting the semaphore. If u think it doesn’t work, then u need another library or o/s. Testing across threads is for people who are testing semaphores. If u think that your JSON transport works — from your UI’s perspective or your backend’s perspective, then test to the level of feeding it JSON. If u think it doesn’t work, then u need another library. Testing
What TDD Tests Prove See Full Post
A Simple Optimization Problem Hey, it’s GeePaw! Got a little optimization issue for you. Let’s look at some code. It’s easy stuff, so I’ve just used pseudocode here. Take a look. The program starts by entering a loop that runs 50 times. Inside that loop, it calls the Read method. It then enters another nested loop, this time for 100 times. And in that inner loop, it calls the Scan method. Finally, we exit both loops, and we call the
Optimizing A Program (And Programming) | Video See Full Post
Continuing last night’s wobbly muse on graceful and awkward collaborators… In the light of day, I think I see four possible responses to the situation when your new code depends on an awkward collaborator or collaboration: Ignore it (possibly just for now). Write your test anyway and suffer the expense. This is a legitimate judgment, tho one the hardcore among us have to be dragged kicking and screaming towards. Don’t automate a test for it. Again, entirely legitimate, and actually
Awkward and Graceful 2 (A Recovery) See Full Post
Software Programs can be understood as (potentially huge) orchestras playing in concert. Depending on your level of abstraction, you might imagine systems, subsystems, layers, packages, objects, or even functions as the individual players. (Aside: Folks often make major distinctions in these abstractions, but to my touch, they feel all the same thing, just with ever larger labels on ever subsets. and at bottom, 100% of it is Von Neumann architecture code.) For the purposes of this conversation, I’ll be thinking
Awkward and Graceful Collaborators See Full Post
Five Underplayed Premises Of Test-Driven Development (Transcript) Hey, it’s GeePaw! I’m here to tell you today about five underplayed premises of Test-Driven Development. These premises form the kind of fundament under which almost all TDD proceeds. And when I say that I’m a TDDer, I almost always mean I am operating inside the little ring formed by these five test-driven development premises. Let’s check them out. We’re In This For The Money The first premise of TDD is what we
Five Underplayed Premises Of TDD | Video See Full Post
Time, finally, for the steering premise, from the five underplayed TDD premises. The steering premise says "tests & testability help steer design & development". What we’re saying here is that tests are first-class citizens in the mob of factors that shape our system, with a voice that counts, all the way through development. Think of the factors we take in to account when we make software. They range all over, from market considerations, to platform, from our geek skillset to
Underplayed: The Steering Premise In Depth See Full Post
Today, let’s talk a little about the chaining premise, from five underplayed tdd premises. The chaining premise says "test a chain by testing its links". Like the other premises, it’s easy to make it pithy, but it has vast ramifications about when we’re doing TDD. When we talked about the money premise, I gave a long, likely partial, list of ways TDD supports that premise. Did you notice I never mentioned the customer? TDD is for developers. The people it
Underplayed: The Chain Premise In Depth See Full Post
The judgment premise is one of five underplayed tdd premises. The judgment premise is simple to word and vast in its extent. It says, "tdd relies absolutely on individual humans using their human judgment." you might ask yourself, "what doesn’t rely on human judgment?" but there are lots and lots of activities that are entirely mechanical, judgment-less, and geekery is full of them. We work with judgment-less systems every day. We call them "computers".there’s merit to "algorithmizing", that is, making
Underplayed: The Judgment Premise In Depth See Full Post
