A peek into your binary world

May 7, 2009 5:01 PM

Developers / coders / programmers: What do you wish your non-technical clients, bosses, and co-workers knew about the work you do?

I'm a non-technical guy trying to bootstrap a software-as-a-service product to market. (I'm not just the idea/vision guy; the product requires my expertise on the content end.) I've mainly been dealing with contractors so far -- although my eyes are always open for a technical co-founder -- and I've predictably come up against differences in our expectations and assumptions.

Here are some lessons I think I've learned so far (feel free to correct me if any sound wrong):

-The feature I want most is always the hardest one to implement. (This actually makes sense, because if I wanted it and it was easy to implement, it would already be for sale.)

-Coders greatly appreciate instructions to code to standards.

-Specs should include a detailed explanation of how I want the end-user experience to go, not a description of how I think it should be done on the back-end (because I have no idea).

-It's valuable to learn enough about the technology to have an intelligent discussion with the contractor. It is not valuable to use that tiny bit of information to ask dumb questions.

-I should expect to be billed for time spent answering dumb questions.

I don't like being the clueless client. So I'd like to know, with no punches pulled: What do you wish your clients, bosses, and co-workers knew?

posted by hayvac to work & money (32 answers total)

As a working coder, I was always much happier working with people who understood that the bearing of a child requires nine months regardless of the number of women assigned to the project.
posted by flabdablet at 5:24 PM on May 7, 2009 [12 favorites]

When managing a software project you have to choose between two basic strategies:

1) Manage to a budget / release date. In this approach you take your total desired feature set then cut features (or postpone them) until it fits within the available time or money (these two variables usually are highly related, more time means more billed hours means more money)

Towards the end of the dev cycle, if you are taking this approach you must be willing to cut or scale back features if it looks like the budget / date will not be met.

2) Manage to a feature set. In this approach you create what you think is the minimum set of features without which the product cannot exist and adjust the budget / release date to accommodate how many man-hours it will take to create those.

With this approach you must be willing to increase the budget or push out the release date if it eventually turns out that the required features will not be ready in time.
posted by Riemann at 5:24 PM on May 7, 2009

Related to the above: never confuse estimates with certainties. A good developer should be able to give a reasonable estimate of how long a task will take. But it is impossible to do so with perfect accuracy. Generally, the larger a task the larger the margin of error on an estimate.

Also, estimating the time to create something new is generally more accurate than estimating the time to fix a problem. The least reliable estimates of all are those on how to fix or add on to a system created by someone else.
posted by Riemann at 5:28 PM on May 7, 2009

When you ask for a feature, explain what you want it to accomplish for your business, your project, your target market, etc. If you can't explain what the concrete "payoff" will be for that feature, it's a red flag. Unless your developers are good communicators and very actively thinking about the business outside of the code, they may not be able to engage you in these kinds of discussions 'cold'. It's worth the effort, though: sometimes, an informed developer can spot other (sometimes simpler) solutions to the same problems your idea is intended to solve.

Also, developer-hours are a resource to be invested, just like builder-hours when constructing a house. If you decide that something needs changing while construction is underway, some number of already-invested hours are being thrown away.
posted by verb at 5:33 PM on May 7, 2009 [4 favorites]

Product/feature complexity is not a linear curve; it is generally exponential.
posted by shownomercy at 5:43 PM on May 7, 2009

A job can be either done fast, or properly. Only occasionally do these two results overlap.

Let the developer decide on the best tool for the task at hand. Everyone has their own strengths and weaknesses, so what is good for the goose may not neccesarily be good for the gander.

Make sure what you're asking is possible (or more accurately, not impossible).

Know what you want to get out of it, and don't change that arbitrarily.

Last, and far from least, talk to the developers and where feasible include them in the decision making process.

posted by ihunui at 5:44 PM on May 7, 2009

Good point verb.

Generally the further into a dev cycle you are the more it will cost to add, remove or change anything.

Hiring more skilled devs and not rushing the schedule will of course result in better code that is more amenable to changes. But even with the best system and the best devs it is always cheaper to add or change a feature on paper than it is to wait until development is underway and change code.

There is a regrettable tendency for some people to not really know what they want (or don't want) until they can sit down and "see" and finished (or mostly finished) product.

These people inevitably end up wasting vast amounts of money because of this inability to plan properly on their part.

Specs exist not just to tell the devs what to do but to allow the business stakeholders to figure out what they want and why they are willing to put up many thousands of dollars for it.
posted by Riemann at 5:49 PM on May 7, 2009 [2 favorites]

Testing. Testing, testing, testing.

We hate writing shitty code, we really do. But we do anyway, because we're not perfect. So we need time to test, or better yet for somebody else to test. And then we need you to assess the priority of severity of bugs. And then we need time to fix the bugs. Sometimes we forget to mention this, so when you get an estimate, ask whether it includes testing.

We also need a test environment to deploy into that isn't your production environment. We feel that preserving your data is a sacred trust, and we don't want to risk losing it by putting untested code into production.

So: yes, we do need to test. No, we can't get it right first time. No, we can't do testing in production.
posted by i_am_joe's_spleen at 5:58 PM on May 7, 2009 [2 favorites]

I highly recommend you look at texts about project management from a design build perspective. A project manager building a nuclear power plant does not need to necessarily have any idea how it works. You'd be surprised how applying solid project management practices will translate well over to high tech projects. Most projects are, in the end, an engineering project. It is easy to get lost in the technology. Make sure you define specs as such! Programmers work quicker when you can give them hard numbers (I don't expect this to get more than 2,000 hits a day, and these are reads not updates, updates I expect 100 a day, but those 100 coming within a narrow, 1 hour time frame). I have found it is more cost effective to simply revisit a feature that's performing poorly and design it to the new loads rather than letting programmers go on their own devices which will result in them programming for every contingency. I have not dealt with anything that needed to scale quickly, like Facebook or such, but at that point the programming plays second fiddle to the need to scale and you'll see all sorts of hacks that deal with how the program is being used at such a large level that would have been near impossible to predict in the beginning --- or so I'm told.
posted by geoff. at 6:11 PM on May 7, 2009

See The Mythical Man Month. Adding more programmers to a project, or adding more hours per developer will not necessarily bring the project to completion any faster. Paradoxically, this can even cause the project to become later.
posted by ijoshua at 6:22 PM on May 7, 2009

Just because I wrote A program doesn't mean I know ALL programs, or even YOUR program.

Debugging your visual GUI application by voice over a phone line is one of the tortures used in hell.

If your program crashes and you can't provide evidence or repeat it on command, then we have find evidence or repeat it ourselves.

Sure, the guy across the street is cheaper, but that's because he's planning to charge you every year for the rest of your life and intends to hold your DNS name hostage if you don't pay.
posted by pwnguin at 6:28 PM on May 7, 2009

The websites cheap programmers write may only be secure through obscurity; and you probably won't find out until you've lost their business card.
posted by pwnguin at 6:30 PM on May 7, 2009

Every good engineer's first response to a hard question is "that's impossible." It is in fact, not always the case that it's "impossible." Unfortunately, not everything that's impossible is provably impossible.
posted by pwnguin at 6:34 PM on May 7, 2009

Price. Speed. Quality. Pick two.

Anything else is defying the laws of physics, economics, or both.
posted by cgg at 6:36 PM on May 7, 2009 [4 favorites]

Not only do they not understand what we do, they don't even know how much they don't know.
posted by jeffamaphone at 6:36 PM on May 7, 2009 [2 favorites]

Coding is iterative. We may come up with a solution quickly, but then we may return to it when we found out a better way to do it. The longer the project goes, the slower it becomes to add new features, because we find things that we now recognize that should have been done otherwise and use time to fix them. However if we don't have time to do that kind of "gardening", and if the code wasn't top quality and rigorously tested from the very beginning, the code grows into a messy jungle. That gardening isn't only about making existing code better, but it helps coders to keep track on what there is in the code and how it works. It may not look productive, as it doesn't give any visible new features, but it is necessary.
posted by Free word order! at 6:40 PM on May 7, 2009

That programming and its friends aren't like digging ditches or making burgers. Sure, you can reuse code (sometimes, other times it isn't practical), but often you're doing something new.

That hooking up to another vendor's application is often horrific.
posted by adipocere at 6:50 PM on May 7, 2009

When you're writing your specs, or thinking about how a feature should work, give LOTS of thought to the edge cases:

- What should happen if the user does something totally unexpected? Non-sensical? Malicious?

- What should a screen/table/chart look like in the worst possible circumstance (e.g., there's too much data? Too many extreme results? The text is too long?)

The reason this is so important is that, when you're thinking about a cool new feature, you're thinking about how great it will be under optimal circumstances. And, under those circumstances, it should be relatively easy to build.

However, good developers are trained to think about the edge cases, and that's where all the real work is. Typically, only a small fraction of my code is focused on managing the optimal case; the bulk is focused on handling the dozens of possible exceptions and unexpected/unanticipated combinations.

So, when someone asks for a new feature, and I give them an estimate that's 4x higher than they expected, it's because they haven't thought about all the work I'll need to do to handle the edge cases.

It'd be nice to have a manager who appreciated this.
posted by stuehler at 6:56 PM on May 7, 2009 [5 favorites]

When you're reporting a bug, do not try to guess what the cause is. Report the symptoms only, and get as much information about the symptoms as you can (version numbers, copies of whatever data may have been choked on, etc.). If at all possible, figure out how to reliably reproduce the bug.
posted by equalpants at 7:19 PM on May 7, 2009

Actually, I wish my non-technical peers and managers understood better that software engineering solutions are more people-and-organization solutions than they are lines-of-code solutions.

If you work with very good, well-rounded developers, a trust relationship with us is priceless. Developers work around things all the time... it's what we do all day every day. If there are trust issues with you -- if you wheedle down our time estimates, if you micromanage solutions, if you abandon us to bureaucracy -- we will work around you as well. That's almost impossible for a team to recover from. Be an uplifting, nurturing intermediary between us and the clients and give us interesting problems to solve and we will walk into fire for you.

If you hire bad (lazy) developers you are in for a special kind of Hell. Google "technical debt".
posted by mindsound at 7:20 PM on May 7, 2009 [3 favorites]

I've marked a few of these as "best answer" because they were directly germane to my project experience. But I honestly don't think there's a single one here that isn't useful to me on some level. Thanks, and keep them coming!
posted by hayvac at 7:30 PM on May 7, 2009

Seconding The Mythical Man Month. I recommend that as a compulsory reading for anybody who has to interface with software developers.
posted by joewandy at 7:34 PM on May 7, 2009

Seconding what mindsound said.

In my current situation our team has been given a fixed date, an ultimatum that our jobs are on the line, and the business/users are still discussing the specifications and requirements. They are putting out memos about new procedures, emphasizing that no new work shall proceed until design and approval is complete, and having meetings, lots of meetings. I feel like asking them if they wanted a house built in another city in time for their children to start school in early September, would they still be discussing how many bedrooms they wanted or whether the house should be brick or frame in May.

It's sad. They can only lay us off once, but they'll be stuck with whatever junk system that results from such bureaucratic design. Good programmers do care, but we're only human.
posted by forthright at 8:52 PM on May 7, 2009 [1 favorite]

-Specs should include a detailed explanation of how I want the end-user experience to go, not a description of how I think it should be done on the back-end (because I have no idea).

-It's valuable to learn enough about the technology to have an intelligent discussion with the contractor. It is not valuable to use that tiny bit of information to ask dumb questions.

Disagree. Granted, I'm not a coder, but I have been a manager in a technical field, often over techs doing things I have no specific in-depth expertise in.

You do want to know as much as possible about the back end. You don't have to tell them how you think it should be done, but they should be able to explain it to you and answer dumb questions to your satisfaction. They may not like it. They may make fun of you for it. Too bad. Peruse the Daily WTF for reasons you can't let people do whatever TF they want just because you don't know as much as them. It's your money.

You should ask lots of dumb questions. That's how your questions become less dumb, and at the very least trying to explain something only forces the explainer to think through his beliefs a bit more closely. Often your question won't be as dumb as you thought. Just be careful dumb questions don't become dumb demands, and that you don't turn your programmers into unpaid personal university professors and you should be ok.
posted by ctmf at 9:02 PM on May 7, 2009

Sometimes a request that might seem very simple can create a lot of work due to the unforeseen. (In a recent case a client wanted to "just put another button in there". However, due to the design requirements, technical constraints, and localization issues another button couldn't fit on the screen where the client thought it could. It ended up taking a redesign of major visual elements to make it work.) Conversely the opposite can be true. Something that you might think is horribly complex could be relatively simple.

Justify and elaborate on feature requests. Bad feature request: "Can you put a button in there that does X?" Better: "We'd like to be able to do X because of Y" (Followed by a discussion of both X and Y.) This lets the developer devise a solution that will not only meet your needs but will be deployed correctly rather than just cramming something in that doesn't work well.

Software development often has little to show early on. It's not like building a house where you can see the walls as they go up and measure progress based on what you can touch. At times it cam be like those Magic Eye stereograms. You can look at it a long time and see nothing, then one day *poof* it's a magic unicorn. Pushing to see visible results early can slow down development as features are jury-rigged to please the client, then have to be redone later as they fail to perform as needed. (See above: Fast, Cheap, Well done. Pick two.)

Related, everyone wants projects to start moving ahead as quickly as possible. For application development "starting a project" is not synonymous with writing code. It's about planning, planning, planning. The more and thorough planning that everyone does the better the final product and the faster you'll get it.

Budgets (time, money, and resources) are based on experience doing something similar before. Chances are there isn't something too similar to what you're developing, or you'd just use that. Because of this there's a good chance that some budget item will be horribly wrong at some point. Identify this ASAP to keep your project from stumbling.

A good contract programmer will pester you with questions about what should happen when. (again, edge cases above.)

No mater what type of software you're developing, Game Developer Magazine's project postmortems are a good read for anyone involved in software development.
posted by Ookseer at 10:30 PM on May 7, 2009

Ookseer is spot-on about pressure to see early results being counterproductive; many projects involve more effort going into creating demos than the actual product, simply to keep a jittery account manager and/or client happy.

There are basically two types of project for a good, enthusiastic developer. The ones where they can apply their expertise, there's give and take with the client, and it's clear the final product will be pretty good. Developers will often go way beyond the budget/spec to ensure they can be really proud of a project like this.
The other projects are ones where it becomes clear the client is difficult, the requirements list is full of bad ideas that can't be dropped, and overall it's obvious it's a dud. A developer will write-off such a project as dumb coding-for-hire, and do the minimum to get through it and get paid.
posted by malevolent at 12:17 AM on May 8, 2009

As a good designer and an OK developer, let me add that if you have both design and coding going on, be sure that those two parts of the process can speak to each other. Unless you hire a jack-of-all-trades like me (OK for your small standard web site, not a good idea for an enterprise-level shopping cart) don't let the designers dictate code and don't let the developers try their hand at design. If you're going to go through the trouble of hiring good devs, go through the trouble of hiring good design.

Don't get hung up on specific technologies (unless there is a compelling business reason). You might find the perfect dev but she only does PHP, or you might find the perfect dev but she only does .NET. It's better to find a great dev team and let that dictate the technology rather than buying into a technology and thereby limiting your dev choices.

If your project is really complex, consider paying your dev team to write a complete, detailed, technical spec before any real money goes down the crapper. Spending 10% of your dev budget getting that spec written can really make the other 90% of the money go much further. In this scenario, your own spec, dictating what you want the product to do, is a quiz, and the technical spec are the devs answers. Any hand-wavy stuff in such a spec should make you pause.
posted by maxwelton at 4:34 AM on May 8, 2009

Don't tell a developer what you want a piece of software to do, tell them what problem you want it to solve and then let them figure out the best way to achieve that goal.
posted by Civil_Disobedient at 5:00 AM on May 8, 2009

While not as directly germane to your question:

As with a lot of other mental work (writing, video editing, architectural design, etc.), programmers usually need to balance a lot of 'big picture' context about their project in mind. It takes some time to get into the right mindset, and if they get interrupted, they often lose it and have to start over.

When you startle a programmer with a question, you may be jerking them out of that mindset. (Tapping them on the back is worst.) While responding with serious irritation or a deer-in-the-headlights glare probably seems like poor social skills, keep in mind that you just dragged them back down to earth without warning. Similarly, I had the same professor for Spanish and German for one semester in college (in the same room!), and a few times I got mixed up and used the wrong one. The professor, who was vastly more acclimated to thinking entirely in Spanish than I was, would get really confused and freeze for an instant if I said something in German. He'd have to suddenly switch mental languages, and it was a bit of a shock.

If you don't need an immediate answer, e-mail is much better, because they can get to it when it won't blow their focus.

For a lot of other ideas about how to enable programmers to work at their best, check out Peopleware by DeMarco and Lister.
posted by silentbicycle at 5:23 AM on May 8, 2009

Three things come to mind right away:

Specify what you want rather than how you want it to be done.

Respect that a coder is a domain expert and that that expertise wins out over the expertise of other experts involved in the project because, no matter what, it must all be reduced to code.

NOBODY can write a spec anticipating all the needs unless the scope of the project is tiny. As the code comes to life, the stakeholders will see new possibilities (and corner cases) and ones no one could have ever anticipated. The longer the project takes the greater the chances of the emergence of "new facts," new cases and new ideas. Managing those new ideas and the risks they inevitably engender is a key responsibility of the project manager. A good client will allow themselves to be managed.
posted by bz at 8:35 AM on May 8, 2009

Well... the coder expertise doesn't necessarily "win out" but needs to be respected. I have noticed that it is often not respected.
posted by bz at 8:37 AM on May 8, 2009

Something I wish more nontechnical and more technical people understood: a good user interface can't be added at the last minute after all the coding is done; it's integral to the product and has to be planned for from the start.
posted by ook at 9:11 AM on May 8, 2009 [1 favorite]