The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
TechInterview.org
CityDesk
FogBugz
Fog Creek Copilot


The Old Forum


Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Development Principles

I was starting a product development shop (which failed for other reasons (:=)), and I created these 18 principles of sw development. Curious what you think.
=====================
1) Vigorous debate is encouraged. Everyone can challenge everyone, and everyone can be challenged. No exceptions. However, the time for debate is finite, and when the leader makes a decision after hearing all sides, everybody needs to accept the decision and get behind it.

2) Sometimes people and teams make mistakes. Much worse than making a mistake is not admitting and fixing a mistake. Mistakes are much easier to fix the earlier they are discovered, agreed upon, and dealt with. Once a mistake has been fixed, it is not to be repeated, but it is not to be dwelt on, either.

3) Documentation is not a necessary evil. Documentation is an integral part of every piece of software. It needs to be clearly written, in good English, with a eye towards teaching someone else to understand the code. You need to put yourself in the place of the person who is going to inherit your code; do you want him/her to think well or poorly of you?

4) Everything we do needs a purpose. If there is no purpose to what is being done, then let's not do it. If there is a purpose to what is being done, that purpose needs to be known up-front and needs to be fulfilled.

5) The right tool for the job. There is no one tool that fits every job. Everyone who develops software for us needs to be flexible as to what tool to use, and what tool they are willing to use.

6) The point of software is to solve problems. The point of software is not to use tools. Unglamorous tools are frequently the best tools to use; in other words, no resume padding by using expensive, "hot" tools.

7) Testing is key. Testing is not separate from coding. Coding is finished when the code works.

8) You always need to know in advance what you're optimizing for.

9) You have to know, in advance, what is meant by quality, and what is meant by success.

10) Programming computers is easy, programming people is hard. You always need to think how someone is going to be using your software.

11) Generally speaking, there are 4 measures of sw quality: does it solve the users' problems?; how easily can someone else take over the software?; how easily can the software be adjusted to new requirements?; how scalable is the software?.

12) Meeting specifications by a date is a milestone, it is not the reason for doing anything, nor is it an end in and of itself.

13) Keep it simple, stupid. Life is too complicated as it is.

14) Clarify, don't simplify. I know this contradicts #13, but Richard Saul Wurman was still right.

15) The bias is towards prototyping, though it may not always be appropriate in all situations.

16) People need to do all parts of the lifecycle. Work with the users, get the specs, develop, test, document, administrate. No prima donnas.

17) Make initial decisions very carefully.

18) Name things carefully. A rose by any other name does not smell as sweet. The name of something is how it is understood by others.
Steve Hirsch Send private email
Thursday, August 10, 2006
 
 
They sound like chapter titles for a self-help book
S. Tanna
Thursday, August 10, 2006
 
 
but its ok
Capablanca Send private email
Thursday, August 10, 2006
 
 
Number 6, while possibly absolutely correct for your situation, may make it find difficult to hire good developers. Good developers are interested in furthering their skills, and like it or not, probably do have an eye out for opportunities to learn tools that will be useful in future gigs.  You can call it resume padding if you like, but I bet your developers would be happier using C# or Java or Ruby than COBOL, JCL, or TurboPascal.

Just my opinion, but I have to say that as a developer, I look more favorably on potential employers that are "up to date" and using current technologies and practices.  If nothing else, it shows that they are plugged in to what's going on in the field.
Jesse Send private email
Thursday, August 10, 2006
 
 
Steve:

Is your intention to give this to developers? If so, what is your purpose? Tell them they are stupid in a militaristic style?!

Purpose accomplished.
Ms Peeved Ghost
Thursday, August 10, 2006
 
 
Steve,

Your views are similiar to mine.  Don't listen to peeved ghost - he's just, well, peeved.  Thinking professionals don't get put out so easily (in my opinion of course). In our company we have a document posted around the place that everyone is made familiar with when they join.  It's called "Our Philosophy" (naf name I suppose) and it encompases a few of the above points.  Particularly your first point about  rigourous debate and decision making.
Paul Norrie Send private email
Thursday, August 10, 2006
 
 
I would be insulted if an employer presented this list to me.  Most of the items are vague truisms ("Make initial decisions very carefully".  "The right tool for the job.")  And maybe it's just me, but some of this seems patronizing ("Everything we do needs a purpose.") almost to the point I would just walk away.  I'd wonder, Why is somebody telling me this?

Question: how are these 18 "principles" specific to sw development?  If I'm not doing sw development, do you advocate I should make initial decisions arbitrarily and use the wrong tool for the job?
William Dowling Send private email
Thursday, August 10, 2006
 
 
My 3:
- be aware
- think before you act
- be efficient
Dino Send private email
Thursday, August 10, 2006
 
 
This was an email sent to management, not a check list for developers. Sorry I didn't make that clear.

#6 is designed to weed out people who are obsessed with being on the bleeding edge. I'd want people who are juiced about solving the problem at hand, not figuring out the latest syntax.

You know, my project just got trashed, and I'm on the beach. Maybe it's time to create that course, "Programming People is Hard"--a software development course for programmers and the users and managers who love them"
Steve Hirsch Send private email
Thursday, August 10, 2006
 
 
Quickly ...

- the list is too long (not #13 !)
- too vague, or rather, at different abstraction levels (don't write code at diff abstraction levels!!)
- too many contradictions

In fact let me elaborate on the last point - everything is a balance of contradictions. Handing out absolutist or psuedo-absolutist rules (no, not everything needs to be debated - the benefit doesn't always exceed the costs of debating, or even asking the question).

An employee needs to know that (a) there will be goals and purposes, often contradicting each other, competing for their time/money (b) that someone has to make a decision what balance of goals to follow; (c) who chooses and how to choose; (d) how to evaluate the results of the choice so that more time isn't wasted in having made a bad choice.

That's the top level stuff for me (encompassing rules 1, 2, 4, 17, etc). Now make a seperate small list for other levels.
Spinoza Send private email
Thursday, August 10, 2006
 
 
I like most of the principles.  When people get emotional or under pressure, they forget about some of these things, so having them written down is helpful.
Doug
Thursday, August 10, 2006
 
 
Dear Mrs Paul Norrie

You wrote:
> Don't listen to peeved ghost - he's just, well, peeved. 

Generally, you can look at the title of a person and assume that:

Mr = MALE,
Ms = FEMALE
Miss = FEMALE
Mrs = FEMALE

Did you notice how I signed my name **** Ms **** Peeved Ghost?

Ah, no harm done, heaven's gates are still swinging.
Ms Peeved Ghost
Thursday, August 10, 2006
 
 
Maybe he thought that, since you're not using your real name, you could be lying about your gender as well...
...
Thursday, August 10, 2006
 
 
There's a man on this site who uses the handle "Sassy". Would have thought him a her, but whatever.

On the internet, nobody knows you're a dog.
Steve Hirsch Send private email
Thursday, August 10, 2006
 
 
"Dear Mrs Paul Norrie" -- I cracked up laughing when I read this.  Very funny!  By the way, when I see "Ms", I usually assume school teacher.
SomeBody Send private email
Thursday, August 10, 2006
 
 
Is it supposed to guide you in making development decisions?

It'd be a struggle to find any item on the list that any of your people are likely to disagree with (at least publicly) - even though some of the items contradict each other a bit..

So, I can't really see what the point is.  How is it supposed to guide you in making difficult decisions and choices?
S. Tanna
Friday, August 11, 2006
 
 
Somewhere in there it should say something to the effect of, "the point of this whole exercise is to make money" (unless you work for the goverment in which case s/make/spend).

Maybe that's the other reason it failed, too much time on programming details and not enough on business details?
Greg Send private email
Friday, August 11, 2006
 
 
The idea was that putting things in writing makes them more concrete somehow. I was the only native American developer in an Indian company, not all of those points are universally held as Truth. In particular, point #1.

The main reason for the failure of the product division was that the people who ran it deceived the money people into thinking that products were going to be throwing off cash in 6 months.
Steve Hirsch Send private email
Friday, August 11, 2006
 
 
While I don't disagree with most of the list I did find a few items questionable.

Some items seem to spend a great deal of time being negative and describing what NOT to do. I think the list would be more effective if all items presented a positive goal to strive for rather than something negative to avoid.
NathanJ Send private email
Friday, August 11, 2006
 
 
I thought the list was ok, but confused two different sets of principles. One set is general team-interaction stuff, and the other is oriented to software development. Maybe you need two lists, both much shorter than this one...
Jeff Kotula
Friday, August 11, 2006
 
 
I like #16 especially, and think that developers that do manage all parts of the life cycle learn how important it is to do each part well and to treat each part seriously. I also agree with some of the other responses, the list could probably be shorter.
Bernard Dy Send private email
Friday, August 11, 2006
 
 
> I was the only native American developer in an Indian company, not all of those points are universally held as Truth. In particular, point #1.

Yes, Indian education system tends to discourage people speaking up with their own ideas to a higher-up.  (I am allowed to say that, being of Indian descent myself, although born and brought up in the UK).

However I don't think you will change that with listing a set of principles (but I guess you have to start somewhere). Instead you are likely to get "Yes I strongly agree we must debate important issues."

Anyway it's all relative.  In my experience, the American idea of vigorous debate, is a whole lot less vigorous (and is more polite), than the average British.



> The main reason for the failure of the product division was that the people who ran it deceived the money people into thinking that products were going to be throwing off cash in 6 months.

Maybe it's just me, but I can't see which of your principles, if applied, would have prevented that problem.
S. Tanna
Friday, August 11, 2006
 
 
Just to elaborate on what NathanJ wrote:

"Some items seem to spend a great deal of time being negative and describing what NOT to do. I think the list would be more effective if all items presented a positive goal to strive for rather than something negative to avoid."

You really need to case the negative points as positives, not because it makes anyone feel better but beacuse a negative is not prescriptive: so long as you do ANYTHING other than what is forbidden, you have satisfied the requirement. If you are looking to change behavior is some specific way, you should indicate what behavior you want, rather than simply saying you don't want the current behavior, otherwise you have no guarantee what you'll get.
Jeff Dutky Send private email
Friday, August 11, 2006
 
 
"Maybe it's just me, but I can't see which of your principles, if applied, would have prevented that problem"

You're absolutely right. The effort was doomed from the start.

Thanks for all your responses. Some good suggestions there.

I do hold differently as to the power of negative commandments, however. Sometimes it is important to step cautiously. Americans tend to be optimistic, and to err on the side of doing something, rather than not doing something.
Steve Hirsch Send private email
Monday, August 14, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz