10 Things About Development For ‘The Others’

TL;DR (Shame on you! the full article has more than the list below!)

A list of 10 things that developers wish were better understood by entrepreneurs, by David Pierce for Startup Weekend:

1. Know how developers work
2. We like specifics
3. Good code takes time
4. “Just code it right the first time” rarely exists
5. Lines of code per hour is not a real metric of success
6. Productivity doesn’t always happen between 9 and 5
7. Have some basic technical literacy
8. Understand technical debt
9. Understand the business value of refactoring and documentation
10. Trust Your Developers

hmmmmmm….
While I clearly am impressed by this list, I think there’s a few things to be said about it.

Devs should think more often about this list, or their own version thereof (which, incidentally, doesn’t have to be made of exactly 10 things), because it is a good introspective exercise. And introspection is good because it makes it possible for you to communicate to others your (professional, in this case) needs/desires. Sure, you need good communication skills, but those won’t help you if you don’t know what you want to communicate.

This is not just for Devs: the same sort of introspective exercise is good for the team members, regardless of their background (entrepreneur, business analysts, tech writers, etc…).

This is not just for Entrepreneurs: regardless of the original article title, Devs would like everyone working with them to know and understand these things. It’s actually a gnarly situation when the top of the organization understands the Devs’ perspective but the layers between that top and the Devs don’t. Sure, it gets gnarly when you start talking about “layers between”, but regardless…

Tweak: We like specifics AND context: as the original article explains, Devs like specifics. Actually we may even hate them, but we simply need as much specifics as we can get our hands on to complete our job in a way that other people will accept and enjoy. Anyways, the point is that Devs also need Context. Now, be careful because many many Devs will not ask for it explicitly. Some will even say they don’t want to get context (“Just tell me what you need done here”). And yet, Devs will need Context to produce a good product. So, when giving specifications to the Devs, make sure you’re also ready to describe the overall context for those requirements. What’s the business scenario, the user story? What’s the end-user trying to achieve with this feature? Does this feature make our product unique in the market or is it one of the basics every competitor implements? These are some simple examples, but the point is that the more context you can provide, the better results you will obtain. Also, make the contextual information available, but don’t push it on the Devs – if you do they will be overwhelmed and retreat in the “Just tell me what you want done right here, between pixels 15 and 75 of the 42nd screen”

Tweak: Productivity doesn’t happen on a schedule: I think the problem is not the specific 9-5 hours, but rather the idea that a creative and generative work such as development can be scheduled in a consistent manner. Sure, there may be bio-rhythms and brain-cycles, and we all understand the need to maximize the overlap of working hours among team members to avoid blocking scenarios. Yet, the quality of the work you get from the most rigidly scheduled and structured teams seems to be well below the quality of work you get from the more fluid teams. Of course, a business needs to herd us Devs (cats?) somehow, in order to keep a pulse on the business, and to be able and stir the business in the desired direction (uhm… I’m going to hope this would be upward and forward, right?). Perhaps a new item should be added to the list to resolve the conundrum?

Add: Communicate Your Needs and Goals: it may sound silly for us to say this, and I tend to think of this as part of the Trust Your Developers topic, but in any case… The Devs, as all team members and employees, work better when given the right information. I never understood the need for secrecy on business decisions within a business. Of course, until the business gets to a size where Random John Doe might be hired one day, hear about very valuable business details, and walk away tomorrow… I mean, if I was Apple, I wouldn’t post on the employees-all mailing list about our OS running on Intel until 10 minutes before announcing it to the press, but most businesses are not quite in those circumstances. Anyways, the best recommendation I can make in this area is that everyone working for the same goal should have the same information available, and everyone should communicate to the rest their needs or desires (aka: ‘What’ you want), and trust the team to come up with the best available option to achieve it (aka: ‘How’ to get it).

Tweak: Understand the business value of dev practices (such as refactoring, documentation, testing) and tools: the Devs are probably more expert at development practices than the non-Devs. This expertise should be recognized and valued accordingly by the rest of the team. Of course, the Devs should do the same in other areas, where the non-Devs (Entrepreneurs, Business Analysts, tech Writers, etc…) are the experts. So, feel free to question the Devs, because they need to be able to explain the value of these tools and practices they recommend, but give this topic the proper attention.

Image Credits: Images are stills from one of the best TV commercials ever made, the ‘Cat Herders’ ad for EDS; the embedded video above is the actual ad, via YouTube