philosophy


31
Mar 10

micro-optimization

nero fiddling as rome burns

Yea, I know it's on fire, but check it, I almost got Freebird down pat.

As all good developers should know, one of the cardinal sins of software development is premature optimization. Premature optimization is bad for a whole host of reasons. But there is another set of optimizations that are in the same realm of bad, micro-optimizations.

I recall learning at some point that in C and C++ it is more efficient to use the pre-increment operator rather than the post-increment operator. Why is this the case, well it’s because of the minor difference in behavior between the following two snippets.

  int source = 10;
  int destination = 0;

  destination = ++source;

  printf("Destination: %d", destination);  //Prints "Destination: 11"

Compare with this snippet

  int source = 10;
  int destination = 0;

  destination = source++;

  printf("Destination: %d", destination); //Prints "Destination: 10"

WHA!? This is actually exactly what we would expect, pre-increment increments the value BEFORE assignment while post-increment increments the value AFTER assignment. What does this all mean, well basically that if you use post-increment you are executing more instructions, because the compiler has to keep the old value around to return to the assignment. That means that unless you are assigning the value and require the particular behavior that post-increment gives you, you can generate faster code by using the pre-increment operator (this may be handled by compiler optimizations these days).

All of the for-loops that you’ve written for(int i = 0; i < something; i++) are identical to and SLOWER than for(int i = 0; i < something; ++i). NOOOOO!!!!! Don't worry though, because this is a micro-optimization, its something to not care about, because in reality that one or two extra machine instructions isn't your bottleneck. Micro-optimizations are all those tricks that make code faster that in the vast majority of cases (although not all cases) don't really amount to any actual noticeable performance gain. A new processor can do something in the magnitude of 100,000 MIPS (Millions of Instructions Per Second). Every second it does 100,000,000,000 Instructions, that is 100 billion instructions. every. single. second. Changing from post- to pre- increment saves 1 or 2 instructions, so for every time that gets executed you have saved a 100th of a nanosecond.

Micro-optimizations are rarely worth the hassle, and, as with premature optimization, the solution is to benchmark and trace where your actual bottlenecks are and go about solving those. It doesn't matter if you're screaming through your increments saving a whole nanosecond if your crappy no index having table is taking a whole minute to read because you are doing a table-scan.

But wait, there's more. Micro-optimization, like everything in programming, can be directly applied to life in general. I work with a person who will spend 5 minutes discussing how to save 30 seconds, this is another incarnation of the micro-optimization. It's that shortcut you take home that actually takes longer, or some everyday voodoo that is draining your time without paying you back, or that client that provides you with 2% of your income but eats up 40% of your effort. Micro-optimizations abound all around us, in the little picture they seem ok, but in the big picture they are nonsense. Take a fresh look at the things and obligations around you and examine them for micro-optimizations, see if the things you do make sense in the big picture.


8
Feb 10

experience as a force multiplier

cat saying "I weveled up yur guys"

Oh DS cat you lovable scamp, don't use up all my healing potions

Over the weekend I experienced two things, one rather normal for a “computer guy” the other less in my wheelhouse. The first thing was that my girlfriend wanted me to help her register a web domain for her dad for his birthday. I have done this twice before, once for the website you are currently viewing and one other time for http://prosper-lib.com (which just redirects back here for the time being). I remember the first time I registered a domain and carefully read all the forms, making measured decisions, and hesitantly moved from step to step unsure of myself. It took an hour or two and then a few more to set up the hosting and get ftp access, set up wordpress and get everything up and running. In total it took a few hours. I didn’t have such a luxury of time, she needed me to get the site up and running, preferably with a custom “Coming Soon” page before lunch, it was 11:00 so I only had around an hour. I clicked over to the site, click click click type type type, and it was up and running. I looked over at the clock to see how badly I had overshot the envelope, 11:15… wait what?

The second experience I had this weekend was tearing up some carpet at my new place. I have undertaken tearing up 850 sq ft of carpet to install new wood flooring in my house. The first night I was able to remove carpet from two rooms in just under 4 hours. It was my first time, and I went slowly following the instructions and making sure that I did everything just right. The second night I worked with an experienced floor guy, we finished taking out the mats, staples, tack strips and carpets from 5 rooms. Over the weekend there was one room left to do, I was able to knock it out, carpet, mats, tack strips, the whole nine yards in about an hour.

After these two events it solidified a point in my head, experience is the best force multiplier. In the first case it was my own hard won experience (not that there is really anything that difficult about registering a website). After performing the task a few times I gained an experience that multiplied my force by an order of magnitude, what once took a few hours now only took a few minutes. In the second case I was able to leverage someone else’s experience to augment my own. I learned countless tricks to getting the job done quickly and efficiently, but more importantly I gained a huge amount of confidence. Having someone that already had mastered the task work with me and confirm that I knew what I was doing gave me all the confidence in the world to go in on Saturday and tear up the last room lickety split.

There were two take away points from these experiences. When doing something new seek out someone more experienced than you to pair with, even if its just temporary. Fully participate with them, ask questions, and do not let them do everything for you. This is the best time to fail, you will get immediate feedback from the more experienced party about how you are failing, why you are failing, and how to avoid failure next time. This will give you a foothold to quickly learn by doing. The second point to take away is to experience lots of things, even if you suspect you will fail. Life is full of failures, but those failures impart experience which is the best force multiplier to get to success.

I would be unable to count the number of times I’ve ruled out some great idea because it took me down some unknown avenue, and I was afraid of failing. I have no experience charging people money, I don’t know how to start up a business, I don’t know how to make a website. These are all things I’ve said to myself at one point or another, the thing I realize now is that no one is born knowing how to do these things, there is only one way to get experience, try new things. Don’t be afraid to fail, work hard to succeed, and know that no matter what happens the experience is valuable and worth it.


5
Feb 10

persist

semi truck

measure twice, turn once

I just witnessed an interesting even unfold in front of my current client’s building. Today in beautiful Columbus, Ohio we are experiencing one hell of a winter storm, lots of fun. A semi truck decided that our parking lot was a great place to turn around in, he just apparently forgot to measure. CRASH BOOM and the lamppost has changed from its normal 90° to a more precarious 78ish°. After striking the lamppost and ramming a concrete barrier the semi was fairly well wedged, but the driver continued revving and the engine struggled and moaned. This persistence paid off and after about 10 minutes of maneuvering he was free. Now to call the insurance companies.

This got me thinking about the nature of difficult situations (self-imposed or otherwise). I also had a breakthrough largely due to persistence today, so happy coincidence. After months of working on documentation, being told that I would never be allowed to program the sacred system, the tides have turned (thanks to an excessively high quote) and the coach has called me up, and I’m ready to play under the bright lights.

I’ve just completed printing out 400 pages of documentation (my weekend is going to be so much fun!) and I will prepare myself for the difficult task ahead. My persistence has paid off, but the bigger realization is that persistence in general pays off.

To borrow one of my favorite quotes from Scrubs, “People are bastard-coated bastards with bastard filling.” People don’t ever want to think that you can succeed, and they are going to tell you no over and over again. There are two reasons for people to shut down your dreams:

  1. They have tried and failed, the task is impossible, your success would undermine them. If you succeed where they have failed then it isn’t an impossible task, they just weren’t good enough to do it.
  2. The have achieved it, but only by their virtue of their amazing talents and pure force of will. You don’t have what it takes!

This is why it’s vitally important to ask people for advice, sage wisdom, realistic assessments, but always keep in mind that very few people actually want you to succeed, especially if its in something they can’t or already have. Don’t worry though, these aren’t bad people, it’s human nature, and when you succeed you will act the same way. Success through hardship and against the odds plays a fun trick on the human brain, it makes you believe you pulled off the impossible. This feels amazing and so you will do anything in to hold on to it, and you don’t want some dirty unwashed masses pulling off the same feat and diminishing it.

The big lesson here though is persistence, the most successful people in the world are those that were willing to have the door slammed in their faces 1000 times before making that sale. This is what you need to do, steel yourself for the struggle, prepare to be emotionally drained, and realize that this is what living is. Life is a stream of people telling you no, with the occasional yes. What separates the successful from the mediocre is that the successful are willing to wade through all the noes to get to the sweet succulent yes.

I’ve been paying my dues on this project for 3 months, and finally I get to go back to what I love the most, coding. There are a hundred stories of people trying and failing and trying and failing and trying and failing to finally succeed. It is definitely the path less taken, but it will make all the difference.


4
Feb 10

finite

santa claus' tombstone with child crying

all that eggnog caught up to him... the cocaine addiction didn't help either.

Here’s something unpleasant to think about, you are finite. Think about it deeply, drink it in, sit with it, feel like you’ve come to understand it, then wake up in a cold sweat thinking about it some more. There is only one certainty in this life, it will end. It gets worse, your time, your effort, your experiences, they are all finite. It’s one of those big huge things in life that is too inconvenient to think about, so we don’t. This is the core reason why most religions exist, coming to terms with one’s own limited nature is terrifying. I’ve always been an Atheist, intimately connected to this notion that one day the unique thing that is me will be no more, just as for billions of years before I popped into existence I wasn’t yet. It’s something I tell myself I have come to terms with, but it is a daunting challenge and one that must be revisited from time to time.

As an aside: although I’m more than happy to discuss my personal spiritual beliefs I attempt to keep such charged matters off of this blog, if you would like to chat about it just post a short comment indicating so and I will contact you. I am an Atheist but I respect others’ belief systems and don’t intend to offend anyone.

I was driving home the other day and an interesting story came up on the radio. The main point being that as we age we sense that time is moving faster and faster. This is the spark that has led me to revisit one of the least comfortable aspects of our shared humanity. I’ve been pondering it for the last few days, thinking about my very real finiteness and trying to evaluate if I’m acting like a man with an expiration date. It was a mixed evaluation, in some ways I am, in others I am not, not a terrible fate by any stretch.

In my personal life I feel like I’m running full steam ahead. It might be the last week or so of 14 hour days working on getting my new house ready to move into. (After years of snacking and typing my body isn’t as suited to the tasks of tearing up carpets and fixing walls as it once was). I’ve set real goals in terms of building skills, building relationships, and creating code I can be proud of, and I’m exceeding my expectations. I finally feel like my wheels have caught solid ground and aren’t just spinning anymore.

There are still some areas I’m not happy with, I’m taking stock and taking action to address these. On the whole though, I feel like I’m spending my limited time here the right way for now. There are a thousand and one clichés about this subject: live each day like it could be your last, what would you do if you knew you would die tomorrow, etc. The problem is that they all take an outlook that is far too limited. No one could live each day like it could be your last, that’s fucking stupid. If I knew I was going to die I’d spend all my money and live with complete abandon, you can’t do that everyday of your life. It is the routine of life that makes this so difficult.

Life is finite but there is also a whole big pile of it. We like to think that we can wait and do something next week, month, year, etc. This is where all that “I always thought we’d have more time together” thing comes from. Want to open a bakery, learn to play the drums, fight a bear, there’s no time like the present. If you are unhappy, you have to fix that. Other people that aren’t you are probably going to tell you that you are foolish for trying to fight a bear, well those people can waste their lives while you’re out punching Yogi in the mouth.

Don’t let anything stand in your way, take it personally because nothing could be more personal. This is your precious finite life and its ticking away. If you are unhappy or feel like it’s being wasted, do something about it. Nothing could be more important. It’s not comfortable, and it can be frightening, but take stock of your life today and the whole time keep in mind, I only have so many days left, is this how I want to spend them.


3
Feb 10

bureaucracy

pentagon bureaucracy cartoon

Wait until he meets the Undersecretary for Reduction Planning and Appropriation's new Assistant

Bureaucracy, long the scourge of people who want to git-r-dun. There are some people out there that hate bureaucracy with a passion I can only really muster up for the pending zombie apocalypse. Make no mistake about it, I dislike bureaucracy, I think it is a wasteful but sometimes necessary evil. I’ve found myself ensnared in a bureaucratic nightmare for the last few months so I thought I would jot down some observations on bureaucracy.

Zombie Bureaucracy

(Wow lots of zombies in this post so far) A Zombie Bureaucracy is a bureaucracy that had some reason (however flimsy) for existing in the past but no longer needs to exist. Not unlike a zombie this bureaucracy manages to live long past its usefulness shambling into the future pointless and frustrating. This is caused by the ease that more bureaucracy can be created, at the stroke of an email someone can dream up a committee or process, but the difficulty in disbanding bureaucracy. It is disproportionately difficult to reduce bureaucracy because it looks like work, and people don’t like having their work taken away, it reduces their sense of job security.

Dev: Why do I need 3 developers to sign off on every commit?
Mgr: Because 4 years ago two of the lead developers got into a pissing war over code formatting
Dev: Why didn’t they just work it out?
Mgr: Because they had huge egos and management was too scared to fire either one
Dev: Is this still going on?
Mgr: No, Frank left 3.5 years ago because he didn’t want to put up with Mark anymore
Dev: So why do I still need 3 developers to sign off on every commit?
Mgr: Because 4 years ago…. I guess it doesn’t make much sense anymore…. That’s the way it is!

Just like misery, bureaucracy love company

Bureaucracy is an attempt to control something, to take organic chaotic processes and make them orderly. The problem that often arises is that bureaucracy is its own organic chaotic system, that then requires more bureaucracy ad infinitum. If you’ve ever been in a meeting where all you decided was the schedule of meetings, congratulations, you are in the Matryoshka doll hell of bureaucracy.

Meetings

I loathe meetings, a bunch of people talking about the work they could be doing if they weren’t in meetings all the damn time. Meetings are seductive, they sound and feel and look like work, but they are occupational masturbation. No one has ever brought a product to market because they were able to make it to 10 meetings a day. Meetings have almost no value, sometimes they are necessary, but not nearly as common as corporate culture would have you believe.

And the rest…

hot tamales candy box

Forgot to file the A34C-Bh amendment releasing liability for tongue trauma

I could go on and on, but I will cut the rant short and get to the point. Bureaucracy at its core is about trust, or more importantly the lack thereof. I don’t have my girlfriend fill out the A34C-B form (Confirmation of Confection Purchase Agreement) before running to the store to ensure that she understands that I would like her to pick me up some Hot Tamales. I trust her at her word, there is no need for such ridiculous formalities.

When an organization has enshrined itself in a monument of bureaucracy what it is really saying is, “We’ve been burned before and now we don’t trust you.” We don’t trust you to deploy your code correctly, we don’t trust you to design things properly, we don’t trust you to do X, so let’s get a bunch of people together to review it. This is fine in small doses, frankly I want people to review my code and my designs, I make mistakes like everyone else. But when taken to the extreme it takes a toll on your motivation, on your creativity, and on any preconceptions that you knew what you were doing. Bureaucracy is the surest way to crush your workforce into a homogeneous mix, you will catch the awful at the expense of the great.


2
Feb 10

stupid ideas

stupid burn

No caption needed

I want to be honest with you for a minute, I have lots of stupid ideas. I have them all day, in the shower, while eating a sandwich, while writing my blog posts, stupid ideas come streaming into my head. I used to just ignore them, “No one needs a peanut powered lawnmower” I would tell myself. The interesting turn was when I started writing these stupid ideas down.

Some stupid ideas will always remain stupid ideas, some though will change over time. That dumb idea might actually just be so brilliant it looks stupid. It might be so big and scary that you’ve convinced yourself it’s stupid. It might not be a bad idea at all, after some careful reflection. It might even be a wonderful idea.

Why do we throw away our stupid ideas? Is it because we don’t have time for them, bah, that can’t be it, you are currently wasting precious time reading the stupid things I have to say. Is it because we are so swamped with brilliant ideas that we have to prioritize, probably not, or else you’d be sipping margaritas next to your perpetual motion machine. No, the answer is much simpler, its because we are afraid or failing. Stupid ideas are failure babies, a dumb idea grows up to be a hairy ugly failure, and we have learned in the school of life that failures are bad, so we avoid them.

Have you ever talked to a 4 year old? I have on various occasions, interesting little buggers those 4 year olds. They will tell you every little thought that bounces into their overly energetic little brains, no matter how wrong or foolish. They don’t mind failing over and over again, they will insist the moon is made of mashed potatoes and not feel bad at all when you tell them the truth. And most importantly they learn a ton of information.

Now don’t take this the wrong way, I don’t think you should just go around like some half-cocked lunatic spouting off every little thing that pops into your head. There was a time for that and if you go into the board room now insisting the moon is made of mashed potatoes you will be roundly mocked and rightfully so. What I am advocating is the preservation and analysis of your stupid ideas. Let’s take a look at some stupid ideas quickly to see why this is useful.

  • Idea #1: A blanket that has arm holes and you wear it backwards or something… yea like a backwards robe! Pretty fucking stupid, but better known as the Snuggie, which has become a huge success and sold tons.
  • Idea #2: Instead of executing the code on this machine, let’s build another machine that doesn’t actually exist and have that fake machine live on the real machine and have code execute on the fake machine…. What? What are you rambling about Jenkins, get out of my office! Jenkins just invented the Virtual Machine architecture that power things like Java’s JVM and .Net’s CLR.
  • Idea #3: Wouldn’t it be awesome if you could tape together 4 iPhones and have like a really big iPhone. I’m sorry, did you just smoke a bunch of peyote?! That’s dumb…. Or its the new iPad.

You get the picture I’m trying to paint here. A lot of the amazing things we take for granted and depend upon everyday, things that seem like great ideas now, all had a moment in time when they were some far-fetched pie-in-the-sky dream. Most ideas start off as stupid ideas. Stupid ideas are important and valuable, not all of them, but there will be some diamonds in those dirt clods. You just have to be smart enough to sift through them.

My advice to you is to jot down those stupid ideas you normally throw by the wayside. Revisit them every once and a while, re-evaluate their “stupidness.” Sometimes you will find a diamond in the rough, sometimes a stupid idea can be the spark needed to have a brilliant idea, and sometimes you will just get a good laugh out of the stupid things you think up.


1
Feb 10

open format

bank safe

We'll just lock your data up in here, don't worry we'll open it up later if you need it. This is what a closed format sounds like

Back in the days when a computer had 64k of RAM and high-capacity meant you had a double-sided floppy disc, there were these funny little things called binary file formats. We still have them today, they are the “pattern” that a program will write and read to and from disc to save and load a file into a program. Some are open, like image file formats, and some are closed, like Microsoft’s binary blob formats for Office. As the world has advanced and storage has become dirt cheap people started looking for an easier way, and whenever there is a problem that we don’t have a tool for yet, we reached for XML.

XML is actually not a bad fit for this problem domain, its a little on the ugly side, but that’s ok, very few people crack open a raw file to read it. The people that are cracking open files in a text editor to peer inside are probably tech-savvy enough to read a little XML. The big bonus of switching to XML, like ODF or DOCX, is that there are very mature XML parsers and writers for almost every programming language. That means that a determined programmer can grab a copy of your format spec, her favorite XML parser, and write a program that operates on your file format. This is the essence of that oh-so-marketing-speak word synergy.

Now I would love to take credit for this awesome idea, but if you’ve read The Art of Unix Programming you will recognize this as nothing more than an extension of the Rule of Composition. Now that you’ve read the Rule of Composition (and you should make the time to read the rest of the Art of Unix Programming, even if you never plan on programming anything for Unix, the lessons within are just in general great to know), you will recognize the inherent advantage of having parsable file formats. Now that I have cunningly converted you over to my way of thinking, what format should you use?

XML

XML (eXtensible Markup Language) is the old standby, it is reliable, standardized by the W3C, well-supported, and there are tons of tools around for playing with XML. XML is “human-readable” for those of you unfamiliar with it here is an example.

&lt;book&gt;
  &lt;title&gt;Example Book&lt;/title&gt;
  &lt;pages&gt;
    &lt;page&gt;
      &lt;![CDATA[
        ...page stuff here...
      ]]&gt;
    &lt;/page&gt;
    &lt;page&gt;
      ...you get the idea...
    &lt;/page&gt;
  &lt;/pages&gt;
&lt;/book&gt;    

Its a bit tag-heavy and that means a slightly large file size, this isn’t a huge concern since storage is so cheap, but you should be aware of it. XML has a neat feature called DTD (Document Type Definition), armed with this most parsers will be able to tell right away if a document is well formed. XML is big and clunky but a fine choice for many applications, especially if you need typing information.

YAML

YAML (YAML Ain’t Markup Language) is the format of choice for the ruby community. YAML is well supported by most mainstream programming languages, it is a more lightweight choice than XML. Here is the same thing as above in YAML.

book: Example Book
  pages: 
    - page: &gt;
      ...here goes my page data...
    - page: &gt;
      ...you get the idea....

YAML uses the structure of the text to indicate the structure of the data. Ending tags are dropped and indentation becomes more important. YAML looks simplistic at first but has a wide-array of functionality hiding below the simple hello world examples. References, hashes, arrays, and much more are possible with YAML. The specification allows you to make concise documents that contain an astounding amount of information.

JSON

JSON (JavaScript Object Notation) is a lightweight way to represent data structures. JSON excels by being incredibly simple to learn and use. There is native support for it in JavaScript which makes it ideal for use in AJAX (which would then technically by called AJAJ), and there are JSON parser available in most mainstream languages. Here is the example from above in JSON.

{title: &quot;Example Book&quot;, pages: [ page: &quot;...page stuff goes here...&quot;, page: &quot;...you get the idea...&quot; ] };

Just like in JavaScript everything in JSON is a Hash or Array. JSON is a simple typeless data recording system, perfect for dynamic languages. JSON is a proper subset of YAML 1.2 so most YAML parsers can also parse JSON. JSON’s incredibly lightweight nature lends itself for being used when sending data over a wire or when space is at a premium.

BSON

BSON (Binary JavaScript Object Notation) is a binary form of JSON. It is meant to be more space efficient than JSON but maintain the ease of parsing. It is described as “A General-Purpose Data Format” and was devised as the serialization medium for the MongoDB project. It is an interesting format to look at if space is at a premium and there are already parsers for C, C++, PHP, Python, and Ruby.


File formats no longer need to be gnarled, tangled messes. We have new standards that allow us to freely share data created in one program to be analyzed, manipulated, and turned into something new in another program. Being able to freely interoperate is the future of computing, it is the driving force behind web standardizations, micro formats, and open file formats. The next time you need to persist data to the file system, resist the urge to roll your own serialization scheme, and check out one of the technologies presented above. The world will thank you.


27
Jan 10

objective measure

ruler

this ruler is deep and spiritual, that's why it was photographed in black and white

I’ve found myself in an odd situation as of late regarding my work, I am a programmer by trade and education but haven’t done any professional programming for 2-3 months now. It’s not that I’m being lazy and don’t want to program, I would jump at the chance to fire up Eclipse right now and start writing mountains of verbose Java code, it’s that I’m not allowed to program. “Not allowed?” I hear the shock and dismay in your voice, so let me explain.

My role on this project is to design middle-ware but because of the way the business is set up I’m not actually allowed to program, the programming is all outsourced. Instead of actual programming I get to engage in some weird form of meta-programming where I turn a program into long flowing sentences in a Word document that take about 3 times the effort to write than the program itself so that it can be shipped off and someone else can program it. It is an odd situation indeed, but I am no business man, this project is important, and so I shall continue in this weird meta-programming.

This is not my first dance at the outsourcing-prom and with the economy in shambles I’m certain it won’t be my last. I have yet to work on a project where the supposed benefits of outsourcing have actually materialized. I did some research (typed something into Google) to attempt to find out how many outsourced projects fail and saw figures between 25-40%. These seem fairly reasonable to me, and with some statistical hand-waving I will use these as “good enough” figures for the rest of this post. This leads to an interesting question though, if this strategy fails so often why do companies continue to outsource?

I would like to posit that a major reason for the continued use of outsourcing is the gap between subjective and objective measure. Subjective measures come from within, they are personal opinions, things like “Frank is a great worker!” or “Jim is so lazy” are subjective measures. Objective measures are fact-based measures things like “Frank worked 48 hours this week” or “Jim only produced 1 class file this week.”

Often, like in the examples above, our objective measures inform our subjective measures. The problem with software development is that there are no good objective measures. As much as we like to think of what we do as a science or even an industry, it is still a craft. In the above scenario we are led to believe that Frank is a “great worker!” because he worked 48 hours this week and that Jim is “so lazy” because he only produced 1 class file. If Frank worked 48 hours doing simple things and just racked up the billable hours is he really “working” harder than Jim who wrote a full web server in one week (monolithic in design so it was only one class). Getting to the heart of the value that someone produces is a difficult process and is by its nature subjective.

Here in lies the problem, software development can really only be measured subjectively, which is hard. Objective measures are much easier though, and so those are often used as a proxy for doing the difficult work of subjective measures. There have been many attempts to make sure people are performing up to par, lines of code, commits, bugs, hours worked, etc. None of these are really ideal, together they can begin to form a picture of the subjective nature of the situation, but they are not nearly enough.

Objective measures are also very seductive because you can perform calculations on them, they are easy to compare, they are easy to play out what if scenarios with. No one balks at answering the question which child is taller, but ask them which one they love more and watch them squirm. Objective measures are great because you can throw them in excel and analyze them, this is also a weakness. It’s easy to draw up a spreadsheet with your in-house assets pitted against outsourced assets and see that you can save a bajillion dollars by outsourcing, but that misses the bigger picture. What are the subjective downsides?

These subjective downsides end up failing some 40% of outsourced projects, communication, quality control, and responsiveness are hard things to chart and graph, but can easily cause a project to run off the rails. What is needed is either some way to make subjective measure easier or some fantastic new unit of objective measure. I would propose ihumanables per hour be the unit if anyone can come up with some really nifty objective system, but I don’t see that happening anytime soon, so all that’s left is making subjective measure easier, a tall order indeed.

At the heart of making subjective measure easier is really what a lot of the agile methodology is about, stand up meetings, scrums, kanban boards, they are all meant to produce a tight feedback loop so that the subjective nature of the situation is constantly being polled. I’m not going to sit here and tell you all to start running agile projects, although they can be a good bit of fun, but if you are managing people you need to get in the dirt with them. Progress reports and weekly status meetings are meant to supplement not substitute actually working with and understanding what the people under you are doing.

Remember the next time you are making a decision based off of objective measure, if you are “going by the numbers” that there are very real subjective side-effects that you should account for and be aware of. And if someone develops a really killer objective measure for software development, remember ihumanables per hour ;)


26
Jan 10

when in rome

collisium

Trust me, you want to do what the Romans do, I mean... have you ever built a Collisium?

Ah the cliché of it all, “When in Rome.” Although it would be nice to have a post about being in or traveling to Rome, sadly this is not the case. Instead, this post is about following convention and how that can help you learn.

I’ve been getting into ruby as of late, after learning Smalltalk, Objective-C, and LISP (to varying degrees), ruby hits a nice sweet spot of stealing some of the best bits from each. I was recently approached by a friend who does primarily .Net programming about the best way to go about learning ruby. He had decided that, at least in the beginning, he should use the NetBeans IDE. This seems harmless enough, even logical for someone who spends their entire day in Visual Studio to want the comforting guidance of the IDE. It is also the exact wrong approach.

As he progressed past simple “Hello World” examples and onto his first rails project he found himself battling with the IDE. Odd error messages, the IDE struggling to provide auto-completion on the dynamic models, but most importantly a complete lack of resources. The ruby and rails world to a large degree lives and breathes on the command line, right now if you go to my home computer you will find 4 terminal windows arranged with a mysql shell, script/console, script/server, and one for git. If something goes wrong and I get a weird error, I do what all great programmers do, copy and paste that sucker into Google. I normally find somewhere around a bajillion hits with solutions, huzzah!

My friend on the other hand had trouble doing the simple things through the IDE, like installing gems. I’m certain the IDE was capable of it, and that someone better versed in it would be able to help him out, but the Google-scape was barren to his questioning. All I could say to answer his questions were, “well I’m not sure how NetBeans does it, but on the command line just type gem install [gem]” (Also I can speak in teletype, I just do a robot voice.)

Despite the difficulties, my friend clung to the belief that the IDE was the way to go for beginners. I finally realized the perfect analogy to drive home the point, I asked, “Would you ever advise someone new to .Net to learn it by using the command line tools?” It’s a perfectly valid question, I’m sure plenty of people who hang out in vim all day and don’t mind doing things like ./configure && make && sudo make install (thanks Jeremiah for pointing out my n00bishness) would feel much more at home on the command line.

I am not free of fault on this either, when I attempted to learn git for the first time, I used TortoiseGit. I was very comfortable with TortoiseSVN and thought it would ease the transition. It sure did, I was able to treat git exactly like svn, and completely miss the point! Once I moved to the command line (and watched some screencasts and read some articles) I felt much more at home with git, and even began to understand why I would want to use it over svn. I had stopped trying to make it something it isn’t and embraced the thing that it is.

The point here is that when you learn something new, it’s new, don’t bring along your technological baggage. If the community all rallies around some IDE (.Net, I’m looking at you) then for flying spaghetti monster’s sake, use that IDE. If they rally around the command line (ruby, I’m looking at you) then by the hammer of Thor, use the command line. If they rally around some weird virtual environment machine (smalltalk, I’m looking at you) then have fun and realize you are never going to be able to use that at work (just poking fun, I <3 smalltalk).

The point here is that learning something new is often times uncomfortable, you have to feel like a tourist for a while. When in Rome though, do as the Romans do. Embrace the methodologies, naming conventions, and tools that are the community standard. Give it a few weeks, if you still find yourself hating it, then maybe that particular technology isn’t for you, it’s ok, we can’t all love everything. Life is about trying new things and figuring out what makes you want to get out of bed in the morning, for some people it will be .Net, for some ruby, for some COBOL (just kidding, no one likes COBOL).

You never do yourself any favors by half-way learning something, because you will either hate it because it was poorly shoehorned into an inappropriate paradigm, or you will learn to love it. “That second thing doesn’t sound too bad” (I can sense your thoughts), and at first blush its not, until you want to start participating with the community by using others’ code and sharing your code. Then you will have to unlearn all the bad practices you’ve adopted and have a difficult transition into the community, attempting to erase months of muscle memory. Save yourself the difficult task of trying to unlearn something and simply embrace the technology in full to begin with. It’s a steeper curve, but the payout is the depth of understanding.


25
Jan 10

api

samsung microwave

oh creator of hot pockets, we praise thee!

I remember being a young lad preparing myself for university I was given a gift from my mother, “C++ for dummies.” The vote of confidence on my status as a “dummy” aside, I read the book with great interest. There was an analogy the author used to explain the idea of classes and what functions they should expose, I’m going to shamelessly steal it (paraphrasing as I don’t have the book with me).

Imagine your son comes up to you and says he wants to make some nachos. You tell him that its fine by you, just go cook them in the microwave, and there is nothing controversial about this statement. Microwaves are actually boxes full of high energy radiation being produced by cavity magnetrons or waveguides, to the end user, the microwave is just a magic warming box. It exposes a very simple interface, some buttons that allow you to enter the amount of time you want to cook something.

This is the essence of an API (Application Programming Interface), wrapping up something complex and possibly dangerous in something safe and easy to interact with. When building code that you intend other people to use someday, it is the part that is most important part, and the part that is easiest to overlook. The problem is that we are often too close to something and too concerned with our use case. If you want to design code for others to use, it requires significant time and effort, and even then you probably still won’t get it right.

Prosper is still undergoing active development, I’m currently agonizing over how I want to expose various execution modes. The solution, no matter what I pick, is trivial to implement, but the api is the most important part. A great api exposes a consistent concept, something that is easily grasped and allows the end user of the api to declare what they want to do without having to worry about how its going to get done. Since good programmers write good code and great programmers steal great code, I’ve modeled the api for prosper extensively off of jQuery. And why not, let’s take a look at two different APIs, the browser dom api and jquery.

  //Let's barber pole a list by coloring every other element blue
  var list = document.getElementById('the_list');
  var highlight = false;
  for(var i = 0; i &lt; list.children.length; i++) {
    if(highlight) {
      list.children[i].style['backgroundColor'] = '#FF0000';
    }
    highlight = !highlight;
  }

Fairly straightforward implementation, but it concerns itself heavily with the “how” of what its doing. Manually traversing to pick the elements it wants, eww.

//Same thing using jquery
$(&quot;ul#the_list li:odd&quot;).css(&quot;background-color&quot;, &quot;#FF0000&quot;);

jQuery is definitely magic, but this code is great because it let’s you focus on the “what” of what you are doing. How does jQuery go about selecting the right elements and all that? I don’t care, and the great thing is I don’t have to care, and if in the next version of jQuery they find a way to do it faster, I win without having to do anything.

Writing a great api is difficult, you have to divorce yourself from the concrete problem you are solving and look at it in the abstract. Put yourself into the shoes of someone trying to figure out how the api works, and then ask the questions they are going to ask.

  • Why do I need to build up this context thing and pass it in?
  • How come there isn’t a sensible default for these arguments?
  • What dumbass made this thing?

Answer those questions, and keep working at it, strive for elegance and consistency, because then it will be easy for people to learn and use. If your code is easy to learn and use, people are going to want to use it more, and they are going to want to tell their friends about it. Then you can get some lucrative ad campaigns with Nike because of the boffo library you write in FoxPro.

There is a more subtle lesson in all of this though. Any code you write is exposing an api to someone else. “But only I am ever going to use this code!” I hear the naysayers warming up their keyboards for the comments section. This may be true now, but the six-months-from-now-you is going to look back at the you-of-today and wonder what the hell he was thinking.

Get in the habit of making your code easy to use, and expose a nice api. This will endear you to your fellow programmers and help make maintenance easy. Strive to be that guy on the team that writes functions and classes people want to use. Make life easier for your fellow developers and even if they don’t return the favor, maybe they will take you out for a beer. People notice over time that your code is the best to work with, they internalize it, and they start to think of you as a great programmer. That’s a pretty great api to expose to the world.