A couple of days ago I was sent a link to Robert Cringely’s latest treatise: The second coming of Java – and to say I disagreed was a bit of an understatement. To me, it represents a fundamental flaw in his perception of developers, and more importantly the economics of software development.
The key to Cringely’s argument comes down to this:
When SSDs gain enough capacity there will be a shift from the Ruby world back to the Java world. Not for prototyping, because, well, it’s prototyping. But simply because the statement “Ruby is incredibly slow but I don’t care because my database is slower” will no longer be true.
What he’s missing here is the real reason people use frameworks like Rails; it’s not about it being Ruby, or being the latest cool thing – it’s about developer productivity. That’s it, and that’s all there is to it – Rails allows a developer to do more in less time. That’s one of the key reasons so many Java web developers jumped ship (though I can think of a few others), and what pushed Microsoft to invest so heavily in their MVC framework.
I could fully rehash the argument, but in what I consider to be one of Jeff Atwood’s best articles, Hardware is Cheap, Programmers are Expensive, he covers a key point to my argument – developer time is vastly more expensive than hardware. Atwood’s take on the issue is clear:
Clearly, hardware is cheap, and programmers are expensive. Whenever you’re provided an opportunity to leverage that imbalance, it would be incredibly foolish not to.
When there’s a choice between developer productivity, and spending money on hardware – the conclusion should be the same. It’s much cheaper to throw more hardware at a slower framework than it is to invest more developer time in a faster framework. For any non-trivial application, throwing more front-end servers at it will always be cheaper than slowing the development process down with a non-productivity-centric toolkit.
It’s simple economics; server hardware is getting faster and cheaper, developer time is only getting more expensive.
While looking at the reactions to Microsoft’s acquisition of Skype, I found one tweet that really stood out:
@knowtheory
Ted HanHow you know you have a PR problem: As soon as you buy popular service X, their userbase starts posting alternatives #skype#Microsoft
FavoriteRetweet
While many users are busy joking about names (personally my money is on “Microsoft Live Skype” – my only hope is that there isn’t an “Ultimate Edition” or “Unicorn Edition” tacked to the end of the name) Microsoft has a significant problem, and I really hope they are looking at public reaction. Users are concerned; what will Microsoft do to the brand, and how will the brand and service change – users need to be reassured that what they love about the service won’t go away.
I use Skype on a daily basis, and for me this brings back memories of AOL’s failed acquisition of Nullsoft (the maker of WinAmp) in 1999, which took a great piece of software and a well-respected brand, and rendered it little better than RealPlayer (and don’t get me started on the Netscape acquisition). I can see this easily going down the same path; as the brand is diluted and merged with others to help boost their marketing goals, and the software is integrated tightly with other products (creating that tight, but invasive feel that the EU had so many issue with when they did it with IE); they could easily find themselves in the same position that eBay did back in 2007.
Microsoft desperately needs to build their online brand to recover the billions that they are losing, and I have to assume they see Skype as a key player in this quest; the question is can the keep their newly acquired user-base from jumping ship.
I don’t think Skype will live or die on technology at this point, I think PR is a far larger issue for them right now.
For those outside of the IT field, developers are looked at as miracle workers – through us, business leaders think anything is possible (and they often see no reason why we can’t work our latest miracle by the next morning). In reality though, we do work miracles; we save companies vast amounts of money every year through increased worker efficiency and automation, we enable new lines of business that wouldn’t be possible otherwise, and reduce energy costs because we keep the office lights turned off. Well, that’s more or less how they see us.
But for all of the wonders we are responsible for, there is one thing we can’t do (no matter what amazing powers some executives think we have to make them look better or earn them more bonuses):
You can’t fix stupid.
I’ve often described development as being a professional problem solver, and we are often tasked with rather challenging problems to solve. Sometimes the problems are purely technical – making something new possible that previously was impracticable or even impossible, sometimes it’s all about efficiency, other times it’s about image and controlling how people see a company. When the problem is the user though, you know you’re in for a rough day.
I was recently given such a task – the users weren’t listening to their supervisors and they wanted the software to force these users to do whatever it was that management told them they should be doing. I was given less than a week to find ways to make people that don’t want to work, work.
Basically, users fall into three simple categories:
- Power Users – these users understand software, and require little, if any instruction – more than anything, you give these users a tool and stay out of their way.
- Average Users – odds are, your mother or father falls into this category. They understand enough to get by, and with a little instruction they should have no trouble.
- Idiots* – odds are, you work with one of these users. You lead them by they hand, and show them exactly what to do – just in time for the boss to walk by and praise them for doing a good job (and 10 minutes later you find them playing in traffic, somehow defying Darwin in the process).
For users of the last category, there’s just not much you can do.
I always do my due diligence while building software; doing all I can to make it simple to use, flexible, and forgiving of user error. I always use extensive data validation, carefully worded instructions and dialogs, and do my best to follow the various best-practice guides for UI and UX; yet for all this effort and design – I can’t write software that thinks for people or makes judgement calls based on business rules that only they know (probably because they make it up as they go).
No matter how helpful or intelligent an application is, or how idiot-proof you think you’ve made it, reality is that you simply can’t fix stupid – you can’t take an incompetent person that refuses to think for themselves and turn them to into a great, productive asset. After years in this industry (which has made me just a little cynical [in the way that Sol only seems little when compared to Betelgeuse]), I’ve come to understand something rather disturbing: idiots keep getting better.
Somewhere, right now, idiots are working to build even better idiots – and that’s a really scary thought.
We can make a user more efficient by automating tasks, providing better information, or helping to manage their workload – what we can’t do is make them smarter, make them think through their actions, or force them to do what their managers tell them. Yet we are, at least on occasion, asked to fix this problem.
Despite our best efforts as professionals and passionate developers; if a user won’t think – we just can’t fix it.
* – I define an idiot about the same way I do someone that’s lazy; they have no medical issues or legitimate handicap. They just don’t want to think or work (probably both). Those that are handicap or have learning or medical issues are a very different story and not the target of this article; I donated time and services to charities that served the disabled for a number of years, I highly recommend that all developers do it – it’s a very rewarding experience to see your work make somebody’s life better and it teaches you quite a bit about how people interact with technology.
On March 11, 2011, Twitter said goodbye to some of it’s most loyal and passionate users.
In a message on their Development Talk group entitled “consistency and ecosystem opportunities” – they make their position clear: we no longer need you. To demonstrate this, let me point out a couple quotes that deserve attention:
Twitter will provide the primary mainstream consumer client experience on phones, computers, and other devices by which millions of people access Twitter content (tweets, trends, profiles, etc.), and send tweets.
and this gem:
More specifically, developers ask us if they should build client apps that mimic or reproduce the mainstream Twitter consumer client experience. The answer is no.
Independent, 3rd-party developers have driven the progression of Twitter from an extremely simplistic group SMS service, to a massive and near ubiquitous communications system used by millions of people. As Twitter fought whales and struggled to keep servers running, outside developers were busy building new and better ways of using the service; now that Twitter has gone mainstream and is doubtlessly looking at revenue options, they’ve told these passionate users that they are no longer needed. The users that evangelized the service, and promoted it in countless ways, suffering through long stretches of downtime remained loyal and energized, pushing the service to become ever more. Twitter, it seems, has no such loyalty to these champions and flag bearers of the service.
If you want to build an application in the Twitter ecosystem now, you are pushed to the outskirts; building integration as a feature of a separate system (such as instagram), or building for vertical markets which by definition have a far more limited market potential. This is a dangerous time to be invested in an application that relies too much on Twitter; there’s no telling what or who they will ban next.
Twitter did make it fairly clear that existing applications can “continue to serve your user base” - there was an air of a threat in the statement, and given their willingness to ban a major player, I can’t help but think that they will be looking for chances to kill off other clients, to further solidify their control of what users see.
If you are an existing developer of client apps, you can continue to serve your user base, but we will be holding you to high standards to ensure you do not violate users’ privacy, that you provide consistency in the user experience, and that you rigorously adhere to all areas of our Terms of Service.
At best Twitter has alienated passionate users, at worst they have inspired new competition with the goal of being what many of these users wanted Twitter to become, before they shifted their strategy away from the core service, to controlling and enforcing a sub-par user experience.
A couple weeks ago, Hulu Plus shed its beta tag and opened to the general public. When this happened, the price was changed and a new one week free trial was added. As a subscriber I was happy to hear about the new lower price, though my main concern was wondering if I would have to contact them to get the price break. That concern, thankfully, was the furthest thing from the truth. Soon as the news hit, I found this email waiting for me:
Hi Adam,
Thanks for being a subscriber to Hulu Plus during our preview. We’ve been hard at work refining our existing applications, expanding the device coverage, and extending our content lineup. We’re excited to announce that today, Hulu Plus is officially launching out of preview to anyone in the U.S. for just $7.99/month.
Since we’re now offering Hulu Plus at a lower price than during the preview, your subscription fee has been lowered to $7.99/month, and on your next billing cycle, we’ll also automatically credit your account with $2 for each month you’ve been a subscriber. In addition, we’re now offering a 1-week free trial for all new subscribers, so we’ll be issuing you an additional $2 credit since the free trial wasn’t in place during the preview.
We’d also like to offer you the chance to earn more free time on Hulu Plus by helping us spread the word about the service. For each friend who uses your referral to join Hulu Plus, we’ll give you two additional weeks for free, up to 20 weeks total. Each of your referrals will also receive two weeks free on their first month’s subscription. For more details on the program and to invite your friends, please visit http://www.hulu.com/profile/referrals.
Since the Hulu Plus preview began, we’ve added more TV shows and extended our device coverage. To see which shows are now available on Hulu Plus, please visit http://www.hulu.com/plus/content, and to see the most up-to-date list of supported TVs, Blu-ray players, set-top boxes, mobile phones, and tablets visit http://www.hulu.com/plus/devices.
Thanks for supporting us during the Hulu Plus preview. We look forward to continuing to work on your behalf in the months and years to come.
The Hulu Team
(emphasis added)
This is about the last thing I expected, especially from a company backed by major media players. I would hate to imaging how much this move cost them, but I know it bought them plenty of loyalty; it’s rare to to see companies go out of their way to be fair to customers, and even moreso when it means giving back money they’ve already collected. If you want to win the hearts of your customers, this is the kind of move that does it.
If you change the price on a service or application – how will you current customers feel? Will they feel cheated for being an early adopter? It’s your current customers that will bring in new customers; make sure you take good care of them, and they will take care of you.
The company I work for is hiring several developers which marks my first significant hiring effort since being promoted to management. This had led to a few interesting observations* I would like to share that may benefit both those looking for a new job and those looking for the next star to add to their team.
Immigration Law: I had no idea how complex this area of law gets; it’s a maddening maze of rules and policies that are more effective at confusing those involved than providing a reasonable solution to a problem. If you run into this (and you will), you need somebody that has dealt with this and knows what to do. Getting both parties into legal hot water is far too easy.
Resumes: I’ve seen great resumes that made it clear that I needed to hire this person and resumes so cluttered and complex it took an hour just to get through it. Here’s a few things that stuck out to me:
- DRY is good for code, and for a resume. Clean and concise is always better; if you find yourself hitting Ctrl+C even once while working on a resume, you’re probably doing something wrong.
- Length is important, but shorter isn’t always better. Unlike many other fields where a single page resume is considered optimal, technical resumes need at least a second page. Going too short on a resume is a great way to blend into the crowd; a resume should stand out, and that takes space.
- How long is too long? Unless you’ve been doing this for a very long time, more than three pages is probably excessive. This isn’t always true, but think it through before using more than two pages.
- Use whitespace carefully. Don’t leave a page half empty or pack everything in so that it looks cluttered. As with any type of design, whitespace is a powerful tool that should be used wisely and never be left to chance.
- Use color sparingly. Many corporate printers are black and white only, so if you use color make sure it looks right when printed without it.
- Use bold even more sparingly. It’s sometimes useful to point out items of interest, but it quickly degrades the readability of a resume.
Many people seem to have a hard time with this, but a resume is a textual representation of yourself. It represents you as a person and your accomplishments as a professional. Any errors or signs of haste or carelessness say much about you as a person; if you are careless with such a significant representation of yourself what does it say about your attention to detail or work ethic?
Experience: For a person that has recently graduated, experience in the field is the single largest hindrance both when it comes to securing a position and to receiving a salary they are happy with. The best advice I can find for people in this position is to look to the open source community for help. There are many projects that are desperate for developers and it’s a great way to get familiar with working in a team, coordinating with people over a distributed area, and releasing code for public consumption. In lieu of paid work experience, open source is a great way to fill in a resume (and it can be quite profitable for some, if you play your cards right).
Salary: In some companies pay is a minor issue thanks to clearly structured systems such as that proposed by Joel Spolsky; for others is can be a source of pain, envy, and jealousy. This is a topic that I truly hate; it’s uncomfortable at best and quite painful at worst. While I can’t offer much advice, here are a few things to think about:
- Money is not an effective motivator. In an ideal environment it should just stay out-of-the-way and allow developers to live a comfortable life; in reality the role it plays is a bit different. More often than not, it’s a distraction that gets in the way and outweighs the factors that do motivate people.
- Companies follow a few different pay systems, and once set moving to different system is nearly impossible. Here are a few I’ve seen:
- Clearly Structured: This system places developers on a scale, and developers at a given level receive the same salary (see Fog Creek).
- Structured + Negotiated: This is the most common system I’ve seen; it mixes a structured level system with negotiated modifications that can apply a certain percentage increase from the normal base salary for that level or other benefits (extended vacation, etc).
- Negotiated: Pay is based on negotiation skills and need; this can lead to odd situations such as where a junior developer can make more than a senior developer due to the need to fill a position quickly. This system requires strict secrecy when it comes to salary information to avoid nasty surprises, unlike the clearly structured system where salary information can be openly shared.
- Are large salary increases possible? Some companies have no issue with large increases in salary for a promotion (20%+) while in others exceeding 5% for any reason is a major challenge. If a developer is coming in on the low-end of the scale (i.e. due to lack of experience, such as a recent graduate), is there a real possibility of moving up? In my experience, people stay near the end they start at – those that start at the bottom will stay there until they move to a different company.
Interview Questions: If you are conducing an interview, make a list of questions and write them down. It’s quite embarrassing to suddenly realize that you are out of questions just a few minutes in (Need inspiration? Try this or this). Many people have said much about this, but the most important thing I can point out is just don’t wing it. Plan carefully, make sure you know what you’re going to do and when before the candidate shows up.
Interview Dress Code: I’ve been amazed at what I’ve seen people wear, everything from high-end suits to jeans. What’s appropriate? It really depends on the environment; a large corporation will expect an Armani suit where a startup is happier seeing jeans and an American Apparel t-shirt. When in doubt, I would go with a suit personally – but depending on the company that could cost you the job just as quickly as showing up in jeans.
Interviews Go Both Ways: An interview shouldn’t be a one-way affair; the candidate should be interviewing the company as much as you are interviewing them. They should be asking questions about the environment, expectations, tools and resources provided as much as you are asking them about prior experience and knowledge. If a candidate doesn’t seem to care about the company or what the working conditions are like – think carefully before hiring them.
Other Thoughts: I’ll not go into what I look for when it comes to personality or other personal traits as that would require far more than a blog post to cover. I’m also going to avoid things such as hobbies and the like; while they can tell you much about a person they can also lead to other complications. Any question in an interview can quickly lead to a land-mine and in the legal quagmire that is HR law and policies, trouble is easy to find. When in doubt, just don’t ask.
* This is based on my experience over the years; not necessarily the experiences in this round of hiring or the opinions or policies of my employer. In general, nothing in this refers to policies, preferences, or procedures of my employer. <Standard Disclaimer />
