Key Developer Skills: Renaissance Man And The Case For Voluntary Ignorance

January 24, 2010 at 10:12 am 1 comment

Looking at resumes this weekend, trying to see good developers among the Currently Fashionable Acronyms (CFAs…?) and I can’t.  Assorted certifications can be found and new-fangled terms like “Agile” and “Scrum” have made an appearance but they seem to obscure more than they tell. It appears that we are all trapped in some kind of techno-fetish wonderland: Good evidence that he or she is a wizard with generics, dreams in lambdas and knows that a “sprint” is about spending long hours sitting on your butt instead of running trumps all else.

Lighten up, people. Whatever happened to Renaissance Man ( and Woman)? Remember – It was supposed to be fun. It’s a thinking machine, a marvel into which you put how the world works (… bits of it, anyway…) and which adds two and two together for you. No matter how satisfying and important it is to work on the plumbing, it won’t help if you wear blinkers which keep you from seeing that you are building a hot tub when a bidet is needed.

It seems to me that the most important skill for developers is the ability to switch their thinking between different perspectives on the system and the development process while at the same time consciously ignoring what they know about the others.

This is the Single Responsibility Principle applied beyond just code and for much the same reasons.

For example:

End User

Point of View:

Don’t make me think.”

Modus Operandi:

Say “what” and “how”. What does the user need to do and how do we arrange the user interface to be as simple and self-explanatory as possible to enable him to do it?

Business Stakeholder

Point of View:

“Why are we doing this? What is the required end result?”

Modus Operandi:

Say “what”, not “how”. What is the purpose of the system? Which business rules and constraints do we need to take into consideration? Which parts of the system need to be automated? What parts are manual, i. e. in scope for “end user”, “business stakeholder” and “project manager” but out of scope for “infrastructure specialist“ and possibly but not necessarily “domain modeler”? Where do we need to exchange information with other systems and why?

Domain Modeler

Point of View:

“Don’t make me think. Automate the testing.”

Modus Operandi:

Think “what” and “how do I test this”. Are we building the right thing? Is the model easy to understand by business stakeholders and developers alike? What are the domain objects and what are their responsibilities? How do we separate concerns and limit coupling in a way which minimizes the potential for side effects and simplifies automated testing as much as possible? Do we need to code a domain model or can we get away with (e.g.) a transaction script?

Infrastructure Specialist

Point of View:

“How do I code this?”

Modus Operandi:

Think how. Use your acronyms. This is the part where we think about database design, ORM vs. Linq, ASP.NET controls vs. MVC,  continuous integration, optimizing “user experiences” for developers through easy to use source control, etc.. Enough said – it’s what we do best. Most resumes say so.

Project Manager

Point of View:

“Minimize waste. Mitigate risk. Get the job done.”

Modus Operandi:

Think what and how. How can we shorten the QA feedback cycle? When somebody finishes a task, do they always know what task is most important to do next and why? What waterfalls do we have in our processes? How could we eliminate them and what are the risks/benefits of doing so? What is the current status? How close are we to meeting the project objectives? What can we do to make project stakeholders comfortable with what we are doing? Are we comfortable with what we are doing? Are we trapped in Cargo-Cult Agile or Scrummerfall ?

To Summarize:

Forget it. At least for now.


Entry filed under: Agile Project Management, People, Software Development.

Article: Working the Core Domain – Delivering Business Value by Shortening QA Feedback Cycles Software Craftsmanship: Coding Under The Influence

1 Comment Add your own

  • 1. PM Hut  |  January 25, 2010 at 9:01 pm

    I like the point of view of the user, concise and straight to the point (don’t let me think). As for the Project Manager, it is ideal for him/her to have this point of view (minimize waste, mitigate risk, and get the job done), but usually this is not the case. Many times the Project Manager’s main concerns are centered around which methodology to use, getting the job done seems to be an elusive goal for many…

    As for your “Cargo-Cult Agile”, I suggest you check this article on Cargo Cult Project Management, you might very well enjoy it.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed



%d bloggers like this: