DaedTech

Stories about Software

By

10x Developer, Reconsidered

Unless my memory and a quick search of my blog are both mistaken, I’ve never tackled the controversial concept of a “10x developer.” For those who aren’t aware, this is the idea that some programmers are order(s) of magnitude more productive than others, with the exact figure varying. I believe that studies of varying statistical rigor have been suggestive of this possibility for decades and that Steve McConnell wrote about it in the iconic book, “Code Complete.” But wherever, exactly, it came from, the sound byte that dominates our industry is the “10x Developer” — the outlier developer archetype so productive as to be called a “rock star.” This seems to drive an endless debate cycle in the community as to whether or not it’s a myth that some of us are 10 or more times as awesome as others. You can read some salient points and a whole ton of interesting links from this jumping off stack exchange question.

Read More

By

The Retreat of the Introvert

If you’ve ever been nervous at a cocktail party or similar event and spilled a drink, you have an acute understanding of how time can elongate. There’s the second your hand brushes the glass and the second the glass offers its liquid to the expensive carpet, and while the seconds are right next to one another, it seems as though minutes or even hours pass in between them. In periods of duress, time spreads out, like (to borrow the words of T.S. Eliot) a patient etherized upon a table.

When you’re an introvert, this happens when social situations become volatile. And, by “social situations,” I don’t mean cocktail parties exclusively, but really any sort of interaction with others. It could be that you’re put on the spot at a meeting in which you weren’t expected to talk. It could happen at a night out when some friend volunteers you for karaoke at the bar. It could happen from something as simple and apparently routine as your girlfriend saying “we need to talk” when the two of you are eating Chinese at home. There’s a trigger and then the elongation occurs and it seizes you, demanding action that you know to be socially impossible. But if you gave in, it would be oh so sweet…

Read More

By

ChessTDD 26: At Last, Acceptance Tests

Let’s get the excuses out of the way: busy, more work coming in, vacation, yada-yada.  Sorry for the delay since last time.  This episode is a short one just to get back on track.  I haven’t been writing much code lately in general, and I was already stumbling blindly through SpecFlow adpotion, so this was kind of just to get my sea legs back.  I wanted to get more than one acceptance test going and start to get a feel for how to divide the acceptance testing effort up among “features” going forward.

Here’s what I accomplish in this clip:

  • Cleaned up the dead code oops from last time.
  • Defined an actual feature file for spec flow, with four real acceptance tests.

Here are some lessons to take away:

  • I don’t really know how Specflow works very well, so that floundering around after pasting in the same text seemed to fix the problem is my way of avoiding programming by coincidence.
  • No matter what you’re doing (unit tests, production code, or, in this case, acceptance tests) you should always strive to keep your code as clean and conformant to the SRP as you can.
  • When you don’t know a tool, go extra slowly with things like rename operations and whatnot.  I’m referring to me changing the name of the spec flow files.  It’s easy to get off the rails when you don’t know what’s going on, so make sure you’re building and your tests are green frequently.

By

What is Your Next Action?

I just got back from a long weekend vacation and am still getting settled and back into the swing of things, so this is going to be another relatively short post.  I’ll soon return to your regularly scheduled extended rants and code-cast posts, but I need a little slack in the meantime.

For the last six months or so, I’ve been making a 5 hour drive twice a week.  This has provided me with a lot of opportunities to listen to books through Audible and Overdrive, and I’ve been listening to a lot of non-fiction stuff that runs the gamut from tech to sociology to science.  Recently, I took a suggestion from a comment in a previous post and read/listened to “Getting Things Done.”

Read More

By

Aggregation of Indignities

I’m about to head off for a small vacation, so I’ll leave you with a relatively short post until I pick things up, probably a week from now.

If one were to track the small indignities of life that add up to serious grievances, it’s temping to think that these would be expressed in terms of, “things I have to do but don’t want to.” If you listen to someone talk about quitting a job, you’d hear about the rolled up grievances and imagine the small indignities. “I can’t stand my boss” would really be a series of things like, “have to go to his status meeting” and “have to respond to emails at all hours of the night.” You can imagine the exercise with other things that fill up the occasional exit interview that’s honest.

But at its core, I don’t think it’s “things we don’t want to do but have to do anyway” that create the important grievances, but rather, “things we think are stupid but have to do anyway.” There are plenty of things that I don’t really want to do, but know make sense, and so I do them anyway. Going to the dentist, working out for the most part, getting up in time to go to a meeting even after sleeping for only 4 hours come to mind. I make the best of the situation because I know these things make sense, and any resultant unhappiness is fleeting.

It’s the things that I think are stupid that result in unhappiness that is more than fleeting. If I have to get up to go to the dentist to have my teeth cleaned, I suffer through and then, after, think, “well, my teeth feel great, and I don’t have to do that again for six months, so, alright, onto the rest of my day.” If I have to go to the DMV because Illinois randomly decided that I owe them $200 for some new tax and the ‘convenience fee’ for online payment is $45, I’ll be in a seriously bad mood while I do it and then still residually salty for the rest of the day.

Back in the exit interview, “I can’t stand my boss” doesn’t actually expand do “I didn’t like being in the status meeting” but rather, “I hate attending those pointless status meetings.” It doesn’t expand to “have to respond to emails at all hours of the night” but rather “have to respond to emails at all hours of the night when there’s no reason it couldn’t wait until morning.” Most people are basically diligent and will do the unpleasant stuff… if they feel it carries forward some purpose.

When it comes to sources of perceived stupidity or pointlessness, I can think of three loose categories:

  1. Institutional/Bureaucratic
  2. Inadvertent/Earnest Disagreement
  3. Posturing/Malicious

Clipboard

The first category exists at most institutions to varying degrees and is straightforward enough: it’s your TPS reports and other infantilizing things that you have to do because someone, somewhere once got sued for something.  The second category boils down to “team lead pulls rank on you about a course of action and you have to go along with what she says, even though you think it’s stupid.”  The third category is “mid level manager shows up 10 minutes late to meeting because he can’t bother to be on time and then dispatches someone to get coffee for him, even though that person is a professional engineer.”  It’s a uniquely aggressive action in that both parties are completely aware that the aggressor is manufacturing stupidity, but the message is essentially, “I have the power to make you do stupid things, and I enjoy using it.”

These things aggregate and fester over the course of time, probably roughly in the numbered ordered above.  People will usually tolerate a maze of bureaucracy more easily than semi-regular demeaning interactions, all other things being equal.  But everyone has some kind of aggregated stupidity score that, when hit, triggers them to quit.  Actual ‘scores’ will vary widely depending on situation and individual personality.

The moral of the story is this.  By and large, people aren’t going to burn out and be driven away by hard or unpleasant work alone.  They’ll burn out and be driven away by work that they think is stupid.  So if you’re focused on retention and morale, pay specific attention not so much to whether people are doing grunt work but rather the value (or lack thereof) they perceive in the work.

By

Programmer IS A Career Path, Thank You

If you’re a programmer, think back for a moment to the first time you hear the career question. You know the one I mean, even if you don’t recognize it as the question: “do you see yourself on the architect track or the management track?” Caught off guard, you panic momentarily as you feel that you have about 5 seconds to decide whether your long term future involves lots of UML diagrams and flow charts or whether it involves lots of Power Point presentations and demanding TPS reports from underlings. If you’re like most, and you were to answer honestly, you’d probably say, “neither, really, because I kind of like writing code.” But you don’t give that answer (I never did) because you’d effectively be responding to a career development question with, “I have no interest in career development.” But let’s put a pin in that for a moment.

Imagine a kid going to law school and graduating to go work at a law firm somewhere as an associate, doing whatever it is that associates do. Now imagine a conversation where a partner at the firm pulls this associate aside and says, “so, have you thought about your future? Do you see yourself as more of a partner in the firm, continuing to practice law, or do you see yourself as more of a lawyer-manager?” I imagine the response would be, “what on Earth are you talking about? I’m a lawyer. I want to practice law and be a partner. What else is there?”

Why is it okay (or would it be okay, since this conversation would never actually take place) for an ambitious lawyer to say, “I just want to be a lawyer” and not for an ambitious programmer to say, “I just want to be a programmer?” For the purposes of this post, I’m going to leave that question as rhetorical one. I’m actually going to answer it at length in the book that I’m starting to write, but until the publication date, I’ll leave the why as an exercise for the reader and just posit that it should also be okay for a programmer to say this.

I’d like to see a culture change, and I think it starts with our current generation of programmers. We need to make it okay to say, “I just want to be a programmer.” Right now, the only option is to ‘graduate’ from programming because failure to do so is widely construed as failure to advance in your career. If you become a line manager (or the diet version, project manager), you stop writing code and become the boss. If you become an architect, you kinda-sort-usually-mostly stop writing code and kinda-sort-sometimes-maybe become sorta like a boss. But however you slice it, organizational power and writing code have historically been mutually exclusive. You can play around with teh codez early in your career, but sooner or later, you have to grow up, take your hands off the keyboard, and become a boss. You have to graduate or risk being the metaphorical ‘drop-out’ with the title “Super Principal Fellow Engineer,” who looks great on paper but is generally ignored or smiled at indulgently.

ProgrammerGraduation

That’s going to change sooner or later. As someone who has looked for work and looked to hire pretty steadily for a number of years, I’ve witnessed an increase in developer salary that is both sharp and sustained. As the average software developer’s wage starts to creep into 6 figure territory, it’s simply not possible to keep the pecking order intact by paying overhead personnel more and more ungodly sums of money. Just as it makes no sense for a law firm billing out at $500/hour to hire a “lawyer manager” as a 1 mil/year cost center, it eventually won’t make sense to pay a quarter million a year to a pointy-hair, when Scrum and basic market forces both offer the allure of a self-managed team. In both cases, overhead work still happens, but it reports to the talent rather than ordering it around and demanding status reports.

How quickly it changes is up to us, though. We can change this culture, and we can change it pretty quickly, I think. The first thing you can do is fix it in your mind that being an “architect” or “project manager” or “manager” isn’t a graduation and it isn’t a rite of passage. It’s an agreement to do something different than what you’re doing now. Nothing more, nothing less. The second thing you can do is vote with your feet.

I’m not advising that you do anything drastic, but rather that you take stock of your circumstances. Are you at an organization where programming is clearly viewed as how you bide time until you get promoted to a boss’s chair? If so, consider adding a new criterion to your next job search. Look for organizations that feature prominent industry figures, such as conference speakers, authors, or people with some “tech celebrity.” These are the organizations that are the “early adopters” of the lawyer/partner dynamic of “best at the trade calls the shots.” If you hook up with these organizations, nobody is going to ask you what “track” you see taking you out of programming. They’ll assume that you’re there because you’re deadly serious about programming as a profession, interested in learning from the best, and interested in subsequently becoming the best.

Sooner or later, we’ll hit some kind of critical mass with this approach. My hope for all of our sake is that it’s sooner. Because the sooner we hit critical mass, the sooner you’ll stop having to explain that doing what you love wasn’t a backup plan for failing to rise in the ranks.

By

Cutting Down on Code Telepathy

Let’s say that you have some public facing method as part of an API:

CustomerOrder is something that you don’t control but that you do have to use. Life is good, but then let’s say that a requirement comes in saying that orders can now be post-dated, so you need to modify your API somewhat, to something like this:

Great, but that was really painful because you learn that publishing changes to your public API is a real hassle for both yourself and for your users. After a lot of elbow grease and grumbling at the breaking change, though, things are stable once again. At least until a stakeholder with a lot of clout comes along and demands that it be possible to process orders through that method while noting that the order is actually a gift. You kick and scream, but to no avail. It has to go out and it has to hurt, and you’re powerless to stop it. Grumbling, you write the following code, trying at least to sneak it in as a non-breaking change:

But then you start reading and realize that life isn’t that simple and that you’re probably going to break your clients anyway. Fed up, you decide that you’re going to prevent yourself ever from being bothered by this again. You’ll write the API that stands the test of time:

Now, this can never be wrong. CustomerOrder can’t be touched, and the options dictionary can support any extensions that are requested of you from here forward. If changes need to be made, you can make them internally without publishing painful changes to the API. You have, fortunately, separated your concerns enough that you can simply deploy a new DLL that handles order processing, and any new values supplied by your clients can be handled. No more API changes — just a quick update, some testing, and an explanatory Word document sent to your client explaining how to use the thing. Here’s the first one:

There. A flexible API and the whole “is gift” thing neatly handled. If they specify that it’s a gift, you handle that. If they specify that it isn’t or just don’t add that option at all, then you treat those equally as the default case. Important stakeholder satisfied, and you won’t be bothered with nasty publications. So, all good, right?

Flexibility, but at what cost?

I’m guessing that, at a visceral level, your reaction to this sequence of events is probably to cringe a little, even if you’re not sure why. Maybe it’s the clunky use of a collection type instead of something slicker. Maybe it’s the (original) passing of a Boolean to the method. Perhaps it’s simply to demand to know why CustomerOrder is inviolate or why we couldn’t work to an order interface or at least define an inheritor. Maybe “options” reminds you of ViewState.

But, whatever it is, doesn’t defining a system boundary that doesn’t need to change seem like a worthwhile goal? Doesn’t it make sense to etch painful boundaries in stone so that all parties can rely on them without painful integration? And if you’re going to go that route, doesn’t it make sense to build in as much flexibility as possible so that all parties can continue to innovate?

Well, that brings me to the thing that makes me wince about this approach. I’m not a fan of shying away from the pain of “icky publish/integration” instead of going with “if it hurts, do it more and get better at it.” That shying away doesn’t make me wince in and of itself, but it does seem like the wrong turn at a fork in the road to what does make me wince, which is the irony of this ‘flexible’ approach. The idea in doing it this way is essentially to say, “okay, publishing sucks, so let’s lock down the integration point so that all parties can work independently, but let’s also make sure that we’re future proof so we can add functionality later.” Or, tl;dr, “minimize multi-party integration coordination with hyper-flexible API.”

So where’s the irony? Well, how about the fact that any new runtime-bound additions to “options” require an insane amount of coordination between the parties? You’re now more coupled than ever! For instance, let’s say that we want to add a “gift wrap” option. How does that go? Well, first I would have to implement the functionality in the code. Then, I’d have to test and deploy my changes to the server, but that’s only the beginning. From there, I need to inform you what magic string to use, and probably to publish a Word document with an example, since it’s easy to get this wrong. Then, once you have that document, I have to go through my logs and troubleshoot to discover that, “oh yeah, see that — you’re passing us ‘shouldGiftwrap’ when it should really be ‘shouldGiftWrap’ with a capital W.” And if I ever change it, by accident or on purpose? You’ll keep compiling and running, and everything will be normal except that, from your perspective, gift wrapping will just quietly stop working. How much pain have we saved in the end with this non-discoverable, counter-intuitive, but ‘flexible’ setup? Wouldn’t it be better not to get cute and just make publishing a more routine, friction-free experience?

The take-away that I’d offer here is to consider something about your code and your software that you may not previously have considered. It’s relatively easy to check your code for simple defects and even to write it in such a way to minimize things like duplication and code churn. We’re good at figuring out how not to have to keep doing the same thing over and over as well and to simplify. Those are all good practices. But the new thing I’d ask you to consider is “how much out of band knowledge does this require between parties?”

It could be a simple scenario like this, with a public facing API. Or, maybe it’s an internal integration point between your team and another team. But maybe it’s even just the interaction surface between two modules, or even classes, within your code base. Do both parties need to understand something that’s not part of the method signatures and general interaction between these entities? Are you passing around magic numbers? Are you relying on the same implicit assumptions in both places? Are there things you’re communicating through a means other than the actual interactions or else just not communicating at all? If so, I suggest you do a mental exercise to ask yourself what would be required to eliminate that out of band communication. Otherwise, today’s clever ideas become tomorrow’s maintenance nightmares.

By

Agile Methodologies or Agile Software?

Over the last couple of months, I’ve been doing mostly management-y things, so I haven’t had a lot of trade craft driven motivations to pick Pluralsight videos to watch while jogging. In other words, I’m not coming up to speed on any language, framework, or methodology, so I’m engaging in undirected learning and observation. (I’m also shamelessly scouring other authors’ courses for ways to make my own courses better). That led me to watch this course about Agile fundamentals.

As I was watching and jogging, I started thinking about Agile Manifesto and the 14 years that have passed since its conception. “Agile” is undeniably here to stay and probably approaching “industry standard.” It’s become so commonplace, in fact, that it is an industry unto itself, containing training courses, conferences, seminars, certifications — the works. And this cottage industry around “getting Agile” has sparked a good bit of consternation and, frequently, derision. We as an industry, critics might say, got so good at planning poker and daily standups that we forgot about the relatively minor detail of making software. Martin Fowler coined a term, “flaccid Scrum” to describe this phenomenon wherein a team follows all of the mechanics of some Agile methodology (presumably Scrum) to the letter and still produces crap.

It’s no mystery how something like this could happen. You’ve probably seen it. The most common culprit is some “Waterfall” shop that decides it wants to “get Agile.” So the solution is to go out and get the coaches, the certifiers, the process experts, and the whole crew to teach everyone how to do all of the ceremonies. A few weeks or months, some hands on training, some seminars, and now the place is Agile. But, what actually happens is that they just do the same basic thing they’d been doing, more or less, but with an artificially reduced cycle time. Instead of shipping software every other year with a painful integration period, they now ship software quarterly, with the same painful integration period. They’re just doing waterfall on a scale of an eighth of the previous size. But with daily standups and retrospectives.

There may be somewhat more nuance to it in places, but it’s a common theme, this focus on the process instead of the “practices.” In fact, it’s so common that I believe the Software Craftsmanship Manifesto and subsequent movement was mainly a rallying cry to say, “hey, remember that stuff in Agile about TDD and pair programming and whatnot…? Instead of figuring out how to dominate Scrum until you’re its master, let’s do that stuff.” So, the Agile movement is born and essentially says, “let’s adopt short feedback cycles and good development practices, and here are some frameworks for that” and what eventually results is the next generation of software process fetishism (following on the heels of the “Rational Unified Process” and “CMM”).

That all played through my head pretty quickly, and what I really started to contemplate was “why?” Why did this happen? It’s not as if the original signatories of the manifesto were focused on process at the exclusion of practices by a long shot. So how did we get to the point where the practices became a second class citizen? And then, the beginnings of a hypothesis occurred to me, and so exists this post.

The Agile Manifesto starts off with “We are uncovering better
ways
of developing software…” (emphasis mine). The frameworks for this type of development were and are referred to as “Agile Methodologies.” Subtly but very clearly, the thing we’re talking about here — Agile — is a process. Here were a bunch of guys who got together and said, “we’ve dumped a lot of the formalism and had good results and here’s how,” and, perversely, the only key phrase most of the industry heard was “here’s how.” So when the early adopted success became too impressive too ignore, the big boys with their big, IBM-ish processes brought in Agile Process People to say, “here’s a 600 page slide deck on exactly how to replace your formal, buttoned-up waterfall process with this new, somehow-eerily-similar, buttoned-up Agile process.” After all, companies that have historically tended to favor waterfall approaches tend to view software development as a mashup of building construction and assembly line pipelining, so their failure could only, possibly be caused by a poorly engineered process. They needed the software equivalent of an industrial engineer (a process coach) to come in and show them where to place the various machines and mindless drones in their employ responsible for the software. Clearly, the problem was doing design documents instead of writing story cards and putting Fibonacci numbers on them.

The Software Craftsmanship movement, I believe, stands as evidence to support what I’m saying here. It removes the emphasis altogether from process and places it, in very opinionated fashion, on the characteristics of the actual software: “not only working software, but also well-crafted software.” (emphasis theirs) I can’t speak exactly to what drove the creation of this document, but I suspect it was at least partially driven by the obsession with process instead of with actually writing software.

MolotovCocktail

All of this leads me to wonder about something very idly. What if the Agile Manifesto, instead of talking about “uncovering better ways,” had spoken to the idea of “let’s create agile software?” In other words, forget about the process of doing this altogether, and let’s simply focus on the properties of the software… namely, that it’s agile. What if it had established a definition that agile software is software that should be able to be deployed within, say, a day? It’s software that anyone on the team can change without fear. It’s software that’s so readable that new team members can understand it almost immediately. And so on.

I think there’s a deep appeal to this concept. After all, one of the most annoying things to me and probably to a lot of you is having someone tell me how to solve a problem instead of what their problem is, when asking for help. And, really, software development methodologies/processes are perhaps the ultimate example of this. Do a requirements phase first, then a design phase, then an implementation phase, etc. Or, these days, write what the users want on story cards, have a grooming session with the product owner, convene the team for planning poker, etc. In both cases, what the person giving the direction is really saying is, “hey, I want you to produce software that caters to my needs,” but instead of saying that and specifying those needs, they’re telling you exactly how to operate. What if they just said, “it should be possible to issue changes to the software with the press of a button, it needs to be easy for new team members to come on board, I need to be able to have new features implemented without major architectural upheaval, etc?” In other words, what if they said, “I need agile software, and you figure out how to do that?”

I can’t possibly criticize the message that came out of that meeting of the minds and gave birth to the Agile Manifesto. These were people that bucked entrenched industry trends, gained traction, and pulled it off with incredible success. They changed how we conceive of software development and clearly for the better. And it’s entirely possible that any different phrasing would have made the message either too radical or too banal for widespread adoption. But I can’t help but wonder… what if the call had been for agile software rather than agile methods.

By

Avoiding the Perfect Design

One of the peculiar ironies that I’ve discovered by watching the way a lot of different software shops work is that the most intense moments of exuberance about software seem to occur in places where software development happens at glacial speeds. If you walk into an agile shop or a startup or some kind of dink-and-dunk place that bangs out little CRUD apps, you’ll hear things like, “hey, a user said she thought it’d be cool if she could search her order history by purchase type, so let’s throw that in and see how it goes.” If it goes insanely well, there may be celebrations and congratulations and even bonuses changing hands which, to be sure, makes people happy. But their happiness is Mercury next to the blazing Sun of an ivory tower architect describing what a system SHALL do.

“There will be an enterprise service bus. That almost goes without saying. The presentation tier and the business tier will be entirely independent of one another, and literally any sort of pluggable module that you dream up as a client can communicate with any sort of rules engine embedded within the business tier. Neither one will EVER know about the other’s existence. The presentation layer collaborators are like Schrodinger and the decision engines are like the cat!

And the clients. Oh yes, there will be clients. The main presentation tier client is a mobile staging environment that will be consumed by Android, iOS, Windows Phone, Blackberry, and even some modified Motorolla walkie-talkies. On top of the mobile staging environment will be a service adapter that makes it so that clients don’t need to worry about whether they’re using SOAP or REST or whatever comes next. All of those implementations will hide behind the interface. And that’s just the mobile space. There are more layers and subtleties in the browser and desktop spaces, since both of those types of clients may be SPAs, other thick clients, thin clients, or just leaf nodes.

Wait, wait, wait, I’m not finished. I haven’t even told you about the persistence factories yet and my method for getting around the CAP theorem. The performance will be sublime. We’re talking picoseconds. We’re going to be using dynamically generated linear programming algorithms to load balance the vertical requests among the tiers, and we’re going to take a page out of the quantum computing book to introduce a new kind of three state boolean… oh, sorry, you had a question?”

“Uh, yeah. Why? I mean, who is going to use this thing and what do they want with it?”

“Everyone. For everything. Forever.”

You back out slowly as the gleam in his eye turns slightly worrisome and he starts talking about the five year plan that involves this thing, let’s call it HAL, achieving sentience, bringing humankind to the cusp of the singularity, and uploading the consciousnesses of all network and enterprise architects.

Singularity

Like I said, the Sun to your Mercury. Has your puny startup ever passed the Turing Test? Well, his system has… as spec’ed out in a document management system with 8,430 pages of design documents and a Visio diagram that’s rumored to have similar effects to the Ark of the Covenant. And that, my friends, is why I think that a failing ATDD scenario should be the absolute first thing anyone who says, “I want to get into programming” learns to do.

Now to justify that whiplash-inducing segue. I wrote a book about unit testing in which I counseled complete initiates to automated testing to forgo TDD and settle for understanding the mechanics of automated tests and test runners first before making the leap. I stand by that advice, but I do so because I think that there is a subtle flaw to the way that most people currently get started down the programming path.

I was watching a Pluralsight course about NUnit to brush up on their latest and greatest assertion semantics, and the examples were really well done. In particular, there was a series of assertions oriented around a rudimentary concept of a role playing game with enumerations of weapons, randomization of events, and hit points. This theme exercised concepts like ranges, variance, collection cardinality, etc and it did so in a way that lent itself to an easy mental model. The approach was very much what mine would have been as well (I wouldn’t have come at this with TDD because there’d have been a lot of ‘downtime’ writing the production code as opposed to just showing the assert methods).

Nevertheless, it’s been a while since I’ve watched someone write tests against a pre-baked system when they weren’t characterization tests in a legacy rescue, and the experience was sort of jarring. I couldn’t help but think, “I wouldn’t want to write these tests if I were in his position — why bother when the code is already done?” Weird as it sounds from a big advocate of testing, writing tests after you’ve completed your implementation feels like a serious case of “going through the motions” in the same way that developers fill out random “SDLC” artifacts for no other purpose than to get PMPs to leave them alone.

And that’s where the connection to the singularity architect comes in. One of the really nice, but subtle perks of the TDD (especially ATDD) approach is that it forces you to define exit criteria before you start doing things. For instance, “I know I’ll be done with this development effort when my user can search her order history by purchase type.” Awesome — you’re well on your way because you’ve (presumably) agreed with stakeholders ahead of time when you can stop coding and declare victory. The next thing is to prove it, and you can approach this in the same way that you might approach fixing a leaking pipe under your sink. Turn the water on, observe the leak, turn the water off, fix the leak, turn the water back on, observe that there is no leak. Done.

In the case of the search, you write a client call to your web service that supplies a “purchase type” parameter and you say that you’re done when you get a known result set back, instead of the current error message: “I do not understand this ‘purchase type’ nonsense you’ve sent — 400 for you!” Then you scurry off to code, and you just keep going until that test that you’ve written turns green and all of the other ones stay green. There. Done, and you can prove it. Ship it.

Our poor architect never knows when he’s done (and we know he’ll never be done). The origin of this Sisyphean struggle started with hobby programming or a CS degree or something. It started with unbounded goals and the kinds of open-ended tasks that allow hobbyists to grow and students to excel. Alright, you’ve got the A, but try to play with it. See if you can make it faster. Try adding features to it. Extra credit! Sky’s the limit! At some point, a cultural norm emerges that says it’s more about the journey than the destination. And then you don’t rise through the ranks by automating for the sake of solving people’s problems but rather by building ever-more impressive juggernauts, leveraging the latest frameworks, instrumented with the most analytics, and optimized to run in O(Planck Time).

I really would like to see initiates to the industry learn to set achievable (but slightly uncomfortable) goals with a notion of value and then reach them. Set a beneficial goal, reach it, rinse, repeat. The goal could be “I want to learn Ruby and I’ll consider a utility that sorts picture files to be a good first step.” You’re adding to your skill set as a developer and you have an exit criteria It could be something for a personal project, a pro-bono client, or for pay. But tie it back to an outcome and assess whether that outcome is worthwhile. This approach will prevent you from shaving microseconds off of an app that runs overnight on a headless server and it will prevent you from introducing random complexity and dependency to an app because you wanted to learn SnazzyButPointless.js. True, the approach will stop you from ever delighting in design documents that promise the birth of true artificial intelligence, but it will also prevent you from experiencing the dejection when you realize it ain’t ever gonna happen.

By

ChessTDD 25: Yak-Shaving with a visit to trusty old ExtendedAssert

I started out with the intent of cleaning up a mistake in the new board setup functionality and moving on to more acceptance tests.  However, I got sidetracked a bit and wound up adding some functionality to my ExtendedAssert utility and briefly contemplating the interaction of some things in my object graph (once a week is better than I’d been doing, but 20 minutes per week isn’t a lot of time to keep it all fresh in my head).

Here’s what I accomplish in this clip:

  • Get at least a start at having tests around PiecePositioner
  • Fixed the issue where SetupStandardBoard was making both pawn rows white
  • Added functionality to my ExtendedAssert utility.
  • Added a way for consumers of the Board class to tell what size the board is after creating it.

Here are some lessons to take away:

  • I make a lot of dumb mistakes.  It’s TDD and the trusted test suite that helps me flounder for times on the order of seconds looking for them, rather than frustrated minutes or hours.
  • If you can avail yourself of NCrunch, I highly recommend it.  It’s incredibly handy to be able to visualize the path through the code that your unit test is driving.
  • A valuable part of TDD is stopping to reason about what your public methods will do when you feed them nonsense.
  • Duplication is icky anywhere you find it, including customized assert utilities.
  • Writing test infrastructure code (e.g. custom asserts) gets deeply weird in a hurry, since you have to either write unit tests for the unit test helping code or else flip the script and use your production code to ‘test’ what you’re doing in the test code.  I favor the latter approach.  Test and production code are like balancing your check book, so it seems reasonable to me to use either one as validation of the other.  YMMV.

Acknowledgements | Contact | About | Social Media