Fog Creek Software
Discussion Board




Fundemental Laws of Software Development part 2

7. CHOOSE A TECHNOLOGY THAT IS APPROPRIATE FOR THE APPLICATION.
Making a technology, which was meant for a different situation, bend to meet the needs of this application's situation will result in additional time being spent making the bend. This additional work may never fully succeed in meeting situational requirements.
The consequences:
  Loss of product quality
  Loss of productivity

8. CHOOSE SOFTWARE TOOLS THAT MEET PROJECT WIDE USE REQUIREMENTS.
Software tools that are widely used can be difficult to choose for projects. This is because of the wide variety of requirements that different project team members will have. Compromise is quite often likely to occur. The key here is to look at the compromises in terms of product quality effect and productivity effect across the project. And since compromise is likely, the software tool should be adaptable. Ease of use should be another consideration in order to avoid extensive training of many users.
The consequences:
  Loss of product quality
  Loss of productivity

9. PRODUCT ASSEMBLY AND SCHEDULE COORDIATION.
Coordination of large groups is difficult; generally areas of work are related through dependencies. These dependencies establish a schedule requirement for when areas of work are to complete. When areas of work deliver out of order, additional rework is required of the areas of work dependant on the out order delivery, failure to do the rework will likely lead to loss of product quality.
The consequences:
  Loss of product quality
  Loss of productivity

10. NEVER BREAK YOUR CUSTOMER.
Customers come in two flavors, internal and external. The external customer is the one outside of the project and usually takes delivery of the project's product. The internal customers are those people in the project, but outside the work area and dependant on another work area. Understanding whom the customer is the first step. Creating insulation between the customer and producer is the next step. This insulation is an agreement that the two parties shall follow to avoid the producer from causing the customer's work to become broken. In this agreement the customer agrees not use the product in a way that was not intended, and the producer agrees not to change the product in a way that would affect the customer. If it becomes necessary for the producer to do something, which breaks the customer, then the obligation is on the producer to communicate the problem and to work with the customer to lessen the resulting change. In software this is called an Application Programmers Interface (API). API code is identified as non-changing, both in signature and behavior. API code is never removed or deprecated; it only goes into a non-maintained state. If it is necessary to change API code, a new API is created to exist with the old, and the old API remains unchanged.
The consequences:
  Loss of product quality
  Loss of productivity
  Loss of customer

11. SEEK THE LEAST COMPLEX SOLUTION.
Adding complexity without adding to product quality causes a loss in quality. Complexity is difficult to produce and maintain. It is imperative that simplest solutions are found to a quality to product.
The consequences:
  Loss of product quality
  Loss of productivity

12. DEVELOP AND TEST WITH REAL DATA.
Simulated data is all right for initial development, however it generally does not behave exactly like real data. This usually leads to problems after delivery to the customer.
The consequences:
  Loss of product quality
  Loss of productivity
  Loss of customer

13. USE STANDARD ENGINEERING PROBLEM SOLVING.
Define the problem, state the given, and create the solution. When the given is not sufficient gather more data based on the fact available. This methodology maintains the focus on the problem and helps to organize solutions.
The consequences:
  Loss of product quality
  Loss of productivity

14. ORGANIZE CODE TO MINIMIZE DEVELOPMENT CONFLICTS.
One problem that occurs in poorly organized code is that multiply developers need edit the same code at the same time to add functionality. This leads to difficulties in merging the code to capture all the functionality without adding bugs. Code needs to be organized in such a way as to avoid large file sizes and code structures that create a single add point for addition.
The consequences:
  Loss of product quality
  Loss of productivity

David Hickerson
Friday, December 06, 2002

True, these "laws" are just common sense.

The real question IMHO is why they are so often ignored and so the project ends in failure. Understanding forces that lead to not applying such common sense would be more useful.

Does anyone knows a good book or web articles on this subject ?

Robert Chevallier
Friday, December 06, 2002

Also look at http://www.cs.usfca.edu/~parrt/doc/devnybbles.html

Robert Chevallier
Friday, December 06, 2002

Jerry and Robert thanks for the validation.

Yea, I thought these were obvious and you would think that any project would at least get these right, however the project I am in fails everyone of them.

David Hickerson
Friday, December 06, 2002

David,

Do you have the beginning of an explanation why ?

Robert Chevallier
Friday, December 06, 2002

There are a few reasons. Management was making design decisions based on politics. Also, management organized the groups in by specializations, such that perspectives are so different between groups, that is causes communication to be difficult. Architects haven't coded for years, are completely separated from implementation groups, and don't test there design decisions. Process was implemented to meet some certification level, yet they never got the point of why process is important and how to improve it.

David Hickerson
Friday, December 06, 2002

>Does anyone knows a good book or web articles on this subject ?

Rapid Development by Steve McConnell.

http://www.stevemcconnell.com/


See also comment on previous thread, re. writing, such that people *want* to read.

Justin
Friday, December 06, 2002

David, it seems you really want to discuss the failings in your present environment. It would been more interesting if you directly addressed that.


Friday, December 06, 2002

David,

Welcome to the wonderful world of software development.

A Fundamental Law of Software Development

1. Most programmers who get paid to develop software for someone else hold little influence over how the development process will be conducted.

I believe Joel has written a few sentences about some of his past employers and the stupidity he has encountered and had to endure.

The Career Programmer: Guerilla Tactics for an Imperfect World by Christopher Duncan

If you are looking for some light and entertaining reading, I suggest you check out this book. Will you learn anything by reading it? I doubt it. It simply explains/confirms why Dilbert is the poster boy of this industry.

one programmer's opinion
Friday, December 06, 2002

I know how this feels, I once wrote a little list myself.  But the truth is that some orgs just don't care.  They don't want to develop good software, nor do they wish to change.  Even when reality stares them in the face and tells them they'll die if they don't change, they will simply just work harder at making the same mistakes.  That way, they think no one will blame them when they fail.

What that means is that you'll have to accept some level of mediocrity if you stay in this org.  Possibly you can create your own team and work separately from the others.  (I'm actually finding some success doing this.)  Otherwise, you can seek out the good orgs you've worked for and stay put when you find one.

The sad thing is that I actually have some smart technical coworkers, but I've slowly lost the ability to look most of them in the face.  Just a job.

anon -- so not to hurt coworkers
Saturday, December 07, 2002

David,

I generally agree with (almost) all the items you listed, but above all I think there is a "meta-rule", which you have been follwing anyway:

MetaRule: REFLECT ON WHAT YOU ARE DOING, AND LEARN FROM YOUR EXPERIENCE.

What delights me most is that you did _not_ say, "folks, after some thinking, I came up with some great ideas", but you wrote, "after some years, I've observed the following guidelines".

In an area such as Software Development, which keeps changing so fast and where everything seems so brand-new and never-known-before, people tend to underestimate the importance of reflection and experience.

I, on the other side, claim that experience is one of the most precious ressources one can have, and I am always astonished that there are some sites (such as JoS) where these invaluable gems are shared for *free*.

Roland
Saturday, December 07, 2002

Your "fundamental laws" look just like all the business management books that everybody is always making fun of, complete with careful numbering, buzzwords, meaningless phrases ("don't break your customer") and even a handy bullet-point list of what goes wrong for each rule you break.

Management books obviously turn a healthy profit (otherwise there wouldn't be so many of them), but I think most of us here like Joel's site because he manages to avoid the buzzwords and fluffy writing that make those management books so worthless.

Foolish Jordan
Saturday, December 07, 2002

How about ...
Right tool for the job; Wrong tool for the money

G.D.
Saturday, December 07, 2002

> Right tool for the job; Wrong tool for the money

Can this ever be the case? I think, choosing a "tool" (method, staff, ...) for a project only because it appears cheaper, even though you know it will not do the job properly, is always very shortsighted. If "right for the job" is "wrong for the money" then something in the whole project plan is seriously wrong.

Have fun,

Jutta Jordans
Monday, December 09, 2002

Anon, I sympathise with your frustration. Many organizations are not devoted to writing decent software on time.

Some of them won't even fail... Sometimes good software is simply not important to a particular organization. Sometimes on time is not important either.

It's painful, but as the old saying goes "If you can't change your organization, change your organization."

During my last organization hunt I interviewed a company that needed a Director of Software Development. When I investigated their culture and style, the message I got was that when push came to shove, they did not 'manage' development but simply whipped everyone into working longer hours.

But outside of whipping, there was no change in management: their attitude was 'empower, delegate' until things went wrong, and then whip. I decided this company did not value software management.

I rejected their offer in favour of a lower authority position with a company that is trying its best to refine and develop its processes.

I put my money where my mouth is, and I've gotta tell you, it was a real eye opener to put myself in the position of paying for my principles!!

--
Reginald Braithwaite-Lee
http://www.braithwaite-lee.com/

Reginald Braithwaite-Lee
Monday, December 09, 2002

What I have seen so far is that getting 12 right answers on Joel's test is hard. In a start up company like MUSE Technologies, we building our process as we went. I believe that we were on the road, but it slow because of the needs of delievering the next application or demo. As developers we did what could, when we could. I believe we would have gotten there eventually.

Now as for the mega company I contracted with currently, they make process decisions from above. These people making decisions do not live with them day to day and do not have first hand experience with process. So in a sense, the motivation to fix it is not there. Plus, the reason they even implemented a proces was to satify a software certification. It was a paper work drill.

I would bet that a large percentage of the companies developing software that can answer 12 out 12 to Joel's test are lead at the ground level, when it comes to process.

The point is we need a starting point, when implement from nothing. Say we take the fundamentals as start and build the processes from there. And what I want to define is a good starting point. Something I can use to help my company build software better. I moving out of the contract position to company projects on a small team. Hopefully, I can influence the process to get to a 12 out 12.

It is really the senior engineers that have to make it work, not management. Management needs to support the engineers and delegate ownership to them.

On the subject of process, the book I recommend is Mary Waltons, "The Deming Method." Demming was one of the orginators of quality process improvement in factories. It gives a good understanding of the why and the how in manufactoring. These concepts which these software certifications are trying to implement, though fall short if implemented without the understanding which this book provides. Granted that software development is much harder and is like trying to control the process of dozen authors trying to write the same book together at the same time. It lacks easily definable repetition.

David Hickerson
Tuesday, December 10, 2002

*  Recent Topics

*  Fog Creek Home