Matt Aimonetti has a client that believes Rubyists don't scale. Sorry Matt, your client is wrong.
It's as easy to hire great Ruby programmers as it is to hire great Java programmers or great programmers for any given popular language.
The problem is, it's not easy to hire great programmers in any language. Worse, companies still think they need to hire one or two great programmers and a supporting cast of average programmers. As Martin Fowler pointed out, cheaper developers are actually more expensive than experts. To make things worse, if you end up with a NNPP or two you'll be headed in the wrong direction.
As I've said before, 50% of all programmers need to find a new profession. In the short term this will create a much larger demand for developers, and salaries will rise. However, since one expert programmer produces significantly more (up to 28 times more) than two terrible programmers, companies will ultimately save money. It's unlikely that salaries of experts will rise to the sum of 28 terrible programmer's salaries.
Some people believe that the average programmers are valuable because they do the jobs the experts don't feel like doing. This is simply wrong. Average programmers will do average jobs on mundane tasks, which often turns into a mess for expert programmers to fix. Even if the solution proposed by average programmers doesn't require an entire rewrite, it is often sub-optimal and can have implications with other pieces of software that rely on it.
There's a better way. Give mundane tasks to expert programmers. Expert programmers remove or automate mundane tasks. The solutions will be superior, and either way the experts won't be doing mundane tasks.
If you have great programmers producing up to 28 times more, and you only hire great programmers, how many programmers do you think you need? Of course the answer depends on how much software needs to be written, but in general teams can become a lot smaller.
And this is the problem with Matt's client's statement. While they may not be able to easily build a team of average Ruby developers, it doesn't matter, that's the wrong goal. Of course, I have no way of knowing the caliber they were looking to hire. But, I do know if they wanted Ruby experts that will travel, ThoughtWorks employs several. So, I'm left to guess that they fell into the same old misguided pattern of trying to pay average salaries to average developers.
I'm left wondering why they would take expert advice on what technology to use, hire an expert, achieve success and then stop pursuing experts. Of course, I'm not surprised. As a consultant, I saw it time and time again.
The question isn't whether you can hire rubyists or not, it's whether or not you are willing to put the effort in to hire experts. It isn't easy to hire experts regardless of the language, but it is worth it.
Thursday, August 28, 2008
Monday, August 25, 2008
Lean Software Development
While working in London for TrafficBroker I had the opportunity to try out Fred George's Lean process. To date, it's absolutely my favorite way to deliver software.
Stories
Stories truly are placeholders for a conversation. They are short sentences such as "The system should process pending orders when inventory is available". If you want to work on the story you (and your pair) go find the business person who wants the feature and you talk to them until you understand what needs to be built. Once you know what you need to do, you create tasks.
Stories are estimated using the techniques I detailed on InfoQ.
Tasks
Tasks are the technical tasks that need to be completed to finish the story. They are written on a sticky and attached to the story on the wall. When a task is finished you put a green dot on the sticky. At any time you can see what stories are being worked on, how many tasks are associated with the story and how many have been completed so far.
Retrospectives
Even though we never felt like we needed a retrospective we got on a schedule of doing them every two weeks. I walked into every one thinking it was unnecessary, and walked out thinking it was critical that it happened. Great retrospectives really make a world of difference.
We all put stickies on the wall in the "not so well" or "well" columns, then we talk about each one. Everyone gets the opportunity to elaborate on their sticky. The common themes become action items.
Showcases
We also had weekly showcases to demo new functionality for anyone who was interested. In the showcase we also used a burndown chart to show progress. We only estimated the stories that were necessary for the next version or release, so the burndown chart was often a short term picture. Of course, any further detail would be greatly unreliable anyway. The burndown numbers are based on taking the sum of the estimates and applying the velocity, based on a weekly velocity total.
Story Wall
We also used a story wall to track progress. The stories moved from Definition -> Awaiting Development -> In Development -> in QA -> Awaiting Business Acceptance -> Complete. The stories in Awaiting Development are ordered from top down by priority. The business could come over at any time and reorder based on priority.
Waste Removal
I loved the process because we constantly removed waste (effort for zero value items). We didn't need to commit to points per iteration because it didn't gain us anything. We didn't bother tracking actuals, hours, or anything else that wasn't important. We also didn't discuss or estimate anything that wasn't in the next release. We only did what was necessary, and we delivered faster than I've ever delivered before. Every detail is judged by it's ROI.
Conclusion
I'm a huge fan. Context is king and it might not work for you based on your constraints, but it's definitely worth considering some if not all of the ideas.
Stories
Stories truly are placeholders for a conversation. They are short sentences such as "The system should process pending orders when inventory is available". If you want to work on the story you (and your pair) go find the business person who wants the feature and you talk to them until you understand what needs to be built. Once you know what you need to do, you create tasks.
Stories are estimated using the techniques I detailed on InfoQ.
Tasks
Tasks are the technical tasks that need to be completed to finish the story. They are written on a sticky and attached to the story on the wall. When a task is finished you put a green dot on the sticky. At any time you can see what stories are being worked on, how many tasks are associated with the story and how many have been completed so far.
Retrospectives
Even though we never felt like we needed a retrospective we got on a schedule of doing them every two weeks. I walked into every one thinking it was unnecessary, and walked out thinking it was critical that it happened. Great retrospectives really make a world of difference.
We all put stickies on the wall in the "not so well" or "well" columns, then we talk about each one. Everyone gets the opportunity to elaborate on their sticky. The common themes become action items.
Showcases
We also had weekly showcases to demo new functionality for anyone who was interested. In the showcase we also used a burndown chart to show progress. We only estimated the stories that were necessary for the next version or release, so the burndown chart was often a short term picture. Of course, any further detail would be greatly unreliable anyway. The burndown numbers are based on taking the sum of the estimates and applying the velocity, based on a weekly velocity total.
Story Wall
We also used a story wall to track progress. The stories moved from Definition -> Awaiting Development -> In Development -> in QA -> Awaiting Business Acceptance -> Complete. The stories in Awaiting Development are ordered from top down by priority. The business could come over at any time and reorder based on priority.
Waste Removal
I loved the process because we constantly removed waste (effort for zero value items). We didn't need to commit to points per iteration because it didn't gain us anything. We didn't bother tracking actuals, hours, or anything else that wasn't important. We also didn't discuss or estimate anything that wasn't in the next release. We only did what was necessary, and we delivered faster than I've ever delivered before. Every detail is judged by it's ROI.
Conclusion
I'm a huge fan. Context is king and it might not work for you based on your constraints, but it's definitely worth considering some if not all of the ideas.
Thursday, August 07, 2008
Be Your Start-Up
It's impossible not to ponder striking it rich at a start up, but there's another alternative if you're looking to make some good money -- build your brand.
In January of 2005 I created a blog. I truly can't remember why I created it, but I do remember that I was making $60,000 a year. Then in February I joined ThoughtWorks and my blog became part of blogs.thoughtworks.com. I had instant readership, but not a lot to say.
Two and a half years and a lot of blog posts later I turned down an offer that was $174,000 a year. This wasn't $174,000 a year because the work sucks. It was a good job, but I wasn't ready to leave ThoughtWorks. It's been a year since then, and I know it was the right decision.
Now, I didn't make millions, but tripling your salary in two and a half years is still quite nice. There's no question that my brand was responsible for my ever increasing salary requirements. In fact, when I was interviewing two of the three interviewers started their interviews with "I read your material, you've got exactly what we need here. So why don't you ask me the questions instead". My brand had already gotten me the job.
Building a brand isn't as hard as you might think. There's really only 3 things you need to focus on.
But, before you do those three things, you'll need to read two books that will give you the proper guidance.note: both books are required reading whether you are building a brand or not.
Once you have the requisite reading covered it's time to make your mark.
Writing
Writing isn't hard. Writing well is hard, but you're a programmer, so you needn't worry about that. No one expects you to be a good writer, they're happy if you are, but they're forgiving if you're not. Don't use your poor writing skills as an excuse not to write.
Don't know what to write about? The answers are all around you. Anything you do that's interesting, there's 100 people searching Google for how to do it. Any question a colleague asks you, someone is searching Google for the same answer. Anything that's valuable to you... yes, someone is googling for it.
Take the time to write the answer in a blog entry. People will remember if your blog consistently shows up in their Google searches.
Create a blog. Blogger is free and definitely good enough. Here's a few thoughts on blogging.
Presenting
Of the 3 things you need to do, I think presenting is the hardest to get going with. You aren't likely to pick up a speaking spot at a good conference if no one has heard of you. So, you'll need to rely on your writing to build your brand a bit, then you can present on the topics that you write about. Alternatively, if you create some open source software that generates buzz you can also pick up a few speaking engagements. Getting started is the hardest part, but once you give a few good talks you'll quickly be turning things down because you just can't fit it in your schedule.
If you're serious about speaking I also highly recommend SpeakEasy. I spent two and a half miserable days at SpeakEasy learning how bad I was at public speaking. The experience was priceless. I can't say enough good things about what I learned in those two and a half days.
Contributing
The last suggestion is the easiest. Contribute some open source software. There's so many ways to contribute.
Oh, and don't submit patches as disco_stus_brother. You're name is your brand, use it.
In January of 2005 I created a blog. I truly can't remember why I created it, but I do remember that I was making $60,000 a year. Then in February I joined ThoughtWorks and my blog became part of blogs.thoughtworks.com. I had instant readership, but not a lot to say.
Two and a half years and a lot of blog posts later I turned down an offer that was $174,000 a year. This wasn't $174,000 a year because the work sucks. It was a good job, but I wasn't ready to leave ThoughtWorks. It's been a year since then, and I know it was the right decision.
Now, I didn't make millions, but tripling your salary in two and a half years is still quite nice. There's no question that my brand was responsible for my ever increasing salary requirements. In fact, when I was interviewing two of the three interviewers started their interviews with "I read your material, you've got exactly what we need here. So why don't you ask me the questions instead". My brand had already gotten me the job.
Building a brand isn't as hard as you might think. There's really only 3 things you need to focus on.
- Writing
- Presenting
- Contributing
But, before you do those three things, you'll need to read two books that will give you the proper guidance.note: both books are required reading whether you are building a brand or not.
Once you have the requisite reading covered it's time to make your mark.
Writing
Writing isn't hard. Writing well is hard, but you're a programmer, so you needn't worry about that. No one expects you to be a good writer, they're happy if you are, but they're forgiving if you're not. Don't use your poor writing skills as an excuse not to write.
Don't know what to write about? The answers are all around you. Anything you do that's interesting, there's 100 people searching Google for how to do it. Any question a colleague asks you, someone is searching Google for the same answer. Anything that's valuable to you... yes, someone is googling for it.
Take the time to write the answer in a blog entry. People will remember if your blog consistently shows up in their Google searches.
Create a blog. Blogger is free and definitely good enough. Here's a few thoughts on blogging.
- Don't roll your own, you don't need the maintenance headache.
- Name it something simple, but be sure to include your name. Disco Stu's Ramblings is funny, but you want to build your brand, not Disco Stu's.
- Buy your name as a domain and put the blog as a directory (I didn't do this correctly). If I had it to do over my blog would be at http://jayfields.com/blog. This is important for Google Page Rank. If you do it the way I did you'll have different page rank for your homepage and your blog. Not the end of the world, but not ideal.
- Keep it focused. If you want to write about programming and gambling, create two different blogs. Also, avoid "Sorry I haven't written in awhile" posts. People aren't dying for your next post. They're subscribed because they want technical content, not stories about how you've been busy remodeling your home.
- Keep blog posts short if possible. Anything over 1500 words is article material. If you can't find somewhere to publish the article, then your blog is fine. But, remember that people don't like reading long blog entries (like this one)
Presenting
Of the 3 things you need to do, I think presenting is the hardest to get going with. You aren't likely to pick up a speaking spot at a good conference if no one has heard of you. So, you'll need to rely on your writing to build your brand a bit, then you can present on the topics that you write about. Alternatively, if you create some open source software that generates buzz you can also pick up a few speaking engagements. Getting started is the hardest part, but once you give a few good talks you'll quickly be turning things down because you just can't fit it in your schedule.
If you're serious about speaking I also highly recommend SpeakEasy. I spent two and a half miserable days at SpeakEasy learning how bad I was at public speaking. The experience was priceless. I can't say enough good things about what I learned in those two and a half days.
Contributing
The last suggestion is the easiest. Contribute some open source software. There's so many ways to contribute.
- Pick an existing project that you use and create a patch for an outstanding bug.
- Extract something interesting from your codebase and release it as open source. You don't need millions of adopters. If you create something valuable to 20 people you'll gain 20 people advocating your brand.
- Be the documentation guy. Almost all open source software suffers from poor documentation. Make it your speciality. You'll quickly make friends if you do the work others don't feel like doing.
- Join a mailing list for your favorite open source project and be active. Be the guy that's always willing to help the recent adopters.
Oh, and don't submit patches as disco_stus_brother. You're name is your brand, use it.
Wednesday, August 06, 2008
Elitist or Optimist
The last few entries have focused more on the industry and leadership than usual. You might find that odd, but the reality is, I write about what I'm doing. When I'm coding in Ruby, you get Ruby entries. When I'm coding in Flex, you get Flex entries. Lately, I've spent more time shaping teams, processes, and individuals -- thus the posts of that nature.
A Scotch Drinker feels I've become Elitist.
I like scotch and scotch drinkers in general, so I gave his/hers entry some thought. You should read the entry if you care, I'm not going to summarize it. But, here's a few quick responses.
I think the difference is, I'm not saying we should fire all but a select group or that a select group should run the show. I'm suggesting that the current minimum requirements for being a programmer are disappointingly low and the products that those programmers produce are often terrible.
If you prefer, here's a more politically correct assertion: Any Net Negative Producing Programmer (NNPP) should find a new profession.
Removing the NNPPs doesn't mean that 50% of your colleagues should move on. My last client, TrafficBroker, didn't employ a single programmer that couldn't pass my requirements. They have no need to get rid of anyone. Conversely, my last full time job before ThoughtWorks was staffed with about 80% NNPPs. You're ratio will probably vary, 50% is based on working for ~10 different companies in the last 5 years and discussing my experiences with many friends from ThougthWorks.
As Josh Graham already pointed out, I'm not the first to say this. Yet, I still feel like it's worth brining up. I knew it would generate responses such as the one from scotch drinker, but it's worth taking some criticism. I hope my entry inspires a few more people to be more vocal with the unacceptable state of certain things in our industry.
As an industry we can do better. Every NNPP that finds a new profession helps our industry improve. I'm not looking for a software development elite community. I'm looking for a productive community. That's why my blog posts and presentations range drastically from very beginner to very advanced. I'll write anything that I think is helpful. But, NNPPs are uninterested or unable to improve, and I can't help them.
I'm not elitist, I'm a silly optimist that thinks a simple blog entry can help change an industry.
A Scotch Drinker feels I've become Elitist.
I like scotch and scotch drinkers in general, so I gave his/hers entry some thought. You should read the entry if you care, I'm not going to summarize it. But, here's a few quick responses.
- There's no question that I wouldn't have reached my position so quickly if the competition wasn't so weak. That's not a good thing.
- I dropped out of college, to say that I'm implying formal education is required is amusing. In fact, no where in my list of things I look for in a colleague do I mention education. I want talented colleagues, nothing more, nothing less.
- There are plenty of crappy jobs. You know what happens to them when you give them to good developers, they get automated or removed. Giving crappy jobs to crappy programmers is an answer, but not the best one.
Elitism is the belief or attitude that those individuals who are considered members of the elite — a select group of people with outstanding personal abilities, intellect, wealth, specialized training or experience, or other distinctive attributes — are those whose views on a matter are to be taken the most seriously or carry the most weight... -- WikipediaI can see where the scotch drinker is coming from. My minimum set of requirements might seem like I'm describing the elite. On the other hand, they might just be a good set of minimum requirements.
I think the difference is, I'm not saying we should fire all but a select group or that a select group should run the show. I'm suggesting that the current minimum requirements for being a programmer are disappointingly low and the products that those programmers produce are often terrible.
If you prefer, here's a more politically correct assertion: Any Net Negative Producing Programmer (NNPP) should find a new profession.
Removing the NNPPs doesn't mean that 50% of your colleagues should move on. My last client, TrafficBroker, didn't employ a single programmer that couldn't pass my requirements. They have no need to get rid of anyone. Conversely, my last full time job before ThoughtWorks was staffed with about 80% NNPPs. You're ratio will probably vary, 50% is based on working for ~10 different companies in the last 5 years and discussing my experiences with many friends from ThougthWorks.
As Josh Graham already pointed out, I'm not the first to say this. Yet, I still feel like it's worth brining up. I knew it would generate responses such as the one from scotch drinker, but it's worth taking some criticism. I hope my entry inspires a few more people to be more vocal with the unacceptable state of certain things in our industry.
As an industry we can do better. Every NNPP that finds a new profession helps our industry improve. I'm not looking for a software development elite community. I'm looking for a productive community. That's why my blog posts and presentations range drastically from very beginner to very advanced. I'll write anything that I think is helpful. But, NNPPs are uninterested or unable to improve, and I can't help them.
I'm not elitist, I'm a silly optimist that thinks a simple blog entry can help change an industry.
Tuesday, August 05, 2008
The Elephant in the Server Room
50% of all people doing business software development should find a new profession.
The dotcom bubble brought us so many bad colleagues. A friend of mine once told me: In 97 he moved from France to the Valley. He basically spoke no English, and was immediately offered several positions as team lead. He couldn't understand their questions and he couldn't articulate answers. It didn't matter; they offered him the job based on his resume and his ability to draw UML diagrams.
There are more interesting stories that may or may not be true, but my friend's experience best summarizes the time for me. If you had a good looking resume (true or not) and you showed any sign of knowledge, you were hired.
Even after the bubble burst, technologists have enjoyed almost constant demand. In 1999 (when I took my first programming job) I was only making ~$20,000 a year. By 2001 I was making ~$45,000, and ~$60,000 in 2003. During the "tough" years I was enjoying ~20% raises annually. I was very junior in those days, but the average programmer was so bad that I looked like a natural team lead.
My salary history is only anecdotal evidence, but I've heard similar stories from other friends enough times to be entirely comfortable with the assertion that any decent programmer was rarely out of work and was often overpaid.
Not everyone was making bad decisions in those days. My two favorite managers from those days didn't even want to hire me. They had candidates ahead of me, but those candidates were getting even more ridiculous offers elsewhere. I took the jobs the better candidates didn't want and worked my way up. I was junior, but I had desire and ability. Those managers wanted the best, but they had to settle for what I was bringing to the table. If I was junior and commanding decent salaries, imagine what the good guys were getting paid.
Luckily, everywhere I went there were a few people who were senior, smart, and willing to help out an aspiring team member. They were the team members who took all the hard work and always delivered early. The Hero Coders of those days.
There were definitely smart managers and smart developers back then, but they were (and are still) the minority.
Now, "those days" are over and technologists are in higher demand than ever. I don't think we got rid of many of the dotcom bubble bad apples, and now we're bringing in a whole new batch of terrible software developers.
The situation is worsened by the immaturity of our profession. Who really knows how to deliver software efficiently? Martin Fowler, Joel on Software, Kent Beck, Zed Shaw? I know who's practices I prefer, but it would be quite naive to ignore the possibility that I've been led down the wrong path.
Teams are generally built around shared practices, so if you pick the wrong practices chances are you are on the wrong team. If the entire team is doing something wrong, who could tell the manager? Who would even know? Realistically, the team would carry on under-delivering until someone with another perspective enters the picture. But, there's no guarantee that the newcomer is correct either.
If we cant be sure what the best practices are, how would we know who to fire? It's tough to say, but I have a few things that I look for in co-workers.
Do you pass the test?
Software will be delivered even if the situation stays the same, but shaking things up could deliver faster, cheaper, and better software. And, that world is a better place to live.
The dotcom bubble brought us so many bad colleagues. A friend of mine once told me: In 97 he moved from France to the Valley. He basically spoke no English, and was immediately offered several positions as team lead. He couldn't understand their questions and he couldn't articulate answers. It didn't matter; they offered him the job based on his resume and his ability to draw UML diagrams.
There are more interesting stories that may or may not be true, but my friend's experience best summarizes the time for me. If you had a good looking resume (true or not) and you showed any sign of knowledge, you were hired.
Even after the bubble burst, technologists have enjoyed almost constant demand. In 1999 (when I took my first programming job) I was only making ~$20,000 a year. By 2001 I was making ~$45,000, and ~$60,000 in 2003. During the "tough" years I was enjoying ~20% raises annually. I was very junior in those days, but the average programmer was so bad that I looked like a natural team lead.
My salary history is only anecdotal evidence, but I've heard similar stories from other friends enough times to be entirely comfortable with the assertion that any decent programmer was rarely out of work and was often overpaid.
Not everyone was making bad decisions in those days. My two favorite managers from those days didn't even want to hire me. They had candidates ahead of me, but those candidates were getting even more ridiculous offers elsewhere. I took the jobs the better candidates didn't want and worked my way up. I was junior, but I had desire and ability. Those managers wanted the best, but they had to settle for what I was bringing to the table. If I was junior and commanding decent salaries, imagine what the good guys were getting paid.
Luckily, everywhere I went there were a few people who were senior, smart, and willing to help out an aspiring team member. They were the team members who took all the hard work and always delivered early. The Hero Coders of those days.
There were definitely smart managers and smart developers back then, but they were (and are still) the minority.
Now, "those days" are over and technologists are in higher demand than ever. I don't think we got rid of many of the dotcom bubble bad apples, and now we're bringing in a whole new batch of terrible software developers.
The situation is worsened by the immaturity of our profession. Who really knows how to deliver software efficiently? Martin Fowler, Joel on Software, Kent Beck, Zed Shaw? I know who's practices I prefer, but it would be quite naive to ignore the possibility that I've been led down the wrong path.
Teams are generally built around shared practices, so if you pick the wrong practices chances are you are on the wrong team. If the entire team is doing something wrong, who could tell the manager? Who would even know? Realistically, the team would carry on under-delivering until someone with another perspective enters the picture. But, there's no guarantee that the newcomer is correct either.
If we cant be sure what the best practices are, how would we know who to fire? It's tough to say, but I have a few things that I look for in co-workers.
- Attention to Quality
- The Desire to Improve
- The Ability to Adapt
- Strong Collaboration Skills
Do you pass the test?
- Have you tried Test Driven Development? Can you name something you liked and something you disliked?
- What language(s) that are gaining popularity, but not yet mainstream, have you written Hello World in?
- Do you read books or blogs looking for new ideas at least (on average) once every two weeks?
- Do you at least attempt to learn a new language every year?
- If you don't understand a requirement, do you IM, phone, or go talk to the business?
- Have you ever run a code coverage or cyclomatic complexity tool against your codebase?
- and so on...
- You're junior and could use a good mentor
- Or, it's time to find a new profession.
Software will be delivered even if the situation stays the same, but shaking things up could deliver faster, cheaper, and better software. And, that world is a better place to live.
Subscribe to:
Posts (Atom)