DaedTech

Stories about Software

By

The Secret to Fighting Buzzword Fatigue

A little while back, I made a post in which I mused about the work-retire dynamic as an unusual example of large batches in life. In the lead-in, I made passing reference to a post where I talked more specifically about buzzword fatigue. This is that post (with this explanatory paragraph pre-pended, of course).

It feels amazing, in an odd way, to give something a good name. You have to know what I mean. Have you ever sat around a whiteboard with a few people, tossing out names for some kind of module or concept or whatever, scrunching your nose and shaking your head slightly at each suggestion? “No, that’s almost right, but I don’t think that’s it.” And then finally, someone tosses out, “let’s call it the clobbering factory!” and all of your eyes go wide as someone else yells, “yes!!”

HighFive

Names are important. There’s a certain finality to naming something, even when you wish it weren’t the case. Have you ever failed in the quest for the perfect name, only to say something like, “aw, screw it, let’s just call it ‘circle’ since it’s a circle on the whiteboard, and we’ll rename it later?” If you have, you can’t tell me that the thing’s official name isn’t still “circle,” even 3 years and 23 production releases later. You probably even once tried to rename it, grousing at people that refused to start calling it “The Phoenix Module” in spite of your many, many, reminder emails. It stayed “circle” and you gave up.

There’s an element of importance to naming that goes beyond simple aesthetics, however, when you’re naming a concept. Products, bits of code and other tangible goodies have it easy because you can always point at what you’re talking about and keep meaning from drifting. With concepts… not so much. Next to their tangible cousins, they’re like unmoored boats in a river and they will drift.

And I think that the amount to which they drift is controlled by two main factors:

  1. Uniqueness
  2. Mappability to known concepts in context

Read More

By

Delegating is Not Just for Managers

I remember most the tiredness that would come and stick around through the next day. After late nights where the effort had been successful, the tiredness was kind of a companion that had accompanied me through battle. After late nights of futility, it was a taunting adversary that wouldn’t go away. But whatever came, there was always tiredness.

I have a personality quirk that probably explains whatever success I’ve enjoyed as well as my frequent tiredness. I am a relentless DIY-er and inveterate tinkerer. In my life I’ve figured out and become serviceable at things ranging from home improvement to cooking to technology. This relentless quest toward complete understanding back to first principles has given me a lot of knowledge, practice, and drive; staying up late re-assembling a garbage disposal when others might have called a handyman is the sort of behavior that’s helped me advance myself and my career. On a long timeline, I’ll figure the problem out, whatever it is, out of a stubborn refusal to be defeated and/or a desire to know and understand more.

Delegating

And so, throughout my career, I’ve labored on things long after I should have gone to bed. I’ve gotten 3 hours of sleep because I refused to go to bed before hacking some Linux driver to work with a wireless networking USB dongle that I had. I’ve stayed up late doing passion projects, tracking down bugs, and everything in between. And wheels, oh, how I’ve re-invented them. It’s not so much that I suffered from “Not Invented Here” syndrome, but that I wanted the practice, satisfaction, and knowledge that accompanied doing it myself. I did these things for the same reason that I learned to cook or fix things around the house: I could pay someone else, but why do that when I’m sure I could figure it out myself?

Read More

By

What I Learned from Learning about SpecFlow

In my ChessTDD series, I was confronted with the need to create some actual acceptance tests.  Historically, I’d generally done this by writing something like a console application that would exercise the system under test.  But I figured this series was about readers/viewers and me learning alongside one another on a TDD journey through a complicated domain, so why not add just another piece of learning to the mix.  I started watching a Pluralsight course about SpecFlow and flubbing my way through it in episodes of my series.

But as it turns out, I picked up SpecFlow quickly.  Like, really quickly.  As much as I’d like to think that this is because I’m some kind of genius, that’s not the explanation by a long shot.  What’s really going on is a lot more in line with the “Talent is Overrated” philosophy that the deck was stacked in my favor via tons and tons of deliberate practice.

SpecFlow is somewhat intuitive, but not remarkably so.  You create these text files, following a certain kind of format, and they’re easy to read.  And then somehow, through behind the scenes magic, they get tied to these actual code files, and not the “code behind” for the feature file that gets generated and is hard to read.  You tie them to the code files yourself in one of a few different ways.  SpecFlow in general relies a good bit on this magic, and anytime there’s magic involved, relatively inexperienced developers can be thrown easily for loops.  To remind myself of this fact, all I need to do is go back in time 8 years or so to when I was struggling to wrap my head around how Spring and an XML file in the Java world made it so that I never invoked constructors anywhere.  IoC containers were utter black magic to me; how does this thing get instantiated, anyway?!

BrandNewSetup

Read More

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

Lessons from the College Days

I have two degrees (Bachelor’s and Master’s) in computer science, so it’s probably no surprise that I place a fairly high degree of value on the background that all of this course work provided. That being said, my experience was that you learn some pretty unfortunate ‘lessons’ in CS degree programs. To name some that I learned (and later had to unlearn):

  • Writing readable code is for weaklings.  Writing your entire loop logic inside the loop guard condition FTW!
  • You get partial credit for non-running (or even non-compiling) code if you add a lot of vacuous comments.
  • All programming projects can be wrapped up in a month or, in extreme cases, a semester.
  • Source control is an important thing, theoretically, but it doesn’t solve any actual problem you have.
  • There are no consequences to making an enormous mess of your code in the hour before your deadline as long as it hits the predefined benchmarks because you’ll never look at it again in your life.
  • Performance and accuracy of results are all that matter.
  • Staying up for 36 hours straight to wheeze across the finish line is how heroes get it done.
  • All you need to deliver is a bunch of source code files that compile.

First of all, I’d like to point out that these aren’t things that a professor sat me down and said at any point and, in fact, if shown this list, they’d probably say, “those things aren’t good lessons.” But these were the lessons I learned by virtue of the incentives to which I was exposed and how I was rewarded or penalized for my actions. There’s a lot of room for improvement, but I’ll come back to that later.

The common theme that drives this list of less-than-awesome lessons learned is that the academic environment and the theory that it tends to teach lend themselves to non-representative situations, contrived for the purpose of teaching a specific lesson, such as how to implement Alpha-Beta pruning or how state machines work. The best ways to drive these points of instruction home don’t correspond with workaday dev concerns like “write me a web service that triggers a database update and keep it relevant when I change my mind every month or so.”

But one lesson that I did take away that has served me very well is, “do what’s necessary to get a D instead of an F, save that off for reference, and once that’s secured, go for the C, save, etc.” In a lot of classes, we’d submit coding assignments that would run against some kind of benchmark, and it was something like, “if you satisfy 60 of the 100 conditions you get a D, 70 of 100 and you get a C, etc.” And I learned that you mitigated a lot of risk by making it your top priority not to fail or get a 0, and then improving from there. This way, if the time ran out, you’d be less like an action hero trying to defuse a bomb before the timer goes off and more like a fussy dog show entrant trying to put a few last minute touches on your dog that would improve its chances of being judged better than the other dogs, whatever that entails.

DogShow

This early lesson to which I was first exposed as an undergrad, around the time the Agile Manifesto was being written, was really the precursor to concepts like iterative development and thin-sliced, end-to-end goals for software. It taught me, through real, meaningful incentives, to make sure that I secured at least some value before chasing unicorns like an A+ off into the sunset. If there were 2 minutes left to submit the assignment, I wanted the backup plan to be an A- rather than a zero.

So what does any of this matter to you grizzled software veterans a decade or however long into your careers? Well, bear in mind that there’s always an A- (or B or C or whatever) out there when a bunch of work gets thrown your way. That web service you’re tasked with writing isn’t all or nothing. Not even a phone app that shows you the time is all or nothing (if push comes to shove, and app that tells you whether it’s AM or PM is better than nothing). Things can always be pared down and scope can always be adjusted, assuming you design towards modularity.

The overriding message of this post is that you should always, always, always look at the beginning for ways that you can secure yourself intermediate grades between 0 and A+ on the way to calling your software done; it’s the only reasonable way that you can manage expectations and adjust on the fly with a software project, apart from getting your customer to agree to indefinite delays. But, for a bit of fun, I’ll leave you with a series of ideas for how college CS curricula might better prepare students for actual development gigs. These might make you laugh to think about, but they’re actually things that could add some value:

  • One assignment in every programming class starts you off not from scratch or from professor-written template code, but from whatever pile of mess some students turned in last semester (teaches you what an unkindness it is to make a mess in code)
  • Every assignment requires students to update a single, shared text file whenever they’re testing against the benchmark and they get dinged if it gets out of sync (teaching about file contention and merge conflicts)
  • There are one or more assignments during the course of the curriculum that simply cannot be totally completed (teaches students to prioritize while working against unrealistic parameters)
  • There is some code that you carry over semester to semester and thus have to live with for years and/or there is a class where each assignment builds on the code of the last one but requires refactoring (teaches writing code with the idea of maintaining it)
  • Lock kids out of the computer lab between 1 and 6 AM.  (Teaches you that you’re going to work at places where juvenile heroics simply aren’t feasible for reasons ranging from the fact that this is a bad idea to the fact that the facility may be locked down at night)
  • All homework/project submissions are real-world deliverables along the lines of an actual phone app, web app or MSI installer (teaches that there’s more to delivering software than writing code)