DaedTech

Stories about Software

Apr
11

By

Striking the Standards Balance: Scale Up without the Bureaucracy

Category: The Life of a Programmer Tags: , | 4 Comments

Editorial Note: I originally wrote this post for the Telerik blog.  You can check out the original here, at their site.  While you’re there, have a look around at their extensive product offering.

In a whitepaper I wrote recently, I talked about two hypothetical organizations.  I used them to offer a study in hyperbolic contrast.

The first had a team of five developers, none of whom used the same development practices. In fact, one of them used a completely different programming language.  They tracked defects using email, and they operated less as a group and more as a collection of ships passing in the night.  If a customer issue arose in the code of a person on vacation, well, then that customer just had to wait.

On the other side of the aisle sat a massive enterprise.  Here, the team not only used the same programming language, but the same everything.  The organization restricted access to the machines so that developers couldn’t install anything of their choosing.  Instead of leaving things to chance, an architectural center of excellence controlled design decisions.  And any deviation from any practice required forms in triplicate.

I used this hyperbole to draw contrast between teams that could benefit from standardization and teams crippled by it.  Predictably, scale plays an important role in the distinction.  To scale an enterprise, one must standardize some operational concerns.  But in doing so, it risks choking the life out of individual innovation.

How can you standardize while minimizing bureaucracy?  Today, I’d like to offer some tips for striking the balance.

Read More

Apr
9

By

Always Be Leaving

Category: Free Agent Developers Tags: , | 7 Comments

Last Friday, I published a post called “The Polyglot’s Dilemma”.  I had actually had a stubbed draft for this post, “Always Be Leaving,” before writing that one.  But it turns out that post segues nicely into this one.

Programmers (especially polyglots) face a dilemma wherein the thing that makes them most employable (broad generalist skills) also positions them as resources rather than strategic experts.  To make matters worse, broad industry generalizing also puts programming labor in the category of fungible commodity.  Knowing many languages and techs makes it easy for a company to assign you to any arbitrary upcoming automation project.  But it also makes you easily replaceable by any similar generalist.

The polyglot generalist comes to the company as an easily-deployed generalist.  He then waits for people tasked with organizational strategy to deploy him.  But then, of course he does.  This represents the only way for him to remain indefinitely engaged as an employee.  A specialist comes in to execute on a limited duration charter.  A generalist signs on to do whatever the company happens to need for the rest of his career (theoretically).  This context demands a generalist, since nobody knows what the company will need in 5, 10, or 20 years.

And so we see that the polyglot’s dilemma arises naturally from indefinite employment.

Leverage: A Study in Contrasts

“Always be leaving,” as a title probably reminds you of the pop culture sales phrase, “always be closing.”  Popularized by movies like Glengary Glenn Ross and Boiler Room, it evokes images of the iconic pushy sales guy.  This sales guy does things like cold call you and say, “should I sign you up for two or just one?”  See what he did there?  He gave you no option to say no.  Slick man that he is, he’s always closing.

If you take the self-important testosterone out of the situation, you can see a more basic psychological reality.  “Always be closing” applies to situations with little to no leverage.  Fast-talking sales guys call up “whales” and, through force of personality, convinces them to buy stocks they don’t need.  He has no actual leverage — nothing they really want — so he exerts his dominance by turning on the forceful charm and bamboozling them.  Then he high fives his buddies afterward and rings a bell and screams or some such idiocy.  He creates leverage theater in order to secure the metaphorical kill.

“Always be leaving,” on the other hand, offers a complete leverage reversal.  When you find yourself ending an engagement or an employment tenure, you have tons of leverage.  But you usually forgo using it.  You give your notice, and the notified party often asks what it can do to keep you, even though you feel excited looking ahead to the next thing.

Read More

Apr
7

By

The Polyglot’s Dilemma

Category: The Life of a Programmer Tags: , , | 11 Comments

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

Apr
4

By

The Relationship between Static Analysis and Continuous Testing

Category: Language Agnostic Tags: , , |

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, download NDepend and give it a try.

As an adult, I have learned that I have an introvert type personality.  I do alright socially, don’t mind public speaking, and do not (I don’t think) present as an awkward person.  So, learning about this characterization surprised me somewhat, but only until I fully understood.

I won’t delve into the finer points of human psychology here, but suffice it to say that introverts prefer to process and grok questions before responding.  This describes me to a tee.  However, working as a consultant and giving frequent advice clashes with this and has forced me to develop somewhat of a knack for answering extemporaneously.  Still, you might ask me just the right question to cause me to cock my head, blink at you, and frown.

I received just such a question the other day.  The question, more or less, was, “if we have continuous testing, do we really need static analysis?”  And, just like that, I was stumped.  This didn’t square, and I wanted time to think on that.  Luckily, I’ve had a bit of time.  (This is why I love blogging.)

Continuous Testing, Defined

Before we go into the relationship between the concepts, let’s first clarify them.  That way we’ll have no inadvertent misunderstandings via buzz word.

My first introduction to continuous testing was through a tool called NCrunch.  It bills itself as an “automated concurrent testing tool,” which certainly offers more precision than “continuous testing.”  NCrunch is awesome.  If you practice TDD or have unit tests, give it a look.  It runs your tests continuously as you write code, providing you real-time, in-IDE, visual feedback as you make changes.  Accidentally delete a line and watch the side of your editor window go immediately red.

In the interceding years, I have seen a broadening of this term to be a follower for concepts such as continuous integration (CI) and continuous deployment (CD).  In agile environments, we integrate constantly and, ideally, deploy (somewhere) constantly.  Why give testing short shrift?  With continuous testing, your environments constantly pepper your build candidates with runtime tests, providing early feedback instead of near the end of the sprint.

So we have two concepts that we can generalize.  The first concept involves tightening the unit test feedback loop, while the second involves the same for integration and acceptance tests.  In both cases, we consistently test our code’s runtime behavior with a fast-feedback loop.

Read More

Apr
2

By

Reader Question Round-Up

Category: You Asked For It |

I’ve just returned from a vacation.  So, after a week of R&R, I’m going to write a post instead of cross posting one.  And I thought that getting back to reader questions after a hiatus might make for a good “welcome back” post.

I mercifully do not struggle with writer’s block.  As someone who gets paid to produce content for a number of outfits, writer’s block would present a deal-breaking problem.  I do, however, struggle with answering some reader questions at times.  Recently, it occurred to me why this might be the case.

Simply put, not all reader questions necessarily require a 1,000+ word post to answer.  Thus, I don’t struggle with writer’s block, but rather with “how do I expand this into a proper post?”  As I sunned myself in tropical climes this past week, it struck me.  Maybe I don’t.

As such, I’m introducing something that I’ll call “reader question round-up.”  In this new style of post, I’ll answer a series of questions — ones that I think I need fewer words than a full post to answer.  Hopefully, this keeps me from rambling and starts to clear out my rather sizable queue of backlogged reader questions.

Reader Question Round-Up

So, here goes.

Read More

« Older Posts
Newer Posts »