Do You Speak “Geek”?

Published on March 27, 2008 by in Best Practices, How To

1
Do You Speak “Geek”?

Or perhaps more importantly, should you? I want to explore the very common situation of a manager or small business owner who does not “speak geek” and needs to outsource a software or web development project. I was recently asked by someone in such a position what the “best way to talk to a web developer” would be, since their requirements discussions were ending up in what he described as “Babylonic confusion,” hoping to find a book or course he could take in order to be able to better communicate his needs to the developer.

240px Babel Fish diagram Do You Speak “Geek”?

I don’t know that anyone has found a real live Babel Fish yet, so you’d better figure out another way to get your point across to the geek(s).

It’s Not Me, It’s You

At a moment like this, it’s time go and get yourself a new developer. The project is doomed to fail. While it is your responsibility as a project manager to clearly articulate your requirements, it should only have to be done so in your own comfort zone and business terminology and not involve learning a new language. Here are some inherent problems with taking this approach:

  • First, this assumes there is a single language to be learned. There are typically multiple technologies involved in any project (e.g. database, server operating system, programming language(s), scripting language(s), hosting platform, external API’s, etc…) and hoping to become conversant in all of them is going to take an incredible effort at best and is futile at worst.
  • Second, merely speaking the language is not enough and could, in fact, exacerbate the problem. The reason is that there is such a thing as “knowing enough to be dangerous”. Without experience in architecting a solution, talking about the technical aspects of a solution is premature. It would be like specifying what type of tires you want on a new car before even deciding whether it will be a sports car, sedan, or SUV!
  • Third, this leads to the real possibility that you will end up with what you asked for and not what you wanted. This is quite common in software development. It’s something like asking for a “kick ass” sports car and then getting a car with a mechanical arm on the front of the car with a boot mounted to it. It may be what you asked for, but it’s not what you wanted.

bug bash20061009 Do You Speak “Geek”?

Tell Me What You Want, Then I’ll Tell You What You Need

I’ve sat down with users many times in requirements meetings and asked them what they want the system to do. Often, they find it very difficult to answer because there have not been any boundaries or parameters established for them. It’s like when my wife asks me, “What do you want for dinner tonight?” When I’m feeling particularly sarcastic, I’ll say something inflammatory like “How about Peking duck with an orange glaze and chocolate soufflé for dessert?” and then run for cover. What I’m actually saying is, “What are my choices? What are the parameters? Are you going shopping or do we need to find something in the fridge? If so, what do we have? What about take out?” You get the picture.

When you alter this scenario and instead put a prototype or screen shots in front of users, then you’ll get bags and bags of feedback. That’s because the parameters have been set and they can visualize the inputs, the manipulations, and the outcomes. In the end, that’s what information technology is; stuff goes in to a box, something happens to the stuff, and new stuff comes out the other end. It’s all about defining the inputs, the manipulations and the outputs. But that still doesn’t answer the fundamental question here. How do you deal with a contract developer who doesn’t get it? I’ve already said you go and get yourself a new one. But how do you make sure the new one will work out differently?

Tell Me Something I Don’t Know

Developing a software application is a lot like building a house; it’s the design, architect, build process. You’re the designer and ideally you’d like to find the architect and builder in the form of one person. As a last resort, you are better off hiring both if you can’t find one person to do both jobs. And remember this – you’re a designer, not an architect and certainly not a builder!

The bottom line is to try to find someone with experience in the business arena in which you operate. If you’re the owner of a small chain of sandwich shops, don’t just hire someone who’s developed a web site before, try to find someone who’s developed a web site for a restaurant. And not just one restaurant; a chain. Experience is golden here and there is one rule of thumb that I also mentioned in an earlier blog (Yes, Virginia, You Need a Web Site). When or if you find a developer who can tell you something non-technical about your business that you didn’t know, then you know you’ve got yourself a winner.

Continue Reading

People Versus Process

Published on March 8, 2008 by in Best Practices

0
People Versus Process
Today I answered a question on LinkedIn regarding a fledgling company’s pursuit of a software development firm in order to commercialize their idea. I was fascinated to read the other answers, which predominately focused on the process whereas I focused on the people. That’s when it struck me…

People solve problems, not processes. I know this sounds like I’m trying to make an obvious observation sound like some brilliant and ironic commentary on mankind. But after you’re done rolling your eyeballs, hear me out.

Throughout my career, I’ve been dismayed and disappointed to encounter regularly customers with huge software development messes left unfinished. Incidentally, that’s not to say that I haven’t been responsible for any. Like everyone else, I’ve learned from mistakes and improved over the years. But as I consider the landscape today and assess how it is that organizations continue to struggle with domesticating the IT animal, it seems to me that many of them confuse people with process.

I see evidence of this in the job market for contract software developers nearly every day. To begin with, there is typically a lengthy and detailed list of requirements for expertise with this language and that technology. Next, candidates are frequently subjected to pre-screen quizzes and online assessment testing to determine their knowledge of programming minutia. My contention is that this only confirms the process and not the person. In other words, the person can string together these particular commands without referencing the help file. Ergo, they must have done this before. Ergo, they are a knowledgeable programmer.

Another example is the reliance upon and prescription of complicated specifications and/or rigid methodologies. Don’t get me wrong here; I think standards and best practices are a good thing. However, rigid and complicated processes tend to prevent people from seeing the forest through the trees, as the focus necessarily shifts from the project’s goal to making sure we didn’t skip step number 12 in section 2 of the first volume of the third edition of the Hitchhiker’s Guide to Project Implementation (with apologies to the late, great Douglas Adams).

If it sounds like I am not sympathetic to the plight of project and hiring managers, I am. If it sounds like I am condemning the use of accepted methodologies or detailed specifications, I am not. What I am saying is this. Most of the time, a great process will not save you from bad people. But most of the time, great people will save you from a bad process.

hbr Image33 People Versus Process

It is rare that major undertakings in life go strictly according to plan. At which point, I take the advice of on Gunny Sergeant Highway from the movie Heartbreak Ridge; “You adapt. You overcome. You improvise.” By their very nature, processes tend not to be adaptive or improvisational. This is where the problem solving skills and experience come into play and the “blank sheet” guys and gals earn their pay.

What is a “blank sheet” person? In my experience, employees can be categorized in two ways depending upon how they react to being given a blank sheet of paper; those who are exhilarated and those who panic. The former represent good modelers and problem solvers who can turn concept into reality. They are the “problem solvers” and “inventors”. The latter represent task-oriented, linear workers who can take a set of inputs, effective use their tool set, and stamp out results. They are the “doers”. Each has their advantages and disadvantages. Sometimes the inventors are too busy contemplating, designing, and conceiving to actually get any work done. Other times, the doers run out of inputs or break a tool and are stuck until someone shows them a way out. They key is to know how many “inventors” you need (and/or have) and how many “doers” you need (and/or have).

dilbert2008026112009 People Versus Process
This brings me full circle to the impetus for this blog entry. The process of selecting the right software developer or consulting firm to undertake a major project is very difficult. I have walked many of those mine fields and passed the corpses along the way. I am a firm believer that high quality software development requires programmers who have some amount of subject matter expertise. The one nugget of practical advice I’ll offer here is to search for a consultant who can tell you something non-technical about your project that you didn’t already know. Then you’ll know that you have someone who has more to offer than stamping out lines of code. If you ask a user what they want a program to do, they will generally struggle to articulate an answer (it’s a rare and beautiful thing when they can, believe me). When they actually get their hands on something, however, you will not be able to shut them up! They will generally be more than happy to tell you what’s good, what’s not, and what’s missing. The best programmers will know much of this ahead of time and, by all means, be able to adapt, overcome, and improvise. Otherwise, you could very well become one of the many who have uttered the phrase, “You built me what I asked for, but that’s not what I want!”

Continue Reading