My other car is a cdr.

August 18, 2005 12:21 PM

What are some basic software-development facts that someone interacting with developers should know?

I have a friend who is applying for a job where she would work with programmers to design features for a product. It's the programmer's job to deal with the complicated technical details, but she needs to be at least somewhat conversant in the basics. She's done some programming while working in a lab before.

I'm a programmer, so I can help her out from my perspective, but I was hoping to get some insight from other people about what's valuable.

posted by clarahamster to computers & internet (11 comments total)

I think this came up recently. Yeah, here we go.
posted by Leon at 12:24 PM on August 18, 2005

damn. i searched, but i didn't find that. I was looking for things more relevant to application development than web development though.
posted by clarahamster at 12:27 PM on August 18, 2005

In general terms...

Your friend may need to know two languages and learn how to translate from one to the other. First, know how the clients speak and what their expectations are for the software being designed. Second, know how to communicate with the developers in terms they understand.

Iterative design is a good thing.

Developers sometimes over engineer things. Try to keep them from doing this.

Usability is critical from a client's perspective.

From my POV, every project needs clearly defined and documented requirements.

I'm an analyst working in application development. Part of my job involves design and design review. A lot of my job involves direct interaction with the developers. Feel free to email me with specific questions.
posted by onhazier at 12:46 PM on August 18, 2005

I write developer documentation, so I have somewhat similar needs: I have to work closely with developers to get knowledge out of them.

Learn how to read the planning tools used by your developers. Back in the day it used to be flowcharts and data flow diagrams; these days it's static structure digrams and sequence diagrams. If your shop uses UML, a good primer on that is O'Reilly's "Learning UML."

Some database design principles would probably be helpful if your developers are doing anything with databases (the concepts of normalization, joins, etc.). Also some object-oriented concepts (what is an object, what are methods, the difference between is-a and has-a relationships, subclassing and inheritance, polymorphism, stuff like that). The basic language features of whatever language is being used; perhaps she won't need to write code but she should be able to look at code and distinguish variable and object definitions, comments, and high-level structures such as conditionals and loops, and get a sense for how the various parts of the system work together. Design patterns (e.g. model-view-controller, factories, singletons, the idea of refactoring, etc.) -- the canonical reference is of course the Gang of Four.

If you use a particular development methodology, some knowledge of that may come in handy (e.g. if you do XP, you will need to know what pair programming is, what stories are, what velocity is, etc.). At the very least she should know how your process works in general terms, how teams are structured and managed, etc.

She may not actually end up using all that stuff but if she's conversant with it, the developers will take her more seriously than someone who just spouts buzzwords like "XML compliance."
posted by kindall at 1:02 PM on August 18, 2005

Computers are dumb. They need to be told everything, and have every case covered. If the features and specification don't cover every edge case and possibility the developers will inevitably make assumptions and fill in the missing functionality.

Good developers recognize this and will likely badger your friend for clarifications on what seem like extremely minor points. Bad developers don't recognize that they are making assumptions and build their biases into the system.

The good developers can be much more of a pain in the ass than the bad ones, but you'll get far fewer unpleasant surprises in the end.
posted by true at 1:02 PM on August 18, 2005

I don't really have much to add, but I salute you for the title. It rocked my socks.
posted by therealadam at 2:15 PM on August 18, 2005

Wow. Excellent question. Here's my shot at it:

1. Computers (and programmers) are literal-minded. Programmer types, and "regular" people have brains that work in different ways. This is not a bad thing, just something you have to be aware of. You cannot assume that a new program will work a certain way, or look a certain way, unless you make that explicit. It drives most people crazy to have to be explicit down to the (seemingly) smallest detail. These details are where programmers live. If you want to talk effectively with them, you will have to be able to walk the path with them.

An adjunct to this is that it is usually better to be blunt, direct, and achingly direct in your communications with technical people. They deal in a world of absolutes, and the kind of person that is usually attracted to programming as a profession is usually more articulate, more inner-directed, and more comfortable with structure than, say, your average musician.

2. All estimates are too optimistic. Not one in one hundred programmers can provide accurate estimates of how long a substantial project will take to complete. Many highly-successful analysts and managers have developed their own rules of thumb over the years. The most common is to multiply programmer estimates by 2.6. It is fascinating to me, and a little scary, how many different development managers I've known have independently arrived at precisely this number.

3. Changes to an ongoing project are vastly more complicated and expensive than you would think. Don't fall into the trap of thinking that because a change looks simple to you, as a user, that it would actually be simple to implement. Computer programs are vast and complicated things, with all kinds of dependencies and interconnections that are not evident to a user. Changing the one "simple" thing that looks easy may easily reverberate to a dozen other things that have to be adapted. It is far, far better to work longer on requirements at the beginning of a project than to make changes to it mid-stream.

4. Programmers take enormous pride in their work. It is interesting to me how most non-technical people interact with technical people. They treat programmers like house painters: "just move this over here, and add a field." Effective organizations hook programmers into the business objectives and purposes for software. When this is done, technical people orient their brain towards these objectives; and produce vastly more usable, appropriate, adaptable programs. But far too many organizations just tell them where to place a button, or field, or to narrowly implement today's company policies.

Programming is problem solving, and the people who choose programming as a profession are usually exceptionally talented problem-solvers. If the problems they are given are narrowly technical, so will be their solutions. But if you pay the the compliment of making them your partner in finding an optimal solution to a business problem or goal, you'll come up with better solutions, and have happier programmers, as well.


One of the truly amazing things about software development is the difference that good management can make. Microsoft hires tens of thousands of the smartest people on the planet, and turns out largely lackluster products. On the other hand, I've seen many well-managed, properly-motivated small teams of 6 or 8 people turn out astonishing, paradigm-changing programs.
posted by curtm at 3:12 PM on August 18, 2005

Good advice. Scour the archives on Joleonsoftware.
Motivating developers is difficult. They'll know what tricks you're trying to play before you play them, and they're quite honest about what they can do and what they want. If you want to get on with them, throw the motivational handbook in the bin and be honest back. If they say they can't do what you want in the time needed, ask them whats going to take the most time and what features can be ejected. Never assume that you can trick them into working harder. That's just one way to drive them onto slashdot.
posted by seanyboy at 11:44 PM on August 18, 2005

I work primarily freelance, so I deal directly with my customers.

From my end, the thing I want most is that my customers understand that what seems simple to them is not simple to create. A request as seemingly trivial as printing a customized header on images can lead to literally hours of working out the linear algebra, tinkering with raster caches, and convincing the infernal thing that 3.0==3.0 on both Mac and Windows.

I can do it, of course. But, I didn't include that in my original quote, so it's going to cost you extra in both money and time.

Tell your friend that she'll probably be most successful if she treats the programmers with whom she works as creative partners and not merely tools.
posted by Netzapper at 12:18 AM on August 19, 2005

important: it is NOT a waste of time to preplan applications as completely as possible. there is nothing more annoying to a programmer than a designer who wants to play it by ear and change basic application concepts (which are different for a programmer and a designer) midway.
posted by mirileh at 1:18 AM on August 19, 2005

Here is one I've not seen mentionned so I'll throw it in. By nature developers hate ineficient things. The prime example in the business world is meetings. Useless or ineficient meetings are the bane of a developers existance.

Do what you can to make meetings infrequent. When they do occur make sure they are short, to the point and useful. A simple question for meetings is to ask yourself this: "Does everyone at the meeting need to be there?" You may think so but try to think like a developer when ansering this question.
posted by cm at 4:56 PM on August 19, 2005