Resume Driven Development (RDD)

Last week I had lunch with a non-technical manager customer of mine who is using our Netspective Enterprise Frameworks Suite for develoment of some heavy-duty mission-critical web applications. After choosing our NEFS, the client has seen many developers complaining about the web development process becoming “too simple” and that it will not be helping their careers and that they should switch to Struts. The manager was suprised that NEFS allowed developers to finish their project on time and budget but developers were complaining anyway. He also noted that the previous project done with Struts was late and overbudget but the developers were happy. I chuckled for a bit and found it amusing that this was the first time the manager came across a situation where programmers wanted to use tools, techniques, or technology to improve their resume instead of solving the customer’s problems. When I explained to him the concept of RDD (resume driven development) he was surprised to know that it’s actually a very widespread problem.

In fact, RDD is so prevalent these days that people will actually choose Java over Perl because “Perl will not help my career”. Or, they’ll choose WebLogic or WebSphere instead of Tomcat or Resin because “who’s going to hire me because I know Resin?” Never mind that Perl or Python may be much better for some quick and dirty solutions where Java may take too long. Never mind that WebSphere will cost much more and may be too heavy a framework for the customer’s need. I’ve heard many developers at my clients’ sites say that they “just have to use Struts on this project” because Struts is in demand. Never mind that Struts may create maintenance headaches or require senior engineering talent that may not be available.

Now, don’t get me wrong: choosing Struts is not bad, it’s very good for many applications. But, it should not be chosen to help a career; it should be chosen because the customer will get a high-quality app. Same with WebSphere or WebLogic: if scalability and reliability requirements won’t be met by smaller open source or commercial tools then definitely go with the bigger name-brand app servers. Just don’t choose WebLogic (and I’ve seen it many, many, times) because a developer wants to “learn WebLogic” at your customer’s expense! Similarly, choose languages and libraries because of their utility to your project, not the developer’s preferences to learn new things.

It’s similar to a problem I’ve seen in non-technical sectors as well — namely, the politicization of decisions. As we all know, politics (office-style) and Politics (democracy-style) often leads us to make suboptimal decisions. Managers choose particular people on their projects to help advance their careers; workers hide problems and make themselves look better to advance their careers; these are things we come across all the time. RDD is no different — developers usually can’t play politics to advance their careers so they end up with resume driven development tactics to pad their resumes so that their next job is easier to get.

Note to all managers and leaders of software projects: when developers ask you to choose a particular tool or technology, always have them explain to you why this may not just be a RDD request versus a request that may actually be good for the client. If the developer talks more about the technology as opposed to the solution or the customer’s requirements then the developer is not focused on the right topic. In fact, ask the developer outright: “will this tool, technology, or technique help your career more than it will help the client?” See how the developer responds.