There’s a wide sense of lament since Oracle has taken over Sun and their intellectual property, including MySQL, Java, Solaris and their hardware sales business.  I’d say the average observer of this process might use the terms “slow moving train wreck”.  I doubt they are far off on this one.

You know what?  I think Oracle taking over Sun and acting stupid is actually a GOOD THING.

No, really I do.  Let me explain.

Sun has a long history of innovation with Java.  They also have a long history of missteps (take your pick, but I personally like the layoffs that happened biannually but basically culled the best folks who took packages to get out of the toxic environment)  and flat out screw ups (Hello?  Selling off your $1B/year professional services business because you’re not a “software company”?  Wish I had those kind of problems).  I have a number of personal friends who worked there (mostly past tense, but there are still a few stragglers left) and I don’t wish their employer to crater.  No, not at all.

So why is Oracle’s behavior regarding the death of Open Solaris or suing the crap out of Google for the use of Java in Android a good thing?  Easy:  We now have an opportunity to spur the development world into action.

The Empire Formerly Known As Evil

Flashback to 1995:  Microsoft (the former and still ranking Evil Empire) was king of the developer world.  Open source was a twinkle in the eyes of a few idealists.  Developers paid handsomely to buy into the Visual Studio paradigm.  Or they bought from a competitor (Borland).  C++ and C were the de rigeur choices of language at the time.  Enter Java and the entire development world was turned upside down.  No one saw Sun as the disruptive innovator at the time.

Of course, other factors played into it over the years:  the rise of the internet, the Dot Com boom and server sales tied into Java usage, the rise of open source and the overwhelming support from the community regarding Java, driving huge amounts of frameworks still in use today.  But there was always a motive:  fight the evil empire.  We fight them because the evil empire doesn’t “get it”.  Remember Microsoft’s internet strategy in the late 90s? (From a blog post regarding the missteps of Microsoft, particularly Project Blackbird)

Adobe’s Mark Anders about his time at Microsoft. Anders is well known as one of the inventors of ASP.NET, along with his colleague Scott Guthrie. However, when he joined Microsoft in the mid nineties he worked initially on the project codenamed Blackbird. This was a kind of Windows-specific internet, and was surfaced to some extent as the MSN client in Windows 95. Although the World Wide Web was already beginning to take off, Blackbird’s advocates within Microsoft considered that its superior layout capabilities would ensure its success versus HTTP-based web browsing. It was also a way to keep users hooked on Windows. Anders told me that he never believed in Blackbird and argued that Microsoft should support HTTP instead. According to him, the executives at the time did not want to listen at first, but Blackbird had severe performance problems

Stuff like this always pisses off the right people. Microsoft didn’t get it, and people got mad.  Microsoft’s stupidity in thinking they could control the internet spurred lots of innovation from other companies to make the *real* internet even more valuable.  Eventually Microsoft capitulated and followed suit with everyone else. 

And that’s precisely what I’m counting on here for the Oracle debacle. Because Oracle isn’t getting it either (at least for developers). Tim Bray’s article today has a great quote from the Empire itself:

“You don’t get it. The central relationship between Oracle and its customers is a business relationship, between an Oracle business expert and a customer business leader. The issues that come up in their conversations are business issues.

“The concerns of developers are just not material at the level of that conversation; in fact, they’re apt to be dangerous distractions. ‘Developer mindshare’… what’s that, and why would Oracle care?”

Let’s Shake Things Up

Java not good enough for Android?  Fine, let’s make a new language that finally innovates on the mobile device, unlocking us from the collective disasters of Objective C, mobile Windows, and bloated Java ME.  If Java 7 is going to die at the hands of Oracle, maybe that will motivate some development group to actively fork it in a meaningful way.  Or finally develop the successor language to Java that revolutionizes the software community the way Java did in the mid-90s.

This complacency about Java, MySQL, and the state of Sun products has got to stop.  It’s time to shake things up.  And the last time that happened, exciting times were had by all.

I can’t wait.

Related posts:

1. Google’s Go Isn’t Getting Us Anywhere, Part 1
2. Google’s Go Isn’t Getting Us Anywhere, Part 2
3. Data In The Cloud: Cloud 9 or Plan 9?

An experiment, posted on LessWrong.com that led to a further diatribe on rationality and rational thinking traps got me thinking too.  Here’s the problem:

Once upon a time, there was an instructor who taught physics students.  One day she called them into her class, and showed them a wide, square plate of metal, next to a hot radiator.  The students each put their hand on the plate, and found the side next to the radiator cool, and the distant side warm.  And the instructor said, Why do you think this happens? Some students guessed convection of air currents, and others guessed strange metals in the plate.  They devised many creative explanations, none stooping so low as to say “I don’t know” or “This seems impossible.“

And the answer was that before the students entered the room, the instructor turned the plate around.

This is Occam’s Razor at its finest.  But these unwitting physics students are no different than the average programmer out there when confronted with a bug report.  Take this example of a guy who had a strange logic error in a core Linux package:

A few weeks ago, though, I encountered some bizarre behavior on my desktop, that honestly just didn’t make sense. I spent about half an hour digging to discover what had gone wrong, and eventually determined, conclusively, that my problem was a single undetected flipped bit in RAM.

This guy admirably spent a long, painful session tracking his error to a faulty location in RAM.  But his most likely rationale for why?

For me, bitflips due to cosmic rays are one of those problems I always assumed happen to “other people”. I also assumed that even if I saw random cosmic-ray bitflips, my computer would probably just crash, and I’d never really be able to tell the difference from some random kernel bug.

Cosmic rays!  Now, the possibility exists, that’s true.  But is it the most likely explanation?  No, not by a long shot. More likely:  faulty RAM due to manufacturing defects.  More RAM failures are documented as problems than cosmic ray defects.

Why do we have some perverse belief that all our problems are exotic, unusual and outside of normal?

When you discover a bug in your code, is your response:

1. Hmmm, I wonder what simple thing I did wrong here?
2. I wonder if there’s a kernel bug in Linux causing that?

Simplicity isn’t just a goal in optimization, but in finding the source of bugs too.  Never let the truth interfere with a good story, I always say.

No related posts.

Recently, I was the happy recipient of some very condescending “advice” from the architecture group of a client.  The tone, quality and delivery of the information completely overwhelmed the actual message (some of which was actually relevant, and some was off in left field).  This pleasant experience reminding me why the term “software architect” has come to be synonymous in some circles with “arrogant jerk who forgot what it’s like to code on a real project”.

I realized that I’ve had that exact same attitude at times and it just didn’t pay off at all.  My message was probably lost in the same manner I discarded this guy’s advice in favor of sticking it to The Man and doing whatever I was going to do anyway.

All of this is counterproductive in any development project.  Reflecting on the situation a bit more, I realized that there are a handful of key points that all software architects ought to remember.  Dispelling the “Ivory Tower” mentality can’t be anything but positive for everyone involved.  With that in mind, I bring you the

Five Minute Guide to Avoid Being the Asshole Architect (FMGTABAA):

1)  Eat your own dog food

Nothing screams “Ivory Tower” like handing down some code you cobbled together to a group of developers to “figure it all out”.  If you write a library to perform common validations, write up a standard test page and post it for all to use.  Consider this your uber-test case.  Or better yet, write an application that uses that same library and see how it works out.  Find out the pain points your consumers will actually feel by becoming one of them.  Anyone who hands you code they just put together in a manner they thought “would be useful” shouldn’t be trusted.

2)  Standards apply to you too

It’s fun (well, maybe to some people) to put together standards documents that lay out the coding conventions, code organization, source code nomenclature, build structures, and so on.  But to publish those standards and fail to hold yourself to them is the highest form of hypocrisy imaginable.  If you can’t follow a standard, why would you expect anyone else to follow it too?

By applying the standards to your work, you’re also eating your own dog food in another sense.  You see what will be painful for others.

3)  Communicate like you are a Teacher, not a Preacher

Architects are supposed to exist as a font of knowledge and experience.  Failing to share that information is pretty much against your core job description.  But how you communicate that experience is just as important as the information itself.  Think of your best teachers in school—did they ever strut at the front of the classroom and tell you how damned smart they were?  Doubtful.  They found ways to express their knowledge that encouraged your learning and questioning.

That condescending tone I received on the architect’s email was the ultimate turn off.  Whatever valid information was being delivered in the message was completely lost because there was no mutual respect.

Power politics kills development projects quicker than baby rattlesnake poison will take out your dog.

4)  Lead by example in Documentation

What’s the Number One complaint about open source projects?  Lack of, or poorly written documentation.  Why is that?  Documentation isn’t exactly the Crystal Meth of programming.  More like Sominex.  No one likes doing it.  Especially those that are good at writing code.

Instead of whipping development teams saying, “You need to produce better documentation”, give them a concrete example of your work.  That also helps with point #3 (Communication), as well as demonstrating point #2 (Standards Apply to You) and point #1 (Eat Your Dog Food).  Push development teams to achieve the standard set by your team for quality.

5)  Command from the trenches, not the Ivory Tower

If one idea generated the majority of contempt for software architects, I think this was it.  Somewhere along the way, the notion of architecture outside of mainstream development took hold and the notion of the Architecture Group was born.

Not once, in any company I’ve ever worked with or for, did this idea bear positive fruit for the development teams involved.  Instead, these segregated groups have generated one or more of the following:

• Contempt for the architecture because the developers had no say in it
• Rejection of the framework because it was impractical to apply to the project at hand
• Blatant disregard for the standards set by architects because the architects did not have to adhere to business needs and company deadlines as a result of the delays introduced by their work

Architects should be a member of the platoon, never a visiting dignitary to the army base.  Teams respect the opinion of someone who lives their daily reality side-by-side with them, not someone who hands them the Ten Commandments and walks back to their posh tent.

6)  Throwing your prototype/framework/design/UML documentation into the hands of the unwashed masses is not the end of your involvement

No sane building architect would throw their blueprints over to the foreman and expect it to be built in their vision.  Related to point #5, architecture teams that believe their involvement is limited to the design phase don’t really understand what it means to be architects.  When a building is being built, the architect is on site during the majority of the project, overseeing the effort at a high level, ensuring that little changes are not impacting the big picture.  All the while, the architect assists in solving minor problems that arise from his or her design from a practical standpoint.

In short, the architect’s involvement is continuous, not discrete.

7)  Attitude may work in the military for commanding respect, but it rarely succeeds in IT

Finally, acting superior, like a know-it-all, or someone who is above listening to others, is just asking to be ignored.  Don’t do it.  Ever.  Not even on a bad hair day.

Friends don’t let friends act like asshole architects.  The respect you save may be your own.

Related posts:

1. Habit 7: Principles Are More Important Than Results

Quick!  Answer the following question without thinking about it:

How would you rate your programming skills?  (Below Average, Average, or Above Average)

Based on psychological studies across many different groups, about 90% of all programmers will answer “Above Average”.

Of course, that can’t possible be true.  In a group of 100 people, 50 are above average, 50 are below average.  This effect is known as Illusory Superiority.  It’s been documented in many domains and even if you’re aware of it, you’ll probably still answer the question above as “Above Average”.

For even more fun, try asking that question to every programmer you know.  Don’t ask them in a group, ask them one-on-one to get more ‘honest’ answers.  You’ll get similar results, even from people who you know can’t program their way out of a wet paper bag (this is the Dunning-Kruger effect, but it’s related).  It’s an epidemic in our profession.

Now, let’s suppose for a second that you’re right–you are actually above average.  You are da man.  A rock star.  God like capacities amongst mere mortals.  Keyboards bow in reverence to you as you approach.  Trumpets sound on high when you commit on GitHub.

If you’re above average, then chances are you’re an expert at what you do.  Calling yourself an expert sounds quite compelling–you get respect, deference, and prestige by being one.

Being an expert means you know it all about your subject. Unfortunately, it also means you’re going to get lazy.  It means you’re going to eventually rest on your laurels and sit around thinking you’re better than everyone else instead of actually working to get there.  Your expertise will become a liability because you stop trying to learn.  Maybe not today, but soon enough.

Instead, why not consider the more likely possibility?  You’re average, or heaven forbid, below average. Aside from the personal stigma you might suffer here, think for a second about the real benefits of doing this:

• By assuming you’re not at the top of the pack, you now have incentive to get there
• By assuming you’re not the smartest person in the group, you now have the opportunity to learn something
• By assuming you’re not the best at what you do, you’re going to work harder to improve yourself

Perhaps you’ve heard of beginner’s mind?  Summed up by a zen master in classic koan-brevity:

In the beginner’s mind there are many possibilities, in the expert’s mind there are few.

The trap of calling yourself ‘expert’ at software development means that you pigeonhole yourself into some language (Java, Ruby, PHP), some industry (medical devices, social networking, games), or some specialty (embedded programming, enterprise software).  Once you establish that expertise, fear of failure arises when you consider going outside that comfort sphere.  With your golden hammer of experience, everything appears to you a nail.  You stop thinking about screwdrivers and all other possible relevant tools because they’re no longer inside your ‘expertise’.

This is why starting out in software you wonder why “experienced programmers” can’t get X, when you just learned X in a matter of days.  X could be anything:  closures, object-oriented programming, Ruby on Rails framework, Haskell programming.  It doesn’t matter in the end, the expert’s mind is cluttered with old knowledge.  The beginner’s mind is open, free of hindrances.

It’s harder to learn when you’re an expert.  And this is why being the ‘expert programmer’ is dangerous.

So what’s the number one thing you can do to be the best programmer out there?  Start by considering yourself below average. Step out of your comfort zone.  Be the averagest.

A master never stops learning, and neither should you.

No related posts.

If you walked into a store and asked to have someone make you a suit and you agreed on a price of $100 and week’s sewing time, a week later you’d expect to walk back in and be trying on your new suit after parting with a $100 bill (at least in America).

What if you went into a different store, after that initial price quote and they offered to make it for $25?  You’d think, “Great!  One fourth the cost of that previous guy!  I’ll take it instead.”

How would you feel if a week later you came back and they said it would be another week and $50 instead?  Think you’d be mad?

How much madder would you be after TWO weeks, and now the shop owner is telling your it will be $75 and one more week, but this time he’d definitely get it done.  And after you get it, you notice that the pocket is sewed on slightly funny and the trousers don’t fit quite the way you’d expect.  Would you be steaming mad now?

Yeah, I would too.

This is exactly what happens with outsourcing projects in most software companies.  If you ask companies why they do it, invariably they answer that outsourcing will save money AND time over local resources.  That’s an unbelievably huge lie. It’s time to tear that apart.

Forgetting the cultural problems you’re going to encounter with outsourcing for a minute, let’s say you have a project scoped by an outsourcing firm.  They bill their engineers to you at $25/hour.  Local contractors run you $100/hour, so you’re thinking to yourself, “Wow, 75% cost savings!  Sign this outsource guy up!”

Whoa, not so fast there, cowboy.  Let’s throw out some project statistics from the Aberdeen Group.  Unsurprisingly, reducing IT costs is the primary driver behind outsourcing for 82% of companies in the U.S.  But, as Aberdeen continues,

• Nearly 50% of outsourced projects fail outright, or fail to meet expectations
• 76% of companies said that vendor management effort and costs were much higher than expected
• 30% reported ongoing issues with outsourcer management processes (e.g., inadequate governance and conflict resolution procedures)
• 51% reported that outsourcer was not performing to expectations

In the end, the average cost savings for projects was a mere 26%.

That might sound like a reasonable number, but consider that first point more closely:  Nearly 50% of all outsourced projects fail outright or fail to meet expectations in the first place. Essentially, you’re taking the same gamble as red vs. black in Roulette about your project’s success right off the bat, and only then if you pass that hurdle, you’ll get on average, 25% savings over having it done locally.

So wait a second, where did my 75% cost savings disappear to? Let’s do the math:

Original project cost (outsourcer estimate): $10,000. (400 engineer-hours @ $25/hour)

Actual project costs: $30,000 (50% overrun on time and 100% overrun on people–longer than expected, 2x as many engineers as originally scoped, which is another finding of Aberdeen’s and other companies’ experience, so 1,200 engineer-hours @ $25/hour)

Unexpected onshore management costs: $6,000 (about 20% of project cost, from spending more time managing expectations, requirements, design reviews, documentation, etc)

Total actual project cost: ($30,000 + $6,000) =  $36,000.

Estimated project cost, if done locally: $40,000 (400 hours @ $100/hour)

Expected cost savings: $30,000

Actual cost savings: $4,000  (($40,000-$36,000)/$36,000) = 11% (for the clients I’ve worked with)

These numbers have been vetted by two recent clients of mine (due to NDA restrictions, I can’t mention either by name but one is a large entertainment conglomerate based in NYC, the other is a worldwide financial clearinghouse firm).  Both have substantial amounts of outsourced projects and both report little actual cost savings shown by front-line managers, huge management issues, and non-trivial project failure rates.  And yet, both continue to outsource because upper management believes they’re saving a lot of money through outsourcing.

Think about this for a minute: If you have 4 projects you outsource (let’s assume they are all the same:  400 hours each, and we’re using an outsource firm at $25/hour), their estimated cost of $10,000 each, and their actual cost $36,000, here’s what you get:   Your budget was for $160,000 and you believed you’d have $120,000 to spend on other projects (foolishly).  Here’s the harsh reality:

• 2 of your 4 projects have high probability of completely failing (let’s assume that they didn’t expend the same cost above, but perhaps only half before they got canceled, so say you got halfway through each and canceled them, burning $36,000 total between them)
• Of the remaining two, you get what you asked for but at a cost of $72,000 instead of the promised $20,000.
• Total budget spent:  $108,000.  Expected budget spend:  $40,000.  (Difference:  +270% over expected costs)
• Actual remaining budget for other costs:  $52,000.  Expected remaining budget:  $120,000.  (Difference:  -43% less than expected available funds)

Assuming you budgeted all your expected remaining project cash on other things, congratulations, you’re now over budget!  Welcome to every CTO and CIO’s nightmare.  And none of this addresses the other problems:  communication lags of several days to answer questions, lack of face-to-face interaction to solve problems quickly, miscommunication over simple requirements that you consider obvious but were missed in the implementation, and so on.  Are you really saving money here?

Let’s call a spade a spade:  Outsourcing just doesn’t save you the kind of money you think it will.

UPDATE:  Thanks for all the comments about my crappy math.  Yes, it’s fixed now.

No related posts.

Jakob Nielsen recently published his report on iPad’s usability and application interface consistency.  To no one’s surprise, he discovered a few issues.

What was the main problem Jakob uncovered?  Many iPad applications aren’t obvious to use:  non standard controls, confusing graphics, and counter-intuitive metaphors.  In psychology parlance, it’s because these apps lack constraints and affordances.

Constraints and affordances are nothing new, even in the real world.  You encounter them every day, but you’re only barely aware of them most of the time.  Joseph Hallinan has a great example in “Why We Make Mistakes”:

“One way to reduce errors is by introducing constraints.  Constraints are essentially simple mental aids that keep us on the right track by limiting our alternatives.  Try repeating the Star Spangled Banner if you’re American without singing it.  How much can you remember?  Now let yourself sing it.  I’ll bet you get most, if not all, of the song.  That’s a constraint against forgetting the song because that’s the only way you’ve ever learned it.

Another way to reduce errors is to use affordances.  If constraints tell us what we can’t do, affordances indicate what something can do.  Affordances may appear in many forms:  texture, shape, or size may indicate usage.  For example, a ball’s shape affords bouncing or throwing.  A knob affords turning.  Slots afford the insertion of things.  When we encounter some basic object, affordances help us answer basic questions like, “How does this work?” and “What is this used for”

An everyday affordance you’re familiar with is the pull-handle on a door.  Just by looking at it, you can immediately tell that you’re supposed to grasp on to it and pull the door open.  The opposite affordance would be the push-pad on a door, where there’s nothing to grab, only a metal surface against which to exert force as you pass through it.  Sometimes constraints are added on top of this, such as “Exit” signs on the door you use to go out as well.  These are all the clues we get on how to use a door, but you’re rarely thinking to yourself, “Oh, there’s a PULL handle, I should PULL on it.”  Affordances are subtle, important cues on how to interact with things.

Those cues can go awry.  For example, building architects foul it up occasionally by putting pull handles on the push side of doors.  Or put the “Exit” sign on the “Enter” side with an arrow pointing to the other door.  These confuse us, make us hesitate, and often force us to enjoy the embarrassment of pulling on the door you’re supposed to push (a personal favorite of mine).  Sometimes they’re done on purpose, like at a famous bar I went to in college that has two doors side by side each a large arrow pointing to the other door and a gender.

Um, which door?

They are intentionally mislabeled so women walk into the men’s restroom and vice-versa, much to the delight of the inebriated patrons.  While that sort of bad affordance was humorous in college, it’s patently frustrating to encounter when I’m struggling with a new app on the iPhone.

This lack of affordances is why the iPad and iPhone can be so bloody hard to figure out sometimes.  We have no hints–no obvious clues what to do with things mostly because the metaphors are new and the controls are often non-standard.  Consider this interface below, heavily laden with nothing but custom graphics in the UI.  Can you tell which items allow you to interact with them, and which are merely display artifacts?

Yes, I’m confused too.  And to add to the confusion, these devices allow actions we couldn’t possibly take on the desktop, like the accelerometer.  How do you give an affordance for that?  Or the shaking action?  We aren’t used to these metaphors yet, so the affordance isn’t quite obvious.

A Clear iPad Actionable UI

Contrast that with this one from the iPad, where the actions you can take are fairly clear from the interface.  (Courtesy of LandingPad.org).  Without knowing what the app is all about, you can already tell (if you’ve used touch interfaces, particularly iPhone) what you can touch, what will likely result in an action, and what items are just eye candy.

There are even more great examples on that site, I encourage you to check them out.

User interface design is hard.  Punting to a graphic designer sounds like a good idea, but consider that the difference between adequate and excellent on a user interface isn’t subtle or small.  It’s the difference between usable and frustrating.  The difference between good and beautiful.  And maybe even the difference between viral and doomed to obscurity in the App Store’s bargain bin.  Make sure you don’t just create pretty graphics, put the time in to make a pretty AND usable UI.

Don’t let your users walk into the wrong gender bathroom in your applications:  use affordances to make your UI obvious and intuitive.

No related posts.

So, think you’ve got what it takes to be a consultant?  Feeling the itch because your current job isn’t motivating you like it used to?

The independence, prospect of better money and the potential for starting your own business make this idea very seductive. A million others have tread this path before you so you’d think it would be easy, right?

Nope. Not even close.

The path to success is littered with the rotting carcasses of those who went before you and failed. Sort of like the great gold rush of 1849 to San Francisco. If you really want to get into it, even after this stern warning, you have my pity. This is anything but an easy path to success, wealth or fame.

Still not daunted? That’s a decent start. Persistence is part of the key to success here.  So is intelligence.  And confidence.  But those things just get you in the door, past the obnoxious bouncer so-to-speak.  It’s early in the night, you have to order a drink and do karaoke before you can hit the dance floor.  In other words, there’s a lot more to it than you think.

Rather than cover the business aspects of consulting, or even the how to make the jump article, I thought I’d share the secrets of successful consultants I’ve come in contact with over the years. These can make or break your career as an independent contractor. Ignore them at your own peril.

Secret #1: Your reputation is your livelihood. Protect it like your life depends on it.

Your career does actually depend on it. People hire contractors for two reasons: someone said they were worthwhile, or they thought you were the cheapest one available. You get far more jobs from the first recommendation than the second, and the quality of work is higher when they pick you for your reputation rather than your rate.

Secret #2: You are always looking for a new gig. Even when you have a current gig, keep your eyes open at all times.

Unless you’re lucky enough to get two year, iron-clad contracts, you’re always keeping an eye on the end date of your current gig, trying to figure out “What’s next?” If you get a job and think, “Oh, they’ll just keep extending me over and over”, you’re not a consultant, you’re thinking like an employee. You’ll be kicked out as soon as someone realizes it. Pay attention to new opportunities coming around, and have something in your back pocket if your current contract ends or is canceled early.

Secret #3: Assume that if you’re not adding value, you’re overhead and you’ll be fired.  Constantly find ways to add value to a project.

This ought to be a rule for employees in general, but sadly, there are too many companies that allow for this sort of inertia to exist in their ranks indefinitely. Often times, this is why a company hires consultants (to get something done), so make sure you’re the person that “gets things done”. I’m already assuming that you’re smart, now you need to deliver on it.

Secret #4: You’re never an employee at the company you contract for, no matter how long you’re there.  Maintain a certain distance.

Making friends at your contract jobs is good. Acting like you’re an employee and leaning against the water cooler, chatting with the gang mid-morning is not. Contractors are supposed to be billing every hour they’re on site. Managers tend to watch consultants more closely than employees because they pay top dollar for good contractors and are paranoid about wasting their money. Don’t be the reason you get tossed out.

Secret #5: Network constantly. Everyone is a potential new client.

You never know who is going to need a contractor at their company. You never know who will be promoted to a manager or executive and suddenly be looking for that certain person with some mad skillz to come in and take over some failing project. People end up in unexpected places, and making enemies is never a good idea. Leave companies gracefully, never burn bridges, don’t speak badly of others, even if you have some personal problems with them. These things always come back to haunt you at some later point, without exception. Don’t believe me? You won’t be the exception. Trust me.

While I don’t advocate the smarmy salesman approach, handing out business cards in the restroom at the local bar, you should stay connected. Make sure you keep in touch with people. LinkedIn is a great way to do that. Facebook is another. MySpace, maybe not so much.

Secret #6: Finish what you start. Deliver what you promise.  Uphold rigorous ethical standards.

The four fastest ways to end your consulting career:

• Fail to finish a project you were given.
• Leave before your project is finished because you wanted a better, more lucrative job.
• Lack the expertise you claim to have and accept a job based on that premise.
• Do something unethical.

Did I mention your reputation was everything? Software is a small community wherever you practice it. You’ll run into the same folks again and again. If you make a bad impression because of those items above, you can bet they will be remembered somewhere down the line when you’re interviewing at another company, if those people already work there.

To confirm reputations, many managers will ask if anyone on their staff already knows this person (Yep, Secret #1 again). A negative reputation will give the manager a reason to move on to the next candidate. Don’t give them any ammunition.

You need to be cautious about finding new work while employed with another company.  You want to maintain your reputation while still networking.  It’s a tricky balance, but we’ve already established you’re smart, so this should be no problem.

As far as ethics goes, do I even need to talk about how unethical behavior has screwed pretty much everyone in the world in the last year?  OK, good.  Moving on.

Secret #7: Consultant is generally synonymous with expert. Make sure you qualify.

You shouldn’t just start consulting right out of school or with little experience. (Accenture, I’m looking at you here with your army of under trained and overpriced pretty boys and girls that you send into large companies like a virus where they try to spread all over the place without being able to tie their own shoes) There are notable exceptions, like where your field of study was highly specialized and you acquired expertise in school along the way from your professors, internships or colleagues. But for software development, you need a few solid projects under your belt to really be able to call yourself a serious consultant. If I had to put a number on it, maybe no less than 5 years experience prior to consulting. There’s no hard-and-fast rule to it, but you should actually know something, otherwise you can’t add value (Secret #3).

Secret #8: You can try to fake it before you make it, but you’ll only get so far.  Represent yourself honestly.

There are folks out there that will tell you that a consultant is only 5 pages ahead of the customer in the same book. Sometimes that’s true. Most of the time, it’s not. You need to know your field well enough to be the expert (Secret #7). Not just sound like one, but really walk the walk here.

Secret #9: Consulting in a niche or a general field can be both good and bad. Choose your specialty carefully.

You may get two kinds of advice about entering consulting:

• Stick with something that is popular, but crowded (like Java, C++, .NET)
• Stick with something that is specialized, but has less competition (e.g. Delphi, Embedded C development, etc)

There are pluses and minuses in both sets and neither in my opinion really wins out.

• The popular fields mean you have more work available to you, but competition is much higher which pushes the overall rate for contractors lower in that skill. Java programmers are in this exact situation today.
• The less popular subject areas command much higher rates because of the skill rarity, but finding new projects is much harder and you might be out of work more often. Google Go programmers are in this situation today.

Ideally, you want to be the early adopter of a new technology that will take over the industry, like learning Java in 1995. Predicting those events is nearly impossible, so I’d suggest sticking with the things that interest you. After all, you’ll spend 30% of your life doing them. No sense in punishing yourself needlessly.

Secret #10: You are a professional. In every situation, make sure you act like one.

New contractors are tempted to act just like those around them in a consulting gig: playing politics, cracking jokes, drinking too much at social events, and the like.

The short answer is: Don’t. Not ever. Even when you’re off the clock, you’re still being judged on your behavior. Remember that reputation thing (Secret #1)? Yeah, it still applies at happy hour, or launch parties, or even casual conversation. What about office politics? Understand them but steer clear of participating as much as you can. You’re not an employee (see Secret #4), so stand above that. You’ve been hired to add value, not noise (Secret #3).

If by now, you’re yelling at the monitor saying, “Dave, these aren’t secrets! Everyone knows them!”, then I applaud you. You’re in the absolute minority and you have what it takes to succeed wildly in this field. So go forth and conquer the consulting world with your intuition.

The rest of us will just have to follow this list.

No related posts.

Top Ten Reasons Babies are better than the iPad

1. Babies eventually grow up to be better than their fathers.
2. Babies get cuter as they get older.  Think those fingerprints on your screen will get any cuter?
3. Babies don’t have a daily purchase limit.
4. After you get a baby, most people are satisfied for awhile and don’t want to upgrade for a long time.
5. Babies make other people smile when they see them.  iPads just make people ask, “What’s that?”
6. iPads look dorky in strollers.
7. Putting an iPad on your back makes you look like a Borg.
8. Babies don’t care if you use Flash, Objective-C, or Lua.  Babies just want you to talk to them in any language.
9. Babies don’t require you to dress in black turtlenecks, khakis, or attend MacWorld for any reason.
10. Babies are a LOT more fun to make than standing in line to buy an iPad

AND!

Top Ten Reasons iPads are better than Babies

1. iPads never require college educations.  The closest you get is $4.99 for the Encyclopedia app.
2. You can shut the iPad off at 10pm and turn it back on at 7am every day, without social services knocking at your door.
3. When the iPad is hungry, you can plug it in and leave it alone for two hours.
4. One word:  Diapers.
5. The iPad will never go on a first date or drive your car.  Ever.  Not even with iPhoneOS 4.0.
6. You’ll never hear the iPad asking where it came from.
7. The iPad will never walk in on you having sex.
8. Trying to swipe a baby will land you in jail.
9. Best game with a baby:  Peek-a-boo.  Which gets boring pretty fast.  Solitaire, on the other hand…
10. You can’t make menstruation jokes about babies.

No related posts.

Software has long since lost its glory-days status.  We’re not the go-to field anymore.  Geeks are no longer revered as gods amongst humanity for our ability to manipulate computers.  We get crappy jobs just like everyone else.

So, what is it that still motivates you to work as a software developer?

Ah...satisfaction!

Is it your fat salary, great perks, and end-of-year bonuses?  Unless you’ve been working on Mars for the past two years, I think Computerworld would disagree with you.  We’ve been getting kicked in the nads just as hard as everyone else.  Between budget cutbacks, layoffs and reductions in benefits or increases in hours, clearly our paychecks are not our primary source of satisfaction.

If money was our primary motive, right now we’d be seeing a mass exodus from the tech sector.  So, if it’s not the money, then what is it that we hang on to when we get up each day?  Are we really working for those options?  That salary bonus?

Turns out, we’re kidding ourselves if we think that’s our real motive as developers.

The assumption: People perform better when given a tangible, and even substantial, reward for completing a task.  Think bonuses, stock options, and huge booze-driven parties.

The reality: In a narrow band of actual cases, this is true.  (And by narrow, I mean anything that isn’t a cognitive task, simple or complex, according to the research I quote below).  By and large, the reward-based incentive actually creates poorer performance in any group of workers for cognitive tasks, regardless of economic background or complexity of the task involved.  (Sorry, outsourcers…dangling the reward under your workers noses doesn’t help even when your home country is considerably poorer on average than Western economies.  Yet another surprising finding of their research.)

I’m not making this up, nor am I just drawing on anecdotal experience.  Watch this 18 minute video from TED and I’ll bet you’re convinced too:

Daniel Pink gave this lecture at the 2009 TED.  It’s mind-blowing if you’re stuck in the carrot-and-stick mentality.  And I’ll just bet, unless you work for Google, are self-employed, or extremely worldly, you probably are.

I’m not saying that to be mean or controversial.  I’m saying that because this mentality has pervasively spread to every business, industry and country on the planet over the past 100 years.  It’s not just software development, but we’re hardly immune from its effect.

While we’re not immune to the impact, we do have a lot going for us that gives us an advantage in stepping outside this mentality:

• Developers tend to be social oddballs and the normal conventions seem awkward to us. Social oddballs tend to question things.  We don’t like what everyone else likes because, well, we’re nerds and we don’t think like sales people.  Or accountants.  Or athletes.  We’re willing to try things others find weird because we’re weird too.
• Because we’re odd, we tend to be forward thinking and revolutionary in our approaches to workplace advancements. Think about the good aspects of the Dot Com era:  pets in the workplace, recreation rooms with pool tables and ping pong, better chairs and desks for people, free lunches.  Those innovations didn’t come out of Pepsi, Toyota, or Price Waterhouse Coopers, they came out of tech companies.  Every one.
• In doing so, our weird becomes the new normal. Witness the output of the Dot Com era:  Aside from the economic meltdown, how many companies now regularly practice some, if not all of those things we did back in the late 90s?  (Albeit with more restraint, thankfully)

With that in mind, let’s take Daniel’s idea of the results-oriented work environment (ROWE) forward and create something new for the 21st century.  It focuses on three important ideas, which developers already love and embrace:

1. Autonomy
2. Mastery
3. Purpose

Autonomy: What developer out there doesn’t like to be given the freedom to do their own thing, on their terms, with their preferred hours, using their tools, environment, IDE, language, operating system and favorite t-shirt?  Find me a single developer anywhere that doesn’t crave this kind of freedom and I’ll pay you $10.  Seriously.  Drop me a contact above.  I’m good for it.  Of course, you’ll search for the rest of your life and won’t be able to do it.

Mastery: Every developer on the planet wants to get better at what they do.  We crave new knowledge like some people quaff coffee after a hangover.  Fortunately, the side effects of getting better at development are far more benign than caffeine binging.

Purpose: Nothing is more tedious, horrific, or uninspiring to developers to work on projects that lack any real meaning in the world.  Or lack any real direction.  Or lack any substantial need from the company.  In fact, you can probably point to the brightest points of your career all stemming from those projects that had the deepest meaning to you personally.  Maybe the darkest points are those soul-sucking projects that you waded through because you were glad to have a job but desperately waited for things to improve so you could find a better job elsewhere.  Preferably where soul-vacuums didn’t exist.

Google gets it:  They already advocate the 20% time concept and (near-)complete workplace freedom.  Atlassian gets it:  They have the Fedex challenge where everyone in the company gets 24 hours to work on something they are interested in, with the caveat you have to deliver it at the end of 24 hours and you must present it to the company.  Think those don’t create passion for the company?  How about the Nine Things Developers Want More than Money?  These points all touch on the same three basic concepts:  autonomy, mastery, and purpose.

Does your company “get it”?  If the answer is NO,  what can you do right now to change your workplace to “get it”? And if that is too Sisyphean a task for you, how about starting your own company instead, that does “get it”?

That’s my challenge for you in 2010.  “Make software suck less in the 21st century”

Good luck.

No related posts.

I’ve mentioned a number of software laws in various posts, like Cargill’s Ninety Nine Rule, or Occam’s Razor.  And there are tons of laws that you probably already know, like Metcalfe’s Law or Moore’s Law.

I’ve found a very complete list of the laws regarding software development (I highly recommend reading that link. I’ll wait, go ahead).  But from that list, we seem to have developed a complete blind spot for five in particular.  Let’s look at these five and how our collective ignorance of them continues to impact software development today:

Law #1: Amdahl’s Law

Gene Amdahl first published this notion in a 1967 paper.  This law is about the mistaken notion that “All We Need Are More Parallel Processors and Our Software Will Run Faster”.

The Damning Evidence: Pop quiz:  have you bought a new machine in the past 4 years that was multi-core?  Were you a little disappointed when you checked the processor usage and found that not every one of those shiny, new cores was busy all the time, no matter which of your apps you ran?

We buy new hardware with the mistaken impression that our old programs will continue to run even faster than before because we expect our software to take advantage of all those friggin cores!  But software never runs as fast we expect it to on the multi-core hardware, because the parallel component of the program is often missing, underdeveloped, or poorly understood by the developer. Thus, our software continues to disappoint us on even on shiny, new multi-core hardware.

Exceptions: Some applications have been expressly written to be massively parallel and they continue to kick ass and take names on new multi-core hardware (e.g. rendering, scientific and encoding applications).  By and large, most applications simply don’t benefit from those extra cores because they weren’t written to do so.

Law #2:  The Law of False Alerts

First introduced by George Spafford in this article, the law states that the more the user is presented with false or erroneous alerts, the more they will ignore real alerts in the system.

The Damning Evidence: Windows Vista is the classic current example.  Every bloody operation in it required your permission from the user authentication module.  After while, you just madly clicked “Yeah, sure whatever…” for every warning that popped up.  This, of course, robs the operating system of any ability to protect you from a real threat because you’ve been annoyed by the feature in the first place.

Of course, people still design applications like this:

• “Are you sure you want to delete?”
• “No, really, are you REALLY sure you want to delete?”.
• “OK, look, I’ve asked already but just so I can’t be blamed for anything, are you SUPER-DUPER-ABSOLUTELY, 110% sure you want to delete?”

Stop the insanity.  If they click delete and they weren’t supposed to, how about offering an undo operation?  Too hard you say?  Then you’re not trying hard enough.  Don’t punish the users for bad design.

Law #3:  Jakob’s Law of Internet Experience

From Jakob Nielsen, web usability guru, who states that users only spend a small fraction of time on your site, compared to all other sites.  Therefore, your site experience should be similar to all other sites to minimize learning curve and maximize usability.

The Damning Evidence: Well, things like Firefox Personas aside, which distract your users from the actual content of the sites, we still can’t seem to come up with a consistent way to develop user interfaces on sites.  Thanks to Web 2.0, everyone is now trying to copy the success of sites like Facebook, Twitter, and other social networks to create wild, experimental web pages that are just plain awful to use.

Don’t get me wrong here:  I’m not saying different is bad, I’m saying that different is hard to get right.  Users (especially “Normals”) don’t like to be made to think how to use things.  But that doesn’t seem to stop us creating web pages with crazy stuff on them.

Exceptions: Sometimes, user interfaces are giant evolutionary steps that simply lie outside the normal boundaries we’ve come to expect and that’s acceptable.  The iPhone was a perfect example:  no one really had mastered the touch interface until Cupertino & Co came out with it and they didn’t exactly follow any of the old school rules.  But it was still a major success and now sets the standard for all smartphones.  However, most everyone else thinks they’re creating the exception when they’re just breaking the rules poorly.

Law #4:  The Pesticide Paradox

Attributed to Bruce Beiser, the law states that every method you use to prevent or find bugs leaves a residue of subtler bugs against which those methods are ineffectual.

The Damning Evidence: Things like Test Driven Development and Unit Testing give us the false impression that we’ve quashed the major bugs in the system when all we’ve really done is quash the obvious bugs, leaving the more subtle, painful, and difficult ones behind.  Many of these types of bugs are related to concurrency or particular complex data conditions that are difficult to express as unit tests.

Before anyone rants about this comment section claiming I think TDD is bad, or unit testing is evil, please hear me correctly:  Unit testing and TDD leave a false sense of security that we’ve managed to create stable software. They are a starting point to more complete testing, but they are not the end.  The meaningful problems are often in integration with other systems and modules, that are often left out of testing plans because of time constraints, schedule pressures, laziness and sometimes plain arrogance.

Exceptions: Small, simpler systems rarely suffer from these issues because testing is much easier.  This is mostly a complex software problem, at a level of enterprise development, large applications (e.g. Microsoft Word), or operating systems.

Law #5:  Fisher’s Fundamental Theorem of Natural Selection

While this law stems from genetic research by R.A. Fisher, the application in software is somewhat obvious:  The more highly adapted an organism becomes, the less adaptable it is to any new change.

The Damning Evidence: We strive to create complex, interesting, and highly useful frameworks:  Hibernate, Struts, Flex, ExtJS, and jQuery to name a few.  But every version we release generates new requests by the users for missing features or enhancements.  Each change adds more complexity.  And the more complex the software, the lower the chance those changes can be easily accommodated in subsequent versions.

For example, Struts went through a major rewrite for version 2.0, which speaks volumes about the original version’s adaptability to change.  Spring did a major update for AOP that was a breaking change from 1.0.  ExtJS did the same for their 1.0 and 2.0 releases.

Exceptions:  Probably none–this seems to be the inherent nature of frameworks.  But if you know of something, please prove me wrong in the comment section.  I’d love to hear about some piece of software that didn’t follow this rule.

No related posts.