DaedTech

Stories about Software

By

Taking the Guild Metaphor Too Far

Today, I’d like to talk about the pervasiveness of the craft guild metaphor in today’s software development landscape.  Specifically, I want to talk about how I think we’ve jumped the shark with this and how it now harms more than helps.  I recognize that I’m probably going to inspire some ire and get myself in trouble here, but please hear me out a bit.

First of all, some words of caveat.  I don’t say this from a place of any hostility or really even criticism.  In other words, I don’t take the position, “you’re all making a mistake with this and being silly.”  Rather, the more I wrote in Developer Hegemony, the more the guild metaphor came to feel wrong to me.  But only during the course of the last few days did I figure out how to articulate why.  So now, I post from the perspective of, “I think we recently took a slight wrong turn and that we should stop to reconnoiter a bit.”

Before I get to building my case, I want to spend some time applauding the guild metaphor for what I believe it has provided us.  I believe it important that I do so because it clarifies my position.  You can’t make a “wrong turn” without having started on the right track.

Also note that I don’t believe anyone has stated what I’m about to say as the reasoning for the metaphor.  What you will read next comes from inferences I have made.

Prequel to the Guild Metaphor: Drilling Holes in Sheet Metal

Corporate software development, by and large, got its start helping organizations capitalize on efficiency opportunities.  Some VP of something, looking at a typed spreadsheet, would say “if we could speed this process up by 25%, we could hit our third quarter numbers!  Poindexter, come in here and do that thing you do with the computer and make it so!”

Poindexter would then leave and come back a few days later.  “I flipped the bits and bypassed the mainframe and transmogrified the capacitor and –“

“In English, Poindexter!”

“Oh, right, sorry Mr. Rearden.  I was able to do a 30% speedup.”

“Good work, Poindexter!”

In this world, you had business people who would create strategy and delegate cost savings to geeks in bite sized morsels.  The geeks would diligently execute their tasks.

Because of this historical and ubiquitous communication deficit, the business people misunderstood the nature of geek work.  Their mental model of software development paralleled it to building construction and manufacturing.  The geeks occupied the role of line level laborers in their particular domain.  And so decades of horribly mismanaged software projects ensued.

“Come on, Poindexter, I need your codes for the next speedup by Friday or we won’t make our numbers!”

“But, Mr. Rearden, you don’t understand – it’s not that simple!  We can’t just – “

“Look, Poindexter, it’s not rocket science.  Just code faster and copy and paste the thing you did last time.  Think of yourself as a guy who drills holes in sheet metal, Poindexter.  Get a stronger drill bit, and lay the last sheet over the new one, using it as a template.  Do I have to think of everything?!”

“But, Mr. Rearden, it doesn’t work that – “

“Shut up Poindexter, or I’ll find a cheaper, offshore Poindexter!”

Read More

By

Logging for Fun: Things You’d Never Thought to Log

Editorial Note: I originally wrote this post for the LogEntries blog.

I work as a consultant in the software industry.  This work affords me the opportunity to see and interact with many different teams and thus to observe prevailing trends.  Among these teams, the attitude toward logging tends to be one of resigned diligence.

That is, many developers view application logging the way they view flossing their teeth: a necessary, dull maintenance activity that will pay dividends later.  Today, however, I’d like to encourage readers to consider a different side of logging.  In the right context and with the right intent, the activity can do so much more than simply insulate against audits and facilitate troubleshooting.  Logging can, in a sense, offer similar appeal to journaling or generally recording information for posterity.

Logging loosely consists of two components: recording and storing information.  As application developers, we find our thoughts occupied by the recording and how that affects our code.  We consider the storage and retrieval only inasmuch as it later aids our debugging efforts.  But we can expand the storage to include sophisticated aggregation, filtering, and querying techniques.  And in these techniques, we can find new ways to understand subjects that interest us.

To be a bit more concrete, I’m going to offer some examples in this post of worlds that you can open through logging.  But the examples will require you to view logging not as dumping data to some file, but as recording information in a way that you can mine it for meaning.  Obviously not all of us share the same interests.  But these examples may give you ideas for your own interests, even if they do not all appeal to you directly.

Read More

By

Comments in Clean Code? Think Documentation

Editorial Note: I originally wrote this post for the SubMain blog.  You can check out the original here, at their site.  While you’re there, take a look at GhostDoc for your documentation needs.

Second Editorial Note: I recently appeared on the Ruby Rogues podcast and was interviewed by Paysa.  If you’re interested, check both of them out!

Notwithstanding some oddball calculator and hobby PC hacking, my first serious programming experience came in college.  A course called “Intro to C++” got us acquainted with arrays, loops, data structures and the like.  Given its introductory nature, this class did not pose a particularly serious challenge (that would come later).  So, with all of the maturity generally possessed by 18 year olds, we had a bit of fun.

I recall contests to see how much application logic we could jam into the loop conditions, and contests to see how much code could be packed onto one line.  These sorts of scavenger hunt activities obviously produced dense, illegible code.  But then, that was kind of the point.

Beyond these silly hijinks, however, a culture of code illegibility permeated this (and, I would learn later) other campuses.  Professors nominally encouraged code readability.  After all, such comments facilitated partial credit in the event of a half-baked homework submission.  But, even still, the mystique of the ingenious but inscrutable algorithm pervaded the culture both for students and faculty.  I had occasion to see code written by various professors, and I noticed no comments that I can recall.

Professionalism via Thoroughness

When I graduated from college, I carried this culture with me.  But not for long.  I took a job where I spent most of my days working on driver and kernel module programming.  There, I noticed that the grizzled veterans to whom I looked up meticulously documented their code.  Above each function sat a neat, orderly comment containing information about its purpose, parameters, return values, and modification history.

This, I realized, was how professionals conducted themselves.  I was hooked.  Fresh out of college, and looking to impress the world, I sought to distinguish myself from my undisciplined student ways.  This decision ushered in a period of many years in which I documented my code with near religious fervor.

My habit included, obviously, the method headers that I emulated.  But on top of that, I added class headers and regularly peppered my code with line comments that offered such wisdom as “increment the loop counter until the end of the array.”  (Okay, probably not that bad, but you get the idea).  I also wrote lengthy readme documents for posterity and maintenance programmers alike.  My professionalism knew no bounds.

Read More

By

Reputation Suicide, and Why I’m Quitting Disqus

I’m going to be switching comment engines soon.  Right now, I use disqus, but I received the email below from them recently.  The email served as the last straw for me with disqus.

This, in and of itself, might not seem overly objectionable.  Sure, it insults the intelligence of anyone reading, but that’s hardly unique.  So let me take you on a brief journey to demonstrate why I find them signing their emails “Disqus Publisher Success” to be a big, fat, middle finger of irony.

Disqus: Comments in Exchange for Disqusting Ads

Years ago, I grew tired of fighting the good fight against comment spam.  I installed a handful of WordPress plugins that aimed to curtail the spam, but as my popularity with readers grew, so too did my popularity with people peddling mail order brides.  I can recall the endless annoyance I felt at waking up to see that someone had sneaked past the spam filters to pepper my comment section at 3:46 AM.

And then I found Disqus.  I recall hesitating at first because it replaced the standard comment section instead of just working with it.  But, at wits end, I signed on anyway.  And I felt happy because it pretty much solved my spam problem.  It also added some cool features around promoting my blog in other places, and authenticating commenters.  Awesome!

I also saw that I could make a bit of money with ads if I so chose.  At the time, I had no interest in monetizing my blog and I didn’t care for the ads, so I passed.  As you can see if you look to the right, I have no qualms about ads.  I’d just want them relevant to my readers and tasteful.

So imagine my surprise a few years later, when I learned that disqus had, at some point unknown to me, turned them back on as part of some update.  My readers at the time found themselves treated to things like this.

Read More

By

Some Visual Studio Tips and Tricks

Editorial Note: I originally wrote this post for the SmartBear blog.  

Last month, I wrote a post about integrated development environments (IDEs).  As mentioned in that post, developers commonly debate the relative merits of lightweight text editors against heavyweight IDEs.  But I suspect just about everyone can agree that if you do plan to use an IDE, you should maximize its utility.  In other words, as long as you’re incurring the overhead, you should reap the benefits.

I work a great deal in the .NET space, which means that I spend a good bit of time using Visual Studio, an extremely heavyweight IDE.  In the interests of full disclosure, I will admit to loving to work with Visual Studio.  But that love has grown out of years of exploring it, tinkering with it, and learning to maximize my efficiency with it.  If not for all that, it would seem only a glorified text editor that takes a lot longer than Notepad++ or Sublime to start.

Today, I’d like to offer some suggestions for getting more mileage out of Visual Studio.  By no means is this an exhaustive list; that would require books and books, rather than a single blog post.  Visual Studio has tons of capability.  Rather, today, I’ll offer some tips and tricks you might not have seen previously.

Read More