Tuesday, December 09, 2008
Targeted Languages
The vast majority of actively evolving business software is written in Java these days. Java has long enjoyed the title of One Language to Rule Them All. However, in a previous post, The Next Big Language, I mention that I'm skeptical that there will be one language that is perfect for solving all possible problems in the future.
I might be overestimating the speed at which our profession is maturing. One of the reasons Java became the enterprise standard was because the wrong people were making decisions based on inadequate information and swarms of terrible programmers. I like to believe that we're moving away from those days, but then again, we definitely still have far too many NNPPs that need to be encouraged to find other employment. However, I do think it's inevitable that we move to languages targeted at specific domains and problems eventually.
We've already taken the first step. Games are a form of business software. Games are consumer products. However, game development has never been dominated by Java. I won't pretend to know about the game industry, but from what I hear it's been largely dominated by C++. However, these days Lua has enjoyed great popularity in the videogames industry.
The game industry has been using the right tool for the job for some time; however, other business are also starting to catch on. Many companies are using Ruby and Rails to build websites. There's no question that having a good group of programmers building your website using Ruby and Rails can provide a significant competitive advantage. Erlang is another language that targets a specific class of applications, and it provides huge advantages over the alternatives for those applications.
I think targeted languages raise some new interesting questions.
For the professional software developer, targeted languages may make it harder to switch domains. These days it's easy to get a job doing Java development in insurance, banking, advertising, and many other domains. If in the future all the banks are using a functional language focused on low-latency, you may find it harder to make the switch to an advertising agency with a shop that's using an object oriented dynamic language. It may not be long before selecting a language implies selecting a domain as well.
There will be implications for firms also. The pools from which companies hire from will get much smaller. It's very hard to hire a good Java developer these days, imagine what the picture is going to look like when there are 5-7 targeted languages that are widely accepted and the developer pool is split 5-7 ways.
There will also be questions about how many languages your organization will support. If you're a bank and you write your trading applications using the best language for the job, would you allow the intranet dev team to use a completely different language?
Companies are already facing these questions. At DRW Trading we use C#, Java, C++, Python, Ruby, Perl, etc. I hear that Google only allows C++, Java, Python, and Javascript. There's definitely a balance between leveraging existing knowledge and using the right tool for the job. However, finding that balance isn't an easy task.
Like it or not, we're headed towards more targeted languages. It's probably worth considering the implications sooner rather than later.
I might be overestimating the speed at which our profession is maturing. One of the reasons Java became the enterprise standard was because the wrong people were making decisions based on inadequate information and swarms of terrible programmers. I like to believe that we're moving away from those days, but then again, we definitely still have far too many NNPPs that need to be encouraged to find other employment. However, I do think it's inevitable that we move to languages targeted at specific domains and problems eventually.
We've already taken the first step. Games are a form of business software. Games are consumer products. However, game development has never been dominated by Java. I won't pretend to know about the game industry, but from what I hear it's been largely dominated by C++. However, these days Lua has enjoyed great popularity in the videogames industry.
The game industry has been using the right tool for the job for some time; however, other business are also starting to catch on. Many companies are using Ruby and Rails to build websites. There's no question that having a good group of programmers building your website using Ruby and Rails can provide a significant competitive advantage. Erlang is another language that targets a specific class of applications, and it provides huge advantages over the alternatives for those applications.
I think targeted languages raise some new interesting questions.
For the professional software developer, targeted languages may make it harder to switch domains. These days it's easy to get a job doing Java development in insurance, banking, advertising, and many other domains. If in the future all the banks are using a functional language focused on low-latency, you may find it harder to make the switch to an advertising agency with a shop that's using an object oriented dynamic language. It may not be long before selecting a language implies selecting a domain as well.
There will be implications for firms also. The pools from which companies hire from will get much smaller. It's very hard to hire a good Java developer these days, imagine what the picture is going to look like when there are 5-7 targeted languages that are widely accepted and the developer pool is split 5-7 ways.
There will also be questions about how many languages your organization will support. If you're a bank and you write your trading applications using the best language for the job, would you allow the intranet dev team to use a completely different language?
Companies are already facing these questions. At DRW Trading we use C#, Java, C++, Python, Ruby, Perl, etc. I hear that Google only allows C++, Java, Python, and Javascript. There's definitely a balance between leveraging existing knowledge and using the right tool for the job. However, finding that balance isn't an easy task.
Like it or not, we're headed towards more targeted languages. It's probably worth considering the implications sooner rather than later.
Labels: developers, languages
Tuesday, November 18, 2008
Specialize in Something Relevant
generalist: a person competent in several different fields or activitiesIf you read my blog entry on Language Specialization you might have concluded that I prefer generalists. If, in our industry, generalists were what the definition describes, then I would prefer generalists. Unfortunately, business software developers seem to have created their own definition of generalist.
business software developing generalist: I know how to do the simplest tasks with many different languages/tools, but I can not be considered competent with any of them.I blame Scott Ambler. To me anyway, it seems like the daft generalist movement started when Scott wrote Generalizing Specialists.
Our industry has always been saturated by bad programmers. I'm on record stating that at least 50% of the people writing business software should find a new profession. The problem with bad developers is that they take good ideas and turn them in to monstrosities.
I remember reading Generalizing Specialists and being inspired. I thought Scott gave fantastic and relevant advice. Unfortunately, many bad or junior developers heard: Don't bother to deeply understand anything, instead, you're agile if you know a little about everything. Suddenly, when I started interviewing developers I ran into situations like this.
- me: So, I see you have Erlang on your resume, how do you like the language?
- candidate: I like it's concurrency handling, but I'm a bit weary of it's syntax.
- me: (thinking - okay, do you have any original thoughts on Erlang?) I can understand those points of view, what problem were you trying to solve with Erlang and why did you think it was the right tool?
- candidate: Oh, I really only got through the 2 minute tutorial, you know, hello world basically. But if you guys have Erlang projects you want me to work on I'm happy to, I'm a generalist, I like all languages.
- me: Okay, so what language would you say you know the most about?
- candidate: I don't bother to specialize, I do a little bit with each language, you know, hello world or whatever, so I can use the right tool for the job. That's the best part of being a generalist.
- me: (thinking - this interview is already over) Okay, so tell me about the languages/tools you've had to use at your different jobs?
The truth is, these generalists have little in the way of valuable knowledge. They provide their projects with little more knowledge than a Google search can bestow in 30 minutes. In short, they're worthless, if not destructive.
I don't actually blame Scott Ambler. In my opinion he was right then, and he's right now. Become a Generalizing Specialist is still the advice that I currently give developers.
Specializing in something makes you an asset to the team. If I'm building a Web 2.0 website, I want everyone to have an understanding of HTML, CSS, Javascript, Ruby, & SQL. However, I also want each team member to specialize in one of those areas. Knowing IE quirks is just as important as knowing how to optimize MySQL. And, I want to make sure I have team members that can get into the deep, dark corners of delivering highly effective software. That doesn't mean everyone needs to know what a straight join in MySQL does, but at least 1 person should. The rest of the team isn't entirely off the hook though, they better understand how to write basic SQL statements that are maintainable and at least semi-performant.
Becoming a Generalizing Specialist takes time, but the first step is becoming a Specialist. Once you deeply understand one language/tool, you can move on to the next relevant language/tool. How do you know when it's time to move on? When you start having answers to questions that people aren't asking. If you're constantly looking up answers to common questions, you aren't a specialist. However, if you start providing more (relevant) detail in your answers than people are looking for, you're on your way to possessing the deep understanding that a Specialist should have. At that point, it's probably time to start looking deeply into something else.
One painful mistake to look out for is specializing in something less relevant. If you work for a trading firm that writes only thick client applications, understanding why Chrome's Javascript VM is better than Firefox's Javascript VM is probably not the best use of your time. It's true that you may move on to a web application at some point, but by then your information will probably have become stale anyway. Stick to specializing in things that you work with day to day. Your language, your IDE, the Domain Specific Languages you use in your applications (regular expressions, SQL, LINQ, etc), or the frameworks you use (Spring, ASP.net, etc) are things you should specialize in to increase the value you provide to your team.
Eventually, you become competent with several different tools and languages. You've become a Generalizing Specialist and as such you are significantly more valuable to your team.
Labels: developers, success
Tuesday, October 21, 2008
Language Specialization
Didn't you just totally sell out? -- Obie Fernandez @ Rails Summit Latin AmericaObie and I are good friends. He wasn't trying to insult me. I was talking about how much I liked my new job (at DRW Trading), and the different aspects of the job. One aspect of my job is that I spend a fair amount of my time working with Java. I do some C# and some Ruby also, but these days it's more Java than anything else. I believe Obie was genuinely curious if I felt like I sold out since I'm not doing Ruby full-time anymore.
It's an interesting question, but it comes packed with all kinds of assumptions. For the question to be valid, I would have had to trade something I truly care about for the combination of something I did and did not like. Luckily, that wasn't the case.
Obie isn't the first person to be surprised that I'm no longer working full-time with Ruby. Truthfully, I find it a bit funny that people think I would base a career move on a language. Ruby is my favorite language, but it's not the correct choice for every problem that needs to be solved. And, languages have never been my primary concern when deciding what job to take.
My first job primarily used Cold Fusion. When I joined AOL Time Warner I gave up Cold Fusion for PHP. When I joined IAG I gave up PHP for C#. And so on. As you can see, I've never been too tied to a language. I've always been most interested in learning and growing. I love jobs that help me improve my skills.
Chad Fowler talks about something similar. In the section "Don’t Put All Your Eggs in Someone Else’s Basket" of My Job Went to India, Chad says the following:
While managing an application development group, I once asked one of my employees, “What do you want to do with your career? What do you want to be?” I was terribly disppointed by his answer: “I want to be a J2EE architect.” ...I think Chad got it right, but it's not just companies you shouldn't trust. I wouldn't base my career on any technology, whether it was produced by a company or an open source community.
This guy wanted to build his career around a specific technology created by a specific company of which he was not an employee. What if the company goes out of business? What if it let its now-sexy technology become obsolete? Why would you want to trust a technology company with your career?
I prefer jobs that allow me to learn new things. Think of it as job security -- I shouldn't ever be out-of-date when it comes to technology experience. Think of it as an investment -- everything I learn creates a broader range of experience that I can leverage for future projects or jobs. Think of it as experimenting -- by trying many different solutions I may find ways to combine them and innovate.
I've turned down several jobs that paid more or offered comfort. I've never regretted it. Your career is long and (as Chad says) you should treat it as a business. When you look at it from that perspective it obviously makes sense to spend the early years learning and deciding which is the best direction to take.
The truth is, if you focus on one technology you'll never be as good as your teammates who have more experience mixing technologies to produce the best solution.
As I told Obie, I definitely don't feel like I sold out. In fact, one of the reasons I joined DRW was because they use Java. I've never worked with Java, messaging, or the financial domain. Having experience with those 3 things will make me better. And, diversifying your experience will make you better as well.
Labels: developers, success
Monday, September 22, 2008
When To Retire Your Brand
Building a brand takes a lot of effort, but I think the payoff justifies the investment. Having a strong brand definitely helped me find a fun and very well paying job. So now that I have a dream job (@ DRW Trading), what should I do with my brand?
I have to confess, I didn't start writing because I wanted share information. I started writing because I wanted to build a big brand, find a great job, and enjoy life. Somewhere along the way I began to enjoy writing and the positive results that came from knowledge sharing. Someone once said to me "I write better tests because of your blog". Obviously I was happy to hear that kind of feedback. At the same time it wasn't the reason I got started down this path.
I love to program. I also love to be in shape (which I'm not) and learn other languages (which I haven't been doing lately).
Now that I have my dream job, I've been spending more time doing the other things I love. Unfortunately, I found that between learning an interesting domain, going to the gym, and learning Italian, there's not much time left for blogging. I also find that since I'm doing all the things I love, I don't really like to be away presenting at conferences.
I thought it might be time to declare success on the brand building project, and move on to new pursuits... But, I was wrong.
The largest reason I can't quit writing and presenting is that I enjoy giving back to the community. Seeing a blog entry get 8,000 hits in one day causes an amazing feeling. Giving a presentation and getting feedback that says "Probably the best presentation at the conference" definitely makes you feel good about what you are doing. Seeing an idea become committed as the way to do something will definitely make you smile. I truly enjoy spreading ideas (or at least attempting to spread ideas) that help the community evolve.
Blogging and presenting also help me personally improve. The easiest way to get feedback on something is to put it out there. I considered several of my testing ideas to be "the right way" for far too long. Putting them down as blog entries resulted in further evolution of the ideas as well as a greater understanding of how context determines the correct approach. Simply writing about my ideas improves them. One thing we aren't short of is people to tell you you're wrong.
Your brand is also valuable to your employer. Employing people with name recognition improves your organization's ability to recruit talented new hires. This also directly benefits you, since you'll be given the opportunity to work with more talented teammates. At the moment, DRW is looking to hire the absolute best people in the industry. I wish I had an even stronger brand, so I could help attract the top talent.
Ultimately I came to the conclusion that building a brand is a career long activity. You can stop at any time, but getting that free time back comes at cost to your profession.
I have to confess, I didn't start writing because I wanted share information. I started writing because I wanted to build a big brand, find a great job, and enjoy life. Somewhere along the way I began to enjoy writing and the positive results that came from knowledge sharing. Someone once said to me "I write better tests because of your blog". Obviously I was happy to hear that kind of feedback. At the same time it wasn't the reason I got started down this path.
I love to program. I also love to be in shape (which I'm not) and learn other languages (which I haven't been doing lately).
Now that I have my dream job, I've been spending more time doing the other things I love. Unfortunately, I found that between learning an interesting domain, going to the gym, and learning Italian, there's not much time left for blogging. I also find that since I'm doing all the things I love, I don't really like to be away presenting at conferences.
I thought it might be time to declare success on the brand building project, and move on to new pursuits... But, I was wrong.
The largest reason I can't quit writing and presenting is that I enjoy giving back to the community. Seeing a blog entry get 8,000 hits in one day causes an amazing feeling. Giving a presentation and getting feedback that says "Probably the best presentation at the conference" definitely makes you feel good about what you are doing. Seeing an idea become committed as the way to do something will definitely make you smile. I truly enjoy spreading ideas (or at least attempting to spread ideas) that help the community evolve.
Blogging and presenting also help me personally improve. The easiest way to get feedback on something is to put it out there. I considered several of my testing ideas to be "the right way" for far too long. Putting them down as blog entries resulted in further evolution of the ideas as well as a greater understanding of how context determines the correct approach. Simply writing about my ideas improves them. One thing we aren't short of is people to tell you you're wrong.
Your brand is also valuable to your employer. Employing people with name recognition improves your organization's ability to recruit talented new hires. This also directly benefits you, since you'll be given the opportunity to work with more talented teammates. At the moment, DRW is looking to hire the absolute best people in the industry. I wish I had an even stronger brand, so I could help attract the top talent.
Ultimately I came to the conclusion that building a brand is a career long activity. You can stop at any time, but getting that free time back comes at cost to your profession.
Labels: developers, success
Monday, September 15, 2008
Is Distributed Development Viable
I've never seen distributed development succeed. However, before we get into what I've seen, I need to be specific about what I'm describing.
Just to be clear I'm not talking about outsourcing (subcontracting a process, such as product design or manufacturing, to a third-party company) or what you might call off-shoring.
This entry will be written with that in mind.
Take 1
Several years ago I worked with one of the nicest and most talented developers I expect I'll ever encounter: Badri. We worked together for about a month before he was forced back to India to deal with US visa issues. We knew this was going to happen and decided that it was so important to keep Badri on the project that we were going to give distributed development a shot. Badri knew the code, the team, and he was great on so many levels that the choice couldn't have been more obvious.
After just a few weeks, we gave up on distributed development. Ever since that experience, I've been highly skeptical of the feasibility of distributed development. I had actual experience working with one of the greatest developers I'd ever encountered, and we still failed.
Failure can be good. There are always lessons to be learned when you fail. Here were a few that I picked up from that project.
The time difference was a huge killer. Every time we spoke to Badri either he was half asleep or we were. I think Badri was working 12 hour days also, just so he could try to talk to us at the beginning and end of his day. It also meant no wine with dinner or having a bit of a buzz for the 11pm stand-up. Either of those options is unacceptable. Worse, if we didn't communicate what we needed in detail, the off-site team would be off in the wrong direction for up to 12 hours straight. We threw away several days worth of code because we hadn't given them enough detail to go in the right direction.
Truthfully, we (the on-site developers) shouldn't have been deciding what they were going to work on in the first place. It was a tough project and we were all learning. None of us felt like we had the time to do both the development required of us, plus the analysis required to give the off-site team good direction. Instead, the off-site team got minimal direction and delivered code that was of minimal use to us. It was beautiful code, but it wasn't what we needed. Again, epic fail.
Even though we clearly were not functioning well, the business expected that the off-site team deliver at the same pace as the on-site team. The business had met and loved Badri. No one could understand why our pace had suddenly dropped off. Not good. More on this later.
Take 2
A few years later I joined a project that was just beginning to give distributed development a shot. I hadn't been there 3 days and I was already in the CEO's office explaining why I thought it was a bad plan. Of course, I was gun-shy, so that was to be expected. Luckily, Fred George was also there and he was more optimistic. In the end we went to an on-site team, but Fred showed me that distributed development is possible.... maybe.... eventually.
We experienced several obstacles, and we overcame some. Again, there were plenty of lessons to be learned.
Time difference was less of a factor. This time I was working in London and the off-site team was in India. Our workdays overlapped fairly well. This was obviously a huge move in the right direction. We also collaborated on who would work on what, which helped ensure that everyone was happy with what they were working on. And, the analysis came from a BA that collaborated with both portions of the team. The BA even traveled to India occasionally.
However, things were still quite broken.
Some members of the team had never met other members of the team. There's something about working, collaborating with someone in person that is almost impossible to replicate over a phone or IM conversation. It wasn't that we didn't want to get everyone together, but there were visa issues that couldn't be overcome. It was a big mistake with no good resolution. Some long time team members couldn't travel, but if we replaced them with people who could travel we would lose domain knowledge and context.
Communication was a constant problem. The telephones on both ends presented problems. I have plenty of Indian friends that I have no problem understanding, but with the off-site team speaking into a bad connection and it being sent out of our bad connection, I caught every other sentence, if that. To make matters worse, people weren't talking nearly as often as they needed to be. We tried to address this by creating a chat room and mandating daily checkpoint phone calls. Both ideas were abandoned due to lack of buy-in. In the end we never did solve the communication issue -- in my opinion. I think the reality is that most programmers are introverted, and being off-site just gives you one more excuse for not talking to the business, even when you really should.
Connectivity was also an issue. If you're in the US, you don't really even think about the reliability of your internet connection. However, in many other places in the world connectivity is much less certain. There were several occasions where the off-site team was simply unable to check-in their code. We never did figure out if the problem was on their side, our side, in our vpn, or some other bizarre location. If your off-site can't check in, IM you, or get to the wiki, you obviously lose productivity.
There was one common problem: the business expected the same level of productivity from both teams. I'm not sure there's a way around this issue. Have you ever heard that programming is about people? Of course you have, and you obviously believe it. But, does the business know that? Even if they've heard it, do they believe it?
I doubt your business does. Frankly, I doubt most of your colleagues in the industry do. I still know far too many programmers who think that their only responsibility is to write code that creates features. If that were true, if we were nothing more than line workers delivering feature after feature, it would be plausible that productivity shouldn't suffer no matter where the factory exists.
But, it's not true. Being a software developer is about communication, collaboration, analysis and coding, at least. Being a phone call away instead of a face to face conversation away impacts communication and collaboration. Thus, productivity is impacted. There's no getting away from that.
How can you convince your business of that? I haven't solved that problem yet, unfortunately.
What could be
I do think Fred had the right ideas. He described scenarios that had previously benefited from distributed development, and what made those situations succeed.
The first suggestion is to get everyone together. You want the team to gel as one entity. Do version one entirely on-site if possible. However, don't do it with all local resources. Bring people from the desired off-site location to work on-site for the first release. The team members will build trust and friendships that last up to 6 months.
Once you are on version two you can move the desired team members back off-site. However, the travel isn't over for anyone. The off-site team should always have at least one member from the on-site team with them, likewise the on-site team should always have at least one member of the off-site team present. These aren't week long trips either. Each member of the team should visit the other location for a month, once every five to six months. That level of in-person communication should lead to high levels of trust and understanding.
The travel situation is even more drastic for the analysts and stakeholders. They should split their time between the two teams, if possible. Neither team should feel like the A team or the more important team. Any implication that one team is above the other team will lead to negative productivity impacts.
That might sound drastic, but it's the price of doing off-site development. The cost doesn't stop there.
Both team locations are going to need to invest heavily in infrastructure. The best video conferencing software and highly reliable bandwidth will also need to be purchased. The idea is to foster communication in every way possible. Without communication and collaboration, the project is doomed.
Open Source
Before anyone points out that it's hard to argue with the success of Open Source, I'd like to be clear -- I'm not. Open Source is obviously successful and developed most often in a distributed manner. However, there are a few differences that, I believe, make it a different situation entirely.
First of all, most people aren't paid to work on Open Source. When someone isn't paying you, you can often do whatever you feel like, whenever you feel like it. If someone is working in the same area of the code as you need to, you can just put off your changes until they are done.
However, the reality is that most people aren't usually working in common areas when they work on open source. Most open source projects are maintained by a few people who work within specific portions of the codebase. If changes need to happen in "your" portion of the codebase, you often queue them up to work on after you finish your current task.
Since there's little conflict between what you work on and what other team members work on there's significantly less communication and collaboration required, and what is necessary can happen at a much slower pace. If you need to make a change, it doesn't often need to happen right away. It can be put off until the team member on the other side of the world wakes up.
The codebase also evolves at a much slower pace. Six to ten people working in the same codebase 8 hours a day move much faster than the average Open Source project that sees 3 developers working a few hours a day.
Distributed development does work for Open Source, but that's not what I'm talking about.
Conclusion
I have heard of companies successfully doing remote pair programming and distributed development. One recipe I've heard is that everyone is off-site in different locations. I can see how that would work since it requires everyone to adopt a new work routine and make the best of it. While I believe it's possible to be successful, I think it's still bleeding edge at this point. You probably don't want to "try this at home" quite yet.
I think Distributed Development is probably the way of the future. As bandwidth and experience is more available the industry will continue to evolve in that direction. However, I think it's still probably about 5-10 years from being mainstream.
Distributed Development: A group of individuals who work across time, space, and organizational boundaries with links strengthened by webs of communication technologyThe link above for Distributed Development redirects to Virtual Team. Wikipedia also has an entry for Distributed Development; however, I found the description of Virtual Team to be much closer to what our industry generally labels Distributed Development.
Just to be clear I'm not talking about outsourcing (subcontracting a process, such as product design or manufacturing, to a third-party company) or what you might call off-shoring.
This entry will be written with that in mind.
Take 1
Several years ago I worked with one of the nicest and most talented developers I expect I'll ever encounter: Badri. We worked together for about a month before he was forced back to India to deal with US visa issues. We knew this was going to happen and decided that it was so important to keep Badri on the project that we were going to give distributed development a shot. Badri knew the code, the team, and he was great on so many levels that the choice couldn't have been more obvious.
After just a few weeks, we gave up on distributed development. Ever since that experience, I've been highly skeptical of the feasibility of distributed development. I had actual experience working with one of the greatest developers I'd ever encountered, and we still failed.
Failure can be good. There are always lessons to be learned when you fail. Here were a few that I picked up from that project.
- Time difference is probably the single largest contributing factor to failure. Badri was in India, and we were in Deleware, USA. There was almost no time overlap to our workdays.
- Having the local or on-site developers feed requirements back to the off-site team equates to an order of magnitude efficiency loss.
- Having the on-site developers decide what pieces are going off-site quickly translates to the off-site team being pissed off about getting the boring work
- Businesses expect the same level of quality and productivity from the on-site members as the off-site members.
The time difference was a huge killer. Every time we spoke to Badri either he was half asleep or we were. I think Badri was working 12 hour days also, just so he could try to talk to us at the beginning and end of his day. It also meant no wine with dinner or having a bit of a buzz for the 11pm stand-up. Either of those options is unacceptable. Worse, if we didn't communicate what we needed in detail, the off-site team would be off in the wrong direction for up to 12 hours straight. We threw away several days worth of code because we hadn't given them enough detail to go in the right direction.
Truthfully, we (the on-site developers) shouldn't have been deciding what they were going to work on in the first place. It was a tough project and we were all learning. None of us felt like we had the time to do both the development required of us, plus the analysis required to give the off-site team good direction. Instead, the off-site team got minimal direction and delivered code that was of minimal use to us. It was beautiful code, but it wasn't what we needed. Again, epic fail.
Even though we clearly were not functioning well, the business expected that the off-site team deliver at the same pace as the on-site team. The business had met and loved Badri. No one could understand why our pace had suddenly dropped off. Not good. More on this later.
Take 2
A few years later I joined a project that was just beginning to give distributed development a shot. I hadn't been there 3 days and I was already in the CEO's office explaining why I thought it was a bad plan. Of course, I was gun-shy, so that was to be expected. Luckily, Fred George was also there and he was more optimistic. In the end we went to an on-site team, but Fred showed me that distributed development is possible.... maybe.... eventually.
We experienced several obstacles, and we overcame some. Again, there were plenty of lessons to be learned.
Time difference was less of a factor. This time I was working in London and the off-site team was in India. Our workdays overlapped fairly well. This was obviously a huge move in the right direction. We also collaborated on who would work on what, which helped ensure that everyone was happy with what they were working on. And, the analysis came from a BA that collaborated with both portions of the team. The BA even traveled to India occasionally.
However, things were still quite broken.
Some members of the team had never met other members of the team. There's something about working, collaborating with someone in person that is almost impossible to replicate over a phone or IM conversation. It wasn't that we didn't want to get everyone together, but there were visa issues that couldn't be overcome. It was a big mistake with no good resolution. Some long time team members couldn't travel, but if we replaced them with people who could travel we would lose domain knowledge and context.
Communication was a constant problem. The telephones on both ends presented problems. I have plenty of Indian friends that I have no problem understanding, but with the off-site team speaking into a bad connection and it being sent out of our bad connection, I caught every other sentence, if that. To make matters worse, people weren't talking nearly as often as they needed to be. We tried to address this by creating a chat room and mandating daily checkpoint phone calls. Both ideas were abandoned due to lack of buy-in. In the end we never did solve the communication issue -- in my opinion. I think the reality is that most programmers are introverted, and being off-site just gives you one more excuse for not talking to the business, even when you really should.
Connectivity was also an issue. If you're in the US, you don't really even think about the reliability of your internet connection. However, in many other places in the world connectivity is much less certain. There were several occasions where the off-site team was simply unable to check-in their code. We never did figure out if the problem was on their side, our side, in our vpn, or some other bizarre location. If your off-site can't check in, IM you, or get to the wiki, you obviously lose productivity.
There was one common problem: the business expected the same level of productivity from both teams. I'm not sure there's a way around this issue. Have you ever heard that programming is about people? Of course you have, and you obviously believe it. But, does the business know that? Even if they've heard it, do they believe it?
I doubt your business does. Frankly, I doubt most of your colleagues in the industry do. I still know far too many programmers who think that their only responsibility is to write code that creates features. If that were true, if we were nothing more than line workers delivering feature after feature, it would be plausible that productivity shouldn't suffer no matter where the factory exists.
But, it's not true. Being a software developer is about communication, collaboration, analysis and coding, at least. Being a phone call away instead of a face to face conversation away impacts communication and collaboration. Thus, productivity is impacted. There's no getting away from that.
How can you convince your business of that? I haven't solved that problem yet, unfortunately.
What could be
I do think Fred had the right ideas. He described scenarios that had previously benefited from distributed development, and what made those situations succeed.
The first suggestion is to get everyone together. You want the team to gel as one entity. Do version one entirely on-site if possible. However, don't do it with all local resources. Bring people from the desired off-site location to work on-site for the first release. The team members will build trust and friendships that last up to 6 months.
Once you are on version two you can move the desired team members back off-site. However, the travel isn't over for anyone. The off-site team should always have at least one member from the on-site team with them, likewise the on-site team should always have at least one member of the off-site team present. These aren't week long trips either. Each member of the team should visit the other location for a month, once every five to six months. That level of in-person communication should lead to high levels of trust and understanding.
The travel situation is even more drastic for the analysts and stakeholders. They should split their time between the two teams, if possible. Neither team should feel like the A team or the more important team. Any implication that one team is above the other team will lead to negative productivity impacts.
That might sound drastic, but it's the price of doing off-site development. The cost doesn't stop there.
Both team locations are going to need to invest heavily in infrastructure. The best video conferencing software and highly reliable bandwidth will also need to be purchased. The idea is to foster communication in every way possible. Without communication and collaboration, the project is doomed.
Open Source
Before anyone points out that it's hard to argue with the success of Open Source, I'd like to be clear -- I'm not. Open Source is obviously successful and developed most often in a distributed manner. However, there are a few differences that, I believe, make it a different situation entirely.
First of all, most people aren't paid to work on Open Source. When someone isn't paying you, you can often do whatever you feel like, whenever you feel like it. If someone is working in the same area of the code as you need to, you can just put off your changes until they are done.
However, the reality is that most people aren't usually working in common areas when they work on open source. Most open source projects are maintained by a few people who work within specific portions of the codebase. If changes need to happen in "your" portion of the codebase, you often queue them up to work on after you finish your current task.
Since there's little conflict between what you work on and what other team members work on there's significantly less communication and collaboration required, and what is necessary can happen at a much slower pace. If you need to make a change, it doesn't often need to happen right away. It can be put off until the team member on the other side of the world wakes up.
The codebase also evolves at a much slower pace. Six to ten people working in the same codebase 8 hours a day move much faster than the average Open Source project that sees 3 developers working a few hours a day.
Distributed development does work for Open Source, but that's not what I'm talking about.
Conclusion
I have heard of companies successfully doing remote pair programming and distributed development. One recipe I've heard is that everyone is off-site in different locations. I can see how that would work since it requires everyone to adopt a new work routine and make the best of it. While I believe it's possible to be successful, I think it's still bleeding edge at this point. You probably don't want to "try this at home" quite yet.
I think Distributed Development is probably the way of the future. As bandwidth and experience is more available the industry will continue to evolve in that direction. However, I think it's still probably about 5-10 years from being mainstream.
Labels: developers
Tuesday, September 02, 2008
Passionate, Not Dogmatic
Ted Neward recently wrote a blog entry that began with the following text:
In the past 3.5 years I had the opportunity to interact with some of the smartest people in our industry. I consider many of those smart people to be among the best software developers in the world. Unfortunately, some of the smart people I met weren't much more than assholes. The big difference I noticed between the two groups was -- The assholes were dogmatic, while the best developers were passionate
Martin Fowler is a great example of someone who is passionate without being dogmatic. For example, Martin is a classicist, he prefers state based testing. However, in Mocks Aren't Stubs Martin examines both points of view and makes no assertion on which was is absolutely correct. That's a tough thing to do, but the result is a classic article that both mockists and classicists often refer to. That's just one example, but almost every article by Martin provides at least 2 points of view. The result is extremely valuable.
I used to be dogmatic. I have no problem admitting it. My earlier writing is clearly arrogant and often shortsighted. Part of the problem was lack of experience. When you take an immature industry and give a platform to someone with limited heuristics you are bound to receive solutions with limited applicability.
As I gained more experience I realized that what I considered to be best practices were only best practices within certain contexts. I also realized that presenting something as the "one true way" only benefited those that worked within exactly the same context that I worked. People who follow my advice when it doesn't apply to their context must fail. The advice isn't flawed, but it is incomplete. You need to see the full picture.
Two interesting things happen when you write passionate entries instead of dogmatic entries.
Conversely, our industry loves dogmatic advice. For example, DRY is blindly, dogmatically followed. I'm not a fan of blindly following DRY, so I wrote about the value of duplication within tests. I attempted to give a counter point of view with contextual examples, but at the end of the day the entry got a large amount of traffic solely from the authoritative title.
It's easy to spot the difference between a dogmatic entry and a passionate entry. The dogmatic entry focuses on the best practice alone. However, a passionate entry gives equal weight to context and the best practice. Passionate entries are much more likely to see successful application, even if they don't make the top of reddit.
Preferring passionate to dogmatic entries is ultimately good, but you suffer in the short term. A career in software development is obviously a long term play, but you can't always blame someone for looking for short term gains. Of course, Martin Fowler is an example of the success you can achieve by sticking with passion over dogmatism.
There is one large upside to being passionate instead of dogmatic: You gain significantly more opportunities to learn. I can't count the number of times in the last year that I've said "I prefer the way I'm suggesting because I know it works, but let's do it your way and see if it's superior". (credit: I'm fairly sure I stole that phrase from George Malamidis while we worked together at TrafficBroker) Sometimes I was right, sometimes I was wrong, but I always learned something by trying a new approach.
That upside is what I believe truly separates the best in our industry from the assholes. The passionate leaders are constantly learning the best ways to do things, while the dogmatic leaders have stopped evolving their approach. As I said before, both groups are smart, but the dogmatic developers can only get by on their wisdom for so long. Eventually all dogmatic leaders become irrelevant.
... the debates have begun, with all the carefully-weighed logic, respectful discourse, and reasoned analysis that we've come to expect and enjoy from this industry.Ted's comment is funny because it's true. Ted's comment is also disappointing... because it's true.
Yeah, right.
In the past 3.5 years I had the opportunity to interact with some of the smartest people in our industry. I consider many of those smart people to be among the best software developers in the world. Unfortunately, some of the smart people I met weren't much more than assholes. The big difference I noticed between the two groups was -- The assholes were dogmatic, while the best developers were passionate
passionate: expressing, showing, or marked by intense or strong feelingThe difference between passionate and dogmatic is slim, but the result is dramatic.
dogmatic: asserting opinions in a doctrinaire or arrogant manner
--dictionary.com
Martin Fowler is a great example of someone who is passionate without being dogmatic. For example, Martin is a classicist, he prefers state based testing. However, in Mocks Aren't Stubs Martin examines both points of view and makes no assertion on which was is absolutely correct. That's a tough thing to do, but the result is a classic article that both mockists and classicists often refer to. That's just one example, but almost every article by Martin provides at least 2 points of view. The result is extremely valuable.
I used to be dogmatic. I have no problem admitting it. My earlier writing is clearly arrogant and often shortsighted. Part of the problem was lack of experience. When you take an immature industry and give a platform to someone with limited heuristics you are bound to receive solutions with limited applicability.
As I gained more experience I realized that what I considered to be best practices were only best practices within certain contexts. I also realized that presenting something as the "one true way" only benefited those that worked within exactly the same context that I worked. People who follow my advice when it doesn't apply to their context must fail. The advice isn't flawed, but it is incomplete. You need to see the full picture.
Two interesting things happen when you write passionate entries instead of dogmatic entries.
- Your advice is more widely and appropriately used.
- Your traffic goes down significantly.
Conversely, our industry loves dogmatic advice. For example, DRY is blindly, dogmatically followed. I'm not a fan of blindly following DRY, so I wrote about the value of duplication within tests. I attempted to give a counter point of view with contextual examples, but at the end of the day the entry got a large amount of traffic solely from the authoritative title.
It's easy to spot the difference between a dogmatic entry and a passionate entry. The dogmatic entry focuses on the best practice alone. However, a passionate entry gives equal weight to context and the best practice. Passionate entries are much more likely to see successful application, even if they don't make the top of reddit.
Preferring passionate to dogmatic entries is ultimately good, but you suffer in the short term. A career in software development is obviously a long term play, but you can't always blame someone for looking for short term gains. Of course, Martin Fowler is an example of the success you can achieve by sticking with passion over dogmatism.
There is one large upside to being passionate instead of dogmatic: You gain significantly more opportunities to learn. I can't count the number of times in the last year that I've said "I prefer the way I'm suggesting because I know it works, but let's do it your way and see if it's superior". (credit: I'm fairly sure I stole that phrase from George Malamidis while we worked together at TrafficBroker) Sometimes I was right, sometimes I was wrong, but I always learned something by trying a new approach.
That upside is what I believe truly separates the best in our industry from the assholes. The passionate leaders are constantly learning the best ways to do things, while the dogmatic leaders have stopped evolving their approach. As I said before, both groups are smart, but the dogmatic developers can only get by on their wisdom for so long. Eventually all dogmatic leaders become irrelevant.
Labels: developers
Thursday, August 28, 2008
Great Developers Are Hard To Find, Regardless of Language
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.
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.
Labels: developers
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.
Labels: developers, success
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.
Labels: developers
Tuesday, July 29, 2008
Developers needed; Hackers need not apply
Two developers interview for the same position. The position is software development for an internet advertising agency. The agency needs a developer to help create internal and external websites.
When the interview ends the candidates are given a simple assignment: the business needs to convert a csv file from one format to another. The candidates are given 24 hours to complete the task.
The first developer goes home and designs an amazing yet simple site where multiple files can be uploaded simultaneously and users can choose to be notified via SMS or email when the task is completed. It's great software.
The second developer receives the assignment and spends the next 30 minutes talking to the business to see how the software will be used and what value it provides. After he's gotten the information he needs he says thanks, but instead of letting him leave, the CTO offers him the job on the spot.
The first developer gets the "thanks, but no thanks" call the following day.
What the first developer didn't understand was that the assignment was designed to evaluate collaboration, not coding ability. Both candidates had previously submitted code samples and discussed their samples as part of the interview. Both developers could code equally well, but only candidate 2 had collaboration skills. Candidate 2 was clearly a better hire.
Developers love to talk about how software is about people. I know it's about people, you know it's about people, yet when I look around I rarely see developers interacting with people. It doesn't seem to make sense, and yet it happens the majority of the time. We're stuck in the ways of software development past.
Hackers put out code, often good code. That's great. Without hackers I wouldn't have messaging systems, proxies, web servers, etc. At least I wouldn't have such a good selection. But, being a good hacker doesn't make you valuable to a business.
Time after time I see requirements gathered and presented in a way that is totally disconnected from the business problem that's being addressed. There are two ways to handle the situation.
But, a developer can deliver what the business is looking for the first time. A(n often) quick conversation with the business ensures that the developer knows what to work on and how it will benefit the business. This dialog often leads to a superior solution implementation where the business gets what it wants and the developer is able to do it in the most efficient way (e.g. I don't need a beautiful website, I need a command line application).
A hacker can deliver the same value to the business (on the 2nd or 3rd try), but the time difference between when the developer delivers and when the hacker delivers is the cost of employing hackers. Hackers create waste (lost time), which the business must pay for. Good developers avoid waste by ensuring that the business gets what they are looking for as quickly as possible.
This idea isn't mine, I just see the application of the idea constantly so I felt the need to write about it. Kent Beck has been talking about it for years, most recently at QCon in London earlier this year. Look for the video when it becomes available at InfoQ -- it's relevant for anyone developing software for a business, and Kent puts it much better than I do. When Kent talks about it you think "well, yes, obviously", but look around work and see if Kent's ideas are being applied. If they are, consider yourself lucky to be working with good colleagues.
When the interview ends the candidates are given a simple assignment: the business needs to convert a csv file from one format to another. The candidates are given 24 hours to complete the task.
The first developer goes home and designs an amazing yet simple site where multiple files can be uploaded simultaneously and users can choose to be notified via SMS or email when the task is completed. It's great software.
The second developer receives the assignment and spends the next 30 minutes talking to the business to see how the software will be used and what value it provides. After he's gotten the information he needs he says thanks, but instead of letting him leave, the CTO offers him the job on the spot.
The first developer gets the "thanks, but no thanks" call the following day.
What the first developer didn't understand was that the assignment was designed to evaluate collaboration, not coding ability. Both candidates had previously submitted code samples and discussed their samples as part of the interview. Both developers could code equally well, but only candidate 2 had collaboration skills. Candidate 2 was clearly a better hire.
Developers love to talk about how software is about people. I know it's about people, you know it's about people, yet when I look around I rarely see developers interacting with people. It doesn't seem to make sense, and yet it happens the majority of the time. We're stuck in the ways of software development past.
Hackers put out code, often good code. That's great. Without hackers I wouldn't have messaging systems, proxies, web servers, etc. At least I wouldn't have such a good selection. But, being a good hacker doesn't make you valuable to a business.
Time after time I see requirements gathered and presented in a way that is totally disconnected from the business problem that's being addressed. There are two ways to handle the situation.
- Write the best code you can.
- Talk to the business.
But, a developer can deliver what the business is looking for the first time. A(n often) quick conversation with the business ensures that the developer knows what to work on and how it will benefit the business. This dialog often leads to a superior solution implementation where the business gets what it wants and the developer is able to do it in the most efficient way (e.g. I don't need a beautiful website, I need a command line application).
A hacker can deliver the same value to the business (on the 2nd or 3rd try), but the time difference between when the developer delivers and when the hacker delivers is the cost of employing hackers. Hackers create waste (lost time), which the business must pay for. Good developers avoid waste by ensuring that the business gets what they are looking for as quickly as possible.
This idea isn't mine, I just see the application of the idea constantly so I felt the need to write about it. Kent Beck has been talking about it for years, most recently at QCon in London earlier this year. Look for the video when it becomes available at InfoQ -- it's relevant for anyone developing software for a business, and Kent puts it much better than I do. When Kent talks about it you think "well, yes, obviously", but look around work and see if Kent's ideas are being applied. If they are, consider yourself lucky to be working with good colleagues.
Labels: developers
