DaedTech

Stories about Software

By

ChessTDD 32: Squashing a Subtle Bug

This was kind of a wild episode, inasmuch as recording oneself writing code gets wild.  This was the second bug driven out by the acceptance tests, but this one was subtle and buried fairly deep in the application logic.  This was another half hour episode as I employed a variety of techniques for hunting down and fixing a bug.

What I accomplish in this clip:

  • Fixed the bug discovered last time.
  • Left a few legitimate tests as breadcrumbs along the trail.

Here are some lessons to take away:

  • Use binary search kinds of techniques when solving problems.  For instance, if a two part boolean expression is causing a test to fail by returning the wrong result, comment out/delete one of the branches to see which one it is.  This helps you narrow the search without invoking the debugger or squinting at the code, scratching your head.
  • It’s important, when you have a failing acceptance test, to drill in and recreate the scenario in unit tests with less setup context around it.  This ensures that the problem is, in fact, a problem of the code under test rather than something going on with the acceptance test setup.  Getting this second failing test prevents you from chasing phantom bugs in your production code.
  • I try to use the debugger as little as possible when doing TDD, especially with the continuous testing tool.  But, for the occasion that you’d have to write a lot of assumption checking asserts, the debugger can be a handy way to see a number of different values that you want to check.  This was relevant when I wanted to see 4 different coordinate values.

By

Carnival Cash: The Cult of Seniority

Alright, screw it. Let’s burn the boats. I said I wasn’t going to get into this until I released the book, but the idealist career advice post I had planned doesn’t make sense without a discussion of corporate seniority.  If you haven’t read this recent post, in which I outline the terms pictured below, you’ll probably want to read it for reference or this one might not make as much sense to you.  In this post, I’m going to defend a thesis that the best career advice I could offer to any knowledge worker, counter-intuitive though it may seem, would be to avoid earning seniority at a company.

In a prequel to this series I seem to be starting, I define the essential conundrum of the corporate pragmatist.  This post is going to focus on corporate idealists and the essential conundrum that they face, and it’s going to address a reader’s question while we’re at it.  That question provides a good lead-in to the context here.  Paraphrased, it was, “while going it alone may be good advice for seasoned, senior developers, shouldn’t junior developers hitch their wagons to a company for a while, giving a lot of extra effort and working their way up while learning the ropes?”  My simple, off-the-cuff response is, “oh, dear God, no!”  But the more nuanced response I’ll expand on here is, “that may be a strategy, but be very, very careful, because here be dragons.”

Dragons

Read More

By

ChessTDD 31: Look, We Caught a Bug!

A bit of time went by between when I recorded the code and when I narrated it, so pardon the unusual amount of rust there. But this episode was particularly interesting because an actual bug emerged and I fixed it. Yay for acceptance tests. After that, a second bug emerged, but I ran out of time. So there’s definitely a todo for episode 32.

What I accomplish in this clip

  • Got away from the C&P implementation of “then” for the new style of tests and implemented a usable one.
  • Discovered and fixed a bug in king’s moves.
  • Discovered another bug to fix next time.

Here are some lessons to take away:

  • When you’re stumped by behavior, particularly in integration tests, the continuous testing tool can help you run experiments very quickly.  Add a precondition assert to verify that your assumptions are correct.
  • TDD is not a catch-all against bugs, by any stretch.  I had a dumb bug in the implementation of the King class that I failed to catch, and everyone following along failed to catch (assuming someone would have reported it, anyway).  It wasn’t until I started simulating real production usage that these bugs started to be revealed.  Acceptance tests are critical.
  • The balance between ATDD and TDD is beneficial.  You’ll see going forward that when I find problems, I tend to use increasingly specific tests the way that you might be used to using step-through in the debugger.  Narrowing the scope of the problem with tests rather than the debugger has the advantage of leaving a trail of breadcrumbs that become guards against regressions as you go on.
  • This ATDD/TDD stuff works.  As you can see, I caught 2 bugs that could have escaped into production.
  • Never commit with red tests, obviously, but I also say never take a break with red tests (the way I would have to between clips).  If you have to go, comment or delete that red test, so that you can start fresh with green next time and reintroduce it.

By

Defining The Corporate Hierarchy

Rites of Passage

Think back to being a kid, and you can probably remember a rather dubious rite of passage that occurred when you figured out that you weren’t going to be a sports player, lead singer, or Hollywood star.  You probably felt sad, but your parents and older siblings likely breathed sighs of relief that you’d never be explaining to people that a manual labor gig was your “day job.”  State lotteries notwithstanding, giving up on improbable dreams is considered by adults to be a sign of maturity in budding adults.

If you think about this, the easy message to hear is “you’re not going to be great, so give up.”  It’s depressing and oft-lamented by college kids having mini crises of identity, but it’s actually a more nuanced and pragmatic message, if a poorly communicated one.  It’s that the expected value of these vocations is horrendous.  For baseball players, actresses, and rock stars, there’s a one in a million chance that you’ll make ridiculous sums of money and a 999,999 in a million chance that you’ll make $4,000 per year and have half of it paid to you in beer nuts.  So the expected value of going into these positions is about a $4,200 per year salary and a handful of beer nuts.  So the message isn’t really “give up because you’ll never make it” but rather “steer clear because anything but meteoric success is impoverishing.”

The better play, we tell our children, is to head for the corporate world where the salaries range from minimum wage in the mailroom to tens of millions per year for CEOs of companies that create stock market volatility. Most importantly, you can find every salary in between.   So if you aim for the heights of CEO and fall short, mid-level manager making $140K per year isn’t a bad consolation prize. And so a funny thing happens. We consider it to be a rite of passage to abandon the delusion that you’ll be Michael Jordan, but we encourage the delusion that you’ll be Bill Gates until people are well into middle age.

That’s right, “the delusion that you’ll be Bill Gates.” You won’t be him. You won’t be a CEO, either, unless you pop for your state’s incorporation fee and give yourself that title. You’re about as likely to “work your way up” to the CEO’s office over the course of your career as any given child is to luck into being the next multi-platinum pop star. So, it’s a rather strange thing that we tsk-tsk children for indulging pie-in-the-sky fantasies past a certain age while we use nearly identical fantasies as the blueprint for modern industry. Kid wants to be Justin Bieber? Pff. Thirty-year-old wants to be Mark Zuckerburg? Keep working hard, kicking butt, and acing those performance reviews, and someday you’ll get there!

Pff. Read More

By

My Blog: If I Build It, Will They Come?

I’m writing a quick post tonight in response to a question I received today.  I actually intended to address this later, but I have a number of posts about what Michael O Church calls CS666 in various stages of readiness, and I’m trying to juggle not offering rabble-rousing cynicism without solutions, avoiding a stream-of-consciousness brain dump of material for my book, and having interesting material to post.  My opinions on the flaws of modern corporate structure will have to wait, and I don’t have my Visual Studio setup with me, so there’s no Chess TDD to be had tonight, either.

The question(s) I’m answering, paraphrased: “there seems to be little point to blogging if no one is reading, so how do you get readers?”

On Low Readership and Blogging Nihilism

GlumGuy

Read More

By

Chess TDD 30: Starting To Be Idiomatic With SpecFlow

This episode went so poorly, I thought briefly about scrapping it and starting from scratch… but that would not be true to the premise I established at the outset where I’d do this unedited, flubs and all.  Having finished with the AsciiBoardBuilder, it was time to start putting Darren Cauthon’s ideas into play.  You can read up on that here.  I sized up what he had done and, in spite of knowing very little about SpecFlow, decided that I only needed certain parts of it for my purposes.  This turned out to be a mistake as something that I thought he had just added for illustrative/cosmetic purposes was decidedly non-cosmetic, and it took me a lot of floundering to figure that out.  Now, that’s not uncommon for me, per se — I’m a “figure it out by breaking it” sort of person, but it’s not exactly the stuff of scintillating videos.

Here’s what I accomplish in this clip:

  • Got the first idiomatic SpecFlow test written in the new feature.  Barely.  And ugly.

Here are some lessons to take away:

  • When using someone else’s example as a template for learning something you don’t yet know, don’t jump the gun and start tweaking and changing things before you get the example working.  Do as I say, not as I do.
  • No matter how long you’ve been doing this, you’ll still make off by one errors and get array bounds arithmetic wrong when it’s complicated.  Improve the odds in your favor by using TDD or, by some other mechanism that you come up with, if applicable.
  • When you find yourself writing a good bit of logic in test code (meaning, you’re writing a lot of code that you aren’t test-driving), ask yourself whether you could move the logic to production or find some other way to tease it out with TDD.  You can see by my floundering here that you become decidedly less productive when you’re writing a lot of code and just hoping for the best.
  • Using NCrunch, it’s pretty easy to run quick experiments to help with my debugging.  One such example was to start hard-coding the row/column indices to see for which ones exceptions were actually generated.
  • Similarly, putting a temporary precondition assert at the top of a test method to check your assumptions can also be a big help.  This is what started me down the path of realizing my mistake with the table’s header.  I finally sanity-checked my assumption that the table had 8 rows to find that it really only had 7.

By

Please Direct all Inquiries to My Agent

I got an email from a recruiter not too long ago.  I suppose that’s not a surprise, given how I’ve made my living, but what might surprise you is that I usually respond to recruiters, and politely at that.  They’re human beings, trying to earn a living in a way that I don’t envy.  These days, my relatively stock reply is to thank them for reaching out, tell them that I’m pretty happy and thus pretty picky, and to offer to chat anyway, if they just want to network.  As a developer with some community presence, a serial freelancer, a consultant, and general entrepreneur, it never hurts to talk for a few minutes and make a connection.  This recruiter persisted, and said that, even if it wasn’t a current fit, something might make sense later.  Sure, why not?

Come Hear about this Depressing Opportunity!

When she called, we exchanged pleasantries and she asked what I’d been doing lately in a professional capacity.  I explained that the last 2 years had seen me as the CIO of a company, running an IT department, and then going off on my own to do freelance development, consulting, coaching, and a cadre of other activities.  At this point, she began to explain what life was like for line level devs at her company and asking what tech stack I preferred.  I sighed inwardly and answered that I’d been engaged in coaching/mentoring activities in Java and .NET recently, but that I didn’t care too much about language or framework specifics.  She then asked about my career goals, and I scratched my head and explained, honestly, that I was looking to generate enough passive income to work on passion projects.  She became a little skeptical and asked if I had recent development experience, clearly now concerned that whatever it was that I’d been doing might not qualify me to crank out reams of line-o-business code or whatever fate she had in mind for me.

The conversation had become deeply tiring to me at this point, and I steered it to a close relatively quickly by telling her I had no interest in line-level development positions unless they were freelance, B2B, part time sorts of engagements that weren’t very long in duration (and not bothering to mention that I’d probably sub-contract something like that since I don’t have an abundance of time).  She assured me that all of the positions she was hiring for were W2, full time positions but I should give her a call if I changed my mind and felt like being an architect or something, and that was that.

I hung up the phone, sort of depressed.  Honestly, I wished I’d never taken the call more profoundly than if I’d interviewed for some plum gig and been rejected.  This just felt so… pointless.  I couldn’t really put my finger on why, and indeed, it took my subconscious some time to kick into useful mode and deposit it coherently into my active brain.DevOpportunityCost

Read More

By

Clean Communication

Do you remember your early days of software development in a team setting? If you do, and you’re anything like me, you’ll have awkward memories of trying too hard. Eager to show that you were ready for a seat at the big kids’ table, you’d dive into new assignments with the sort of over-eager attitude that made the grizzled veterans around you roll their eyes knowingly and, perhaps, smile faintly indulgent smiles.

It was time for you to shine. Adding a new radio button option to an existing series of options was the perfect chance for you to show that you knew what the Composite Pattern was. And, why use any of the collection types in the standard library when you could roll your own and use a method header comment to prove, mathematically, that it sorted itself in O(n log n)? Any unimaginative clod could write code that did what the users needed it to do, but it took a visionary, like you or me from days past, to write code that mostly did what users needed it to do while showcasing lessons from all 4 years of your undergraduate programs. Each feature that you delivered was a chance to add to your own personal portfolio at the company.

scan0002

Read More

By

What Story Does Your Code Tell?

I’ve found that as the timeline of my life becomes longer, my capacity for surprise at my situation diminishes. And so my recent combination of types of work and engagements, rather than being strange in any way to me, is simply ammo for genuineness when I offer up the cliche, “variety is the spice of life.” Of late, I’ve been reviewing a lot of code in a coaching capacity as well as creating and giving workshops on story telling and creative writing. And given how much practice I’ve had over the last several years at multi-purposing my work, I’m quite vigilant for opportunities to merge story-telling and software advice. This post is one such opportunity, if a small one.

A little under a year ago, I offered up a post in which I suggested some visualization mnemonics to help make important software design principles more memorable. It was a relatively popular post, so I assume that people found it helpful. And the reason, I believe, that people found it helpful is that stories engage your brain far more than simple conveyance of information. When you read a white-paper explaining the Law of Demeter, the part of your brain that processes natural language activates and decodes the words. But when I tell you a story about a customer in a convenience store removing his pants to pay for a soda, your brain processes this text as if it were experiencing the event. Stories really engage the brain.

One of the most difficult aspects of writing code is to find ways to build abstraction and make your code readable so that others (or you, months later) can read the code as easily as prose. The idea is that code is read far more often than written or modified, so readability is important. But it isn’t just that the code should be readable — it should be understandable and, in some way, even memorable. Usually, understandability is achieved through simplicity and crisp, clear abstractions. Memorability, if achieved at all, is usually created via Principle of Least Surprise. It’s a cheat — your code is memorable not because it captivates the reader, but because the reader knows that mapping what she’s used to will probably work. (Of course, I recognize that atrocious code will be memorable in the vivid, conversational sense, but I’m talking about it being memorable in terms of its function and exact behavior).

It’s therefore worth asking what story your code is telling. Look at this code. What story is it telling?

Read More

By

ChessTDD 29: Finishing up the ASCII Board Builder

I actually recorded this episode right on the heels of the last one, so that I could keep a good rhythm with the ASCII builder class.  I finished that class up here.

Here’s what I accomplish in this clip:

  • Finished the class, as I mentioned.
  • Moved the class into the production code.

Here are some lessons to take away:

  • Sometimes you’ll write a test that goes red while writing the first line.  According to the strictest discipline, you should make that green and then keep going.  But if it’s a question of writing a few more characters or another line or something to get your fully realized red test into place, I, personally, think that’s okay.
  • If you’re going through your red-green-refactor cycle and, during the course of a refactoring, you introduce lines of code that none of the tests are hitting, be very careful.
  • If you’re in the middle of a refactoring and you start to wonder if maybe you aren’t changing the way the inputs and outputs could work, back out the refactoring work and get to a known, green state.
  • I’ve no doubt covered this before, but TDD is a great way to force yourself to think about how your API behaves with non-happy path inputs.  You’re writing tests that tease out implementation, rather than coding to get something working in a GUI.

Acknowledgements | Contact | About | Social Media