DaedTech

Stories about Software

By

The Polyglot’s Dilemma

Few things seem as institutional to the programming world as what I call the experience tuple.  A company needs to hire someone to automate something, so, naturally, it asks the software development group to make alphabet soup for dice.com.  “We need someone with (C#, XML, HTML, JS, ASP, MVC, REST, Angular, AJAX) with (React, MSTest, Moq, CSS) as plus.”  Presumably then, polyglot applicants stand a better chance.  But I’d argue that they also face something I’ll call the polyglot’s dilemma.

Hold on to your hats, programmers, because this will get counter-intuitive before it makes sense.  With that in mind… where to start?

Problem Solvers and Problem Transformers

Well, perhaps categorizing hired software developers as problems makes for a good start.  I don’t mean problems in a negative sense, but rather in the same vein as puzzles.  A business hires software developers for some broader purpose.  Maybe they work on internal automation that reduces operating expenses.  Or perhaps they produce software sold as a good or service and add to top line revenue.

In either case, the business implicitly says “I need help increasing our profitability.”  And you show up saying the following.

I have (8, 10, 10, 4, 6, 3, 1, 1, 0) years of (C#, XML, HTML, JS, ASP, MVC, REST, Angular, AJAX).  Now while the rest of you figure out how to make use of me, I’ll be over here sharpening the saw with some code katas.

Whenever I’ve had management responsibility, I’ve subconsciously put people into two buckets.  Problem solvers take a problem I have and make it go away.  Problem transformers take a problem I have and solve it by bringing me the next problem.  (I’m omitting non-performers who don’t solve problems at all as beyond the scope of this post.)

For instance, take the problem of a malfunctioning production server.  A problem solver would go off and come back with a functioning production server, somehow.  A problem transformer would come back, report that the problem was caused by a faulty power supply and ask what I wanted to do about that new problem.

As programmers, we behave as problem transformers.  We present ourselves and our skill sets as problems in need of management solutions.

Read More

By

The Business-Personal Value Continuum

While out on a jog recently, I found myself listening to an episode of .NET Rocks, in which the discussion covered the surprising percentage of developers still using Winforms and the general topic of using licensed controls written by third parties.  This started a train of thought in my head that might end in mild controversy, but I think it’s worth exploring a bit.

Two profiles (well, more like caricatures) of developer came to mind, standing in stark contrast to one another.  First is this Winforms developer that is more or less cobbling together spare parts to build applications. He uses a WYSIWYG editor, employs some kind of “database form wizard” to bind a GUI widget directly to a table, plops a slew of obscure third party controls into the code, and ships some kind of Franken-app not actually involving much code.  The second profile rounds out the dichotomy and consists of the foundational crafter.  This person builds her own tools and controls using low level language constructs and the command line, and assembles these works of art into ever-higher layers of abstraction until shipping a hand-crafted app.

If I’m running a business, give me the first person.

Undoubtedly, the crafter harbors a better, more fundamental grasp of the principles of computer science, and she undoubtedly offers the most versatility.  If she can build a compiler, use that to build a text editor, use that to build a source control system, use that to build a web server, and use that to build the sexiest, popping-ist, UX-friendliest website you’ve ever seen, she is the most employable, most full stackable programmer ever.  The business will never encounter a situation beyond her grasp.  But who cares, if the business just needs a checkbox added to a battleship gray, outdated Windows application?

Female Artist

I practice test driven development.  I rail against the evils of copy and paste programming.  I counsel clients on the dangers of technical debt and feature slow down.  I advocate wholesale for clean code.  And because of all these things, I understand that every single line of code you write is an incremental business liability.  So why would I take the cobbler over the crafter?  Don’t get me wrong — if I had to pick one of the two of them to write a given module, I would take the crafter.  But for approach, I would take the cobbler because the cobbler makes most of the code someone else’s problem while the crafter makes it all my problem.

What I really want is someone with the chops of a crafter and the reluctance to write more code than necessary of a cobbler.

Read More

By

How to De-Brilliant Your Code

Three weeks, three reader questions.  I daresay that I’m on a roll.  This week’s question asks about what I’ll refer to as “how to de-brilliant your code.”  It was a response to this post, in which I offered the idea of a distinction between maintainable code and common code.  The lead-in premise was that of supposedly “brilliant” code, which was code that was written by an ostensible genius and that no one but said genius could understand.  (My argument was/is that this is usually just bad code written by a self-important expert beginner).

The question is, as follows, verbatim.

In your opinion, what is the best approach to identify que “brilliant” ones with hard code, to later work on turn brilliant to common?

Would be code review the best? Pair programming (seniors could felt challenged…)?

Now, please forgive me if I get this wrong, but because of the use of “que” where an English speaker might say “which”, I’m going to infer that the question submitter speaks Spanish as a first language.  I believe the question is asking after the best way to identify and remediate pockets of ‘brilliant’ code.  But, because of the ambiguity of “ones” it could also be asking about identifying humans that tend to write ‘brilliant’.  Because of this, I’ll just go ahead and address both.

Einstein Thinking Public Static Void

Find the Brilliant Code

First up is identifying brilliant code, which shouldn’t be terribly hard.  You could gather a quorum of your team together and see if there are pockets of code that no one really understands, or else you could remove the anchoring bias of being in a group by having everyone assess the code independently.  In either case, a bunch of “uh, I don’t get it” probably indicates ‘brilliant’ code.  The group aspect of this also serves (probably) to prevent against an individual not understanding simply by virtue of being too much of a language novice (“what’s that ++ after the i variable,” for instance, indicates the problem is with the beholder rather than the original developer).

But, even better, ask people to take turns explaining what methods do.  If people flounder or if they disagree, then they obviously don’t get it, self-reporting notwithstanding.  And having team members not understanding pockets of code is an ipso facto problem.

An interesting side note at this point is whether this illegible code is “brilliant” or “utter spaghetti” is going to depend a lot more on knowledge of who wrote it than anything else.  “Oh, Alice wrote that — it’s probably just too sophisticated for our dull brains.  Oh, wait, you were reading the wrong commit, and it’s actually Bob’s code?  Bob’s an idiot — that’s just bad code.”

De-Brilliant The Codebase

Having identified the target code for de-brillianting, flag it somewhere for refactoring: Jira, TFS, that spreadsheet your team uses, whatever.  Just make a note and queue it as work — don’t just dive in and start mucking around in production code, unless that’s a team norm and you have heavy test coverage.  Absent these things, you’re creating risk without buy in.

Leave these things in the backlog for prioritization on the “eventually” pile, but with one caveat.  If you need to be touching that code for some other reason, employ the boy-scout rule and de-brilliant it, as long as you’re already in there.  First, though, put some characterization tests around it, so that you have a chance to know if you’re breaking anything.  Then, do what you need to and make the code easy to read; when you’re done, the same, “tell me what this does” should be easy to answer for your teammates.

De-brillianting the codebase is something that you’ll have to chip away at over the course of time.

De-Brilliant The Humans

I would include a blurb on how to find the humans, but that should be pretty straightforward — find the brilliant code and look at the commit history.  You might even be able to tell simply from behavior.  People that talk about using 4 design patterns on a feature or cramming 12 statements into a loop condition are prime candidates.

The trick isn’t in finding these folks, but in convincing them to stop it.  And that is both simple to understand and hard to do.

During my undergrad CS major many years ago, I took an intro course in C++.  At one point, we had to do a series of pretty mundane, review exercises that would be graded automatically by a program (easy things like “write a for loop”).  Not exactly the stuff dreams are made of, so some people got creative.  One kid removed literally every piece of white space from his program, and another made some kind of art with indentations.  When people are bored, they seek clever things to do, and the result is ‘brilliant’ code.

The key to de-brillianting thus lies in presenting them with the right challenge, often via constraints or restrictions of some kind.  They do it to themselves otherwise — “I’ll write this feature without using the if keyword anywhere!”

The Right Motivation

Like I said, a simple solution does not necessarily imply an easy solution.  How does one challenge others into writing the kind of straightforward code that is readable and maintainable?

Code review/pairing presents a possible solution.  Given the earlier, “can others articulate what this does” metric, the team can challenge programmer-Einstein to channel that towering intellect toward this purpose.  That may work for some, but other brilliant programmers might not consider that to be a worthwhile or interesting challenge.

In that case, automated feedback through static analysis might do the trick.  FXCop, NDepend, SonarQube, and others can be installed and configured to steer things in the general direction of readability.  Writing code that complies with all warning thresholds of such tools actually presents quite a challenge, since so much of programming is about trade-offs.  Now, a sufficiently determined clever coder could still invent ways to write hard-to-read code, but that would be a much more difficult task when he’d get slapped by the tool for chaining 20 Linq statements onto a single line or whatever.

Of course, probably the best solution is to work with the sort of people who recognize that demonstrating their cleverness takes a backseat to being a professional.  They can do that in their spare time.

If you have a question you’d like to hear my opinion on, please feel free to submit.

By

Surviving The Dreaded Company Framework

This week, I’m making it two in a row with a reader question.  Today’s question is about an internal company framework and how to survive it.  Well, it’s actually about how to work effectively with it, but the options there are sort of limited to “get in there and fix it yourself” and “other” when the first option is not valid (which it often is not).

How does one work effectively with a medium to large sized company-internal framework? The framework has one or two killer features, but overall is poorly abstracted and [released] with little QA.

I think the best way for me to tackle this question is first to complain a little about Comcast, my erstwhile cable company, and then come around to the point.  They recently explained, in response to one of my occasional Comcast rage-tweets, “[The] promotional pricing is intended to offer you the services at a reduced rate, in the hopes that you enjoy them enough to keep them.”

This is, in a nutshell, the Comcast business model — it was an honest, and forthright tweet (unlike the nature of the business model itself).  What Comcast does is reminiscent of what grocery stores do when they flood the local shopping magazines with coupons: differential pricing.  Differential pricing is a tactic where in you charge different rates for the same product to different customers, generally on the basis of charging more when people are non-price averse.

The trouble is that outright differential pricing is usually illegal, so companies have to get creative.  With the grocery store, you can pay full price if you’re generally too busy for coupons, but if you load up with serious couponing, you can get that same grocery trip for half the price or less.  They can’t say, “you look rich so that’ll be $10.00 instead of $5.00” but they can make the thing $10.00 and serially discount it to $5.00 for people willing to jump through hoops.

Comcast does this same thing, but in a sneakier way.  They advertise “promotions” and “bundles” to such an extent that these appear to be the normal prices for things, which encourages people to sign up.  Then, after some time you’ll never keep track of and never be reminded of, the “regular” price kicks in.  For me, recently, this turned out to be the comical price of $139 per month for 24 Mbps of internet.

scan0002

When you call them to ask why your most recent bill was for $10,928 instead of $59.99, they’ll say “oh noes, too bad, it looks like your bundle expired!”  And this is where things take a turn for the farcical.  You can ask them for another bundle, and they’ll offer to knock your monthly bill down to $10,925.  If you want to secure the real savings, you have to pretend for a while to be canceling your service, get transferred over to the “retentions department,” and then and only then will you be offered to have your service returned to a price that isn’t absolutely insane.  I suspect that Comcast makes a lot of hey on the month or two that you get billed before you call up and do that again, because the ‘normal’ prices are equal parts prohibitive and laughable.

Why am I mentioning all this?  Well, it’s because when the time came for my most recent annual Comcast gouge ‘n’ threaten, things got a little philosophical.  I wound up on the phone with an agent to whom I confessed I was sick of this stupid charade.  Instead of arguing with me, he said something along the lines of, “yeah, it’s pretty ridiculous.  Before I started working here, I used to hate calling up and threatening them every year, but the thing is, all of the other companies do it too.”  This was either a guy being refreshingly honest, or a really shrewd customer service tactic or, perhaps, both.

But the interesting message came through loud and clear.  In my area, if you want TV and internet, it’s Comcast or it’s AT&T.  And if both of them behave this way, it goes to show you the power of a monopoly (or a nominally competing cartel).  Their motto is, in essence, “Comcast: it’s not like you have a choice.”

Read More

By

Three Martini Open Office Plans

A tweet came into my Twitter feed last night, and I noted that (1) I was a little late to the party and (2) it was wildly popular.  I found myself a bit surprised, because it was critical of the open plan office construct, which I figured was by now just an accepted condition of salaried employment, like status meetings or PTO limits.  Apparently, however, this is one particular management fad that has not met with universal approval.  The tweet (shown below), is trending toward 10K likes and retweets.

Personally, I love open plan offices.  Granted, I don’t actually work in one with any regularity, but I enjoy them immensely when I have occasion to park for a few hours at a client site.  It’s sort of like going to the gym, but without the sweating.  Actually, I’d say, it’s more like going to a bar (more on that later).

Three Martini Lunchers

I’m a type A introvert, and I work predominantly from home (or a hotel wherever I happen to be, since I travel a lot).  This means that it’s not uncommon for me to get swept up in my work and log 10+ hour stints of heavy concentration.  For instance, I recently wrote an E-Book for a client in 2 days.  It’s like I go into a sensory deprivation chamber and I get things done, delivering code, write-ups, posts, or whatever to clients on or ahead of schedule.

But following a productivity ‘binge’ like that, there are typically human connection things that have to happen.  I travel to a client site to present something in person or I get on a series of conference calls to collaborate.  It is in these situations that hyper-productivity ends and human connection begins in the meatspace.  Consulting requires more than just output — it requires relationship management.

More and more these days, when I pull that part of a tour of duty, it happens in an open plan office, simply because there are more and more open office plans.  Even clients that don’t have them now talk sheepishly about how they should.  For me, fresh off a week or two of minimal human interaction and intense productivity, I fly somewhere and meet with people for a couple of days, wherein the goal is mainly relationship forging.  In this capacity I’m greeted by someone who proudly demonstrates the egalitarian nature of the office space, and ushers me to a high top or to a focus room or whatever they’re calling it.

At this point, it’s as if I were in a college Starbucks that served a single company.  Some patrons are sitting alone, studying glowing screens, while others gather in impromptu circles, having animated discussions.  There’s the occasional jerk making lots of noise and distracting everyone and the occasional good-natured hijinks in the form or Nerf guns or whatever.  The result is a Dionysian experience to my Appolonian, introverted sensibilities.  I wouldn’t want to try to get serious, thought-intensive work done in such a place (if I needed to do that, I’d obviously leave), but it’s a nice way to obtain social camaraderie without much pressure.

Read More