The Psychology of Non-Programmers

With apologies to Gerry Weinberg, author of The Psychology of Computer Programming, what is the psychology of non-programmers, folks who would never call themselves developers, but are using new-age tools like BPM or mashups to create business solutions? I'm not sure, because although I work for Forrester now, I used to be a programmer, years ago, so I am forever cut off from knowing what it's like not to be a programmer.

Why do we care? Well if you've been following the posts to our blog, you know that non-programmers, who we might call "business developers" (although they would probably hate that term) or "super users" are a central theme in the future of application development. My colleague Mike Gualtieri has outlined two scenarios for the future of app dev, and future 2, the "Dynamic Business Developer," is all about business people who have a day job in the business, but who are also doing some of what we might call "development."

But What Do "Real Programmers" Think About "Business Developers"?

Another member of our team, John Rymer, recently gave a keynote at the Spring Experience in Florida. As part of that session John presented the vision that he and Connie Moore have developed of Dynamic Business Applications, and included some of this discussion around the role of business analysts or business developers in our vision of the future. Later on after his session, John sat down with some Java developers, avid users of the Spring framework from SpringSource (formerly known as Interface21). They said:

"I wish business managers would stop trying to micromanage our work. They should get out of the way and let us create value."

Not a very collaborative attitude, but not uncommon. Why do some developers think this way? They live in a world that values the ability to craft a better algorithm more than the ability to solve a business problem. Well, perhaps I exaggerate. I know plenty of developers who really get off on making business people happy (and I was one of them, back in the day). But the dirty little secret is that our universities and other sources of entry-level developers are still cranking out lots of this other kind of developer. Exactly the wrong kind of developer to work with the business in a collaborative fashion.

Why Are Developers So Cranky?

It takes a certain kind of person to have the concentration and focus to sit in front of a computer all day and crank out code. Some of the folks who are good at this are not so good with their social skills, nor are they really interested in the business except as a source of funds for their paycheck. Folks from this mold can make great engineers, but unless they are that rare individual who combines those qualities with great right-brain visual acuity and strong social and verbal skills, they will have a hard time communicating effectively with the business, or truly empathizing with the goals of business people.

Hey, Gene Leganza (VP and Research Director of the Enterprise Architecture team) told a funny joke the other day at our Enterprise Architecture Forum - well, it was about architects, but I think we can use it here, too:

"How can you tell when an enterprise architect is an extrovert? When he looks at your shoes while talking he's talking to you, instead of his own!"

Whoa hoh!

So What About Business Developers?

I said I wanted to talk about business developers, or non-programmers, so why so much time talking about programmers? Well, other than it being the world I know, and having that joke to tell, I think one of the key issues around growing more business developers will also be the psychology of this role, both the way business people perceive it, and the way current developers perceive it. What motivates a business person to learn how to do this work? What kind of person is good at it? Some ideas:

  • Perhaps the best business developers, or non-programmers, will be similar to those folks who can craft amazing spreadsheets in Excel. I'm not one of them! But for the right person with the patience to learn how all those formulas and features work, you can do some pretty amazing things.
  • Will business developers even want to be called something with "developer" in the name? Probably not! The best business developers identify much more with their business peers, than with IT folks. They don't want to be labeled a geek - whereas I fully embrace my geekhood!
  • The motivation to develop in this career will have to include wanting to be a member of the club. They don't want to be a member of the programmer / geek club. So what are the attributes of the non-programmer club? Is their favorite sport more likely to be golf than cycling?

Please Give Us Your Feedback!

We'd love to hear your stories, your jokes, your ideas about business developers or non-programmers!

  • Do you know a business developer, or are you one? What are they (or you) like?
  • How should enterprises think about finding and growing folks like this?
  • Is it crazy to think developers and non-developers can get along? What do you think these roles will look like in the future?

Mike Gilpin


re: The Psychology of Non-Programmers

Mike--Here are a couple of pieces of the puzzle:College CS programs do not teach budding young developers to build products. Instead, they focus on projects that they need to finish for this semester. The "customer" is the CS professor, who will be grading on the elegance or functionality of the code, not the value to a hypothetical user.Fast forward 10 years. The former CS major is now a development manager. Her job is to deliver releases, on time, within certain parameters of acceptability. Anything that stands between her and that goal is a distraction that can hurt her compensation, future career prospects, and team morale.That's how some developers get cranky. This maturation process does not fully explain aspect of what you call "crankiness," such as...(1) Developers who think that users are idiots.(2) Developers who agree to unrealistic schedules with no room for tactical adjustments.P.S. I'd definitely not call the business users who drive requirements "developers." They need to have a different mindset that counterbalances the project-driven, deadline-obsessed world of software development. Mingling the cultures would help no one.

re: The Psychology of Non-Programmers

Thanks, Tom. By the way, I would call "business users who drive requirements" business analysts. The sort of person we're seeking to label, who some might call a business developer, is not merely the source of requirements, they are an active participant in the development process.In the case of the Excel example, they would create the spreadsheet and author all the macros, but would still probably rely upon an IT person to write any underlying services that are invoked by those macros.Other key examples of this situation:-- A "business developer" who uses a mashup tool to create an app that mashes up a Google Map with data from services provided by IT - perhaps with customer information that salespeople can then use to target their sales activities in a map region.-- A "business developer" who is granted the authority to make changes to business rules, in a rules-based application. To make that work, the means of changing rules has to be business-friendly, not the sort of rule editor designed for programmers. I've seen such business-friendly editors from vendors like Pegasystems.-- A "business developer" who authors process models in a BPM tool, which are then used to drive application behavior. This is not typical today, but it does happen occasionally. What's more likely today is that a business that needs this sort of work done will hire a developer to work for them locally (not in IT) to do that work, but with a strong business background and focus. But in the future, for BPM tools that have simple enough business-friendly editors, there's no reason why the same sort of business person who can author an Excel or Word macro, couldn't also author process models.

re: The Psychology of Non-Programmers

I think the idea of "business developed" applications is fine if properly bounded and supported. Where business developemnt reall makes developers cranky is when a user builds some monster spreadsheet or scripted application with no help or guidance from IT, shares it around his group, then transfers to another job, and then the business says "Here IT, you need to support this for us, and oh by the way, we have to make it work globally now." And then we are expected to work miracles with a set of code that was never developed to support this.It is possible to have this model if what the user can do is boudned to a certain problem space, or if IT allocates specific resoruces dedicated to the user to help them (the old End User Computing idea), but users developing things totally on their own and then throwing them over the fence is not truly workable.

re: The Psychology of Non-Programmers

Thanks Robert, I think you're exactly right. I recall being on the receiving end of a few of those over-the-wall handoffs back in the days of dBASE III in the 80s (dating myself, I know). Ugh.To your point about appropriate boundaries, two ideas:-- I don't have a lot of data points on this, but I have seen one good solution to this problem, from Pegasystems. In the example they showed me, it was possible for a developer to create a rules-driven application that exposed only specific rules, and specific classes of change to those rules, to the business "developer." The domain-specific editor that was made available to the business person had the smarts built in to ensure that only those classes of change were done, and that the resulting rules were valid and would work in context.-- But in general I don't think these kinds of constraints are in place today in the tools that are provided for IT developers and business "developers" to work together in this concerted fashion. This is the area where the most work needs to be done by vendors of tools, before this vision can become a more widespread practical reality. Fortunately the general move toward more policy-based ways of specifying application behavior holds out a glimmer of hope that such policies can also be established to enable, but also constrain, what the business "developer" can do.