Dot Net Tricks

Articles about .NET, ASP.NET, C#, Object Oriented Programming and Agile Methodologies
Welcome to Dot Net Tricks Sign in | Join | Help
in Search

Software Theosophy

Programming is NOT Manufacturing

Its been a while since I’ve blogged about anything. I have a new baby, a new house on the way and a new job.  But right now I have an itch to scratch so let me throw it out there for my small but sophisticated audience:

 

PROGRAMMING IS NOT MANUFACTURING

 

When I was in college taking Java and OO Design classes, developing software was likened to building a house.  UML diagrams and the like were blueprints, and actual coding was the product built.  This thought process has permeated our industry so much, that people with years of experience in programming still think this way.  They think that software can be designed using diagrams, use cases and documentation, then built using tools like visual studio and hordes of programmers.  Much of the ardor for OOP stems from a desire to reuse components and form a sort of assembly line process where developers don’t have to think very hard but merely assemble software from pre-manufactured pieces.  Much of the current excitement about offshore outsourcing of programming talent to countries like India and China also stems from this thought process.  After all, if Nike shoes can be made in China, why can’t software?  Finally, the whole waterfall development process is based on the metaphor of software development as manufacturing: Discover, Design, Code and Test.  This process is very similar to what occurs in manufacturing.  The idea that you can discover and design everything up front and then you only have to “build” the product and test it (Quality Assurance) comes from manufacturing.

 

This is all wrong.  I have been reading a lot about this topic lately, and my own experience validates what I’ve been reading.  I have even have started to hate the term “software architect” as it stems from the home building industry which is also a form of manufacturing.   However, I do perfer thinking about software as being similar to traditional architecture a LOT more then thinking of it as “building” anything. 

 

So let’s get this straight programmers and managers: In software development, we are never “building” anything.  We are designing, the whole way through up until the time we compile our code for the last time before a release.  The entire software development process is design one-hundred percent.   

 

Let me put it this way.  One of my first jobs was at Six Flags over Texas amusement park.  I worked in the snow cone booth.  Making snow cones is predictable manufacturing process.  One person gets the cup or cone and fires the machine that shaves the ice.  He fills the cone with ice, and mashes it roughly into the shape of a ball and then hands it off to another guy.  The next guy takes the snow cone and dumps some syrup to it and hands it to the cashier.  The cashier then takes the snow cone and gives it to the customer and takes their money.  That’s it.

 

This is a very simple job that anyone can do.  It required little training or experience.  I was lucky that it was an air conditioned booth and I worked with some pretty nice people.  It was also exceptionally BORING. 

 

There are much more complicated assembly processes than snow cone making of course that may require a lot more training.  But once that initial training period is over, assembly is basically a nearly thoughtless process.  It is repetitive and consistent and is meant to be so. You want the same results every time.  The design of the snow cone was already in place before I ever started my job there.  The design of a car is in place before an assembly worker starts his job.  It was boring to me because I am the type of person that loves to think, loves to problem solve and use my mind actively in a creative way.  In short, I love to design things and that is why I love programming. 

 

Programming is design because we build something new every time.  There are certainly similarities between many projects and common elements and code reuse.  But the whole time I write code or plan to write code, my mind is active, there are decisions to be made at each step and there is creativity involved.  If you have not noticed this while programming you should get out of the industry.  I am not bored.

 

Now design may take many forms.  I may draw on a white board first or write CRC cards.  I may create a short use case or requirements document.  However, all I’m really doing when coding is taking one of these simpler more abstract design and translating it into a fuller more detailed design in code.   I am not simply taking instructions and mindlessly executing them when I program.   I cannot get a bunch of programmers on an assembly line and give them different pieces to build from my documentation in a repetitive, predictable manner.  The programmers must be creative and engaged in their work and their design will differ then what was originally planned despite all our best efforts.

 

The Agile movement is about the only thing that seems to be working to rectify this malady.  Agile emphasizes people over process and understands that programmers are not the same as assembly line workers where you can pull one out if you need to and replace them with another.  Agile recognizes that the design keeps changing because software is “soft” and that design is much harder and unpredictable than mechanically following documentation or instructions the way you would in a manufacturing discipline.  I’m sure agile isn’t a panacea for all software problems but it seems to address at least this one problem.

 

Here are some quick links:

 

Martin Fowler states this much more eloquently than I in his excellent article on agile:

http://www.martinfowler.com/articles/newMethodology.html#FromNothingToMonumentalToAgile

 

Also, see this article on outsourcing:

http://www.forio.com/outsourcing.htm
Published Sunday, September 03, 2006 12:00 AM by Fregas
Filed Under: , ,

Comments

 

Mistercain said:

The time I tried waterfall, it was basically a joke.  Here's why...

I spent about 1 month solid of writing paperwork (the "Documentation") that described every little nook and cranny of the HR system I was going to build.  Once that document was complete we had it signed off on by the "customer" (HR).  Notice that during this time, no software was written and nothing substantially useful was delivered.  (A huge waste of time IMHO)

I (and my colleagues) then wrote the program to spec, debugged it, tested it, and deployed it to an environment where it could be "User Acceptance Tested".  Then the problems began.  It turned out that the documentaiton wasn't really "Documentation", but a political document used for finger pointing and blame placing when "it didn't work".  One glaring problem was that the verbiage in the documentation didn't mean the same thing to everyone reading the document.  In fact, I question as to whether everyone "reading" the document could actually read at all, but that is a story for a different forum.

So, the application started to change based on the feedback from UAT.  The "Documentation" became severely stale and was never kept up to date because we were trying to "deliver" on time.  We did several rounds of UAT and the when the users finally saw what they wanted to see on the screen, we called it a wrap and rolled it out into production.

The long and the short of it is, there is nothing functional about a functional specifications document, you'll never be able to capture anywhere close to a majority of all of the requirements up front so don't waste your time, and the only thing that people will be able to agree on is what they actually see on the screen (which is nothing if you spend a lot of up front time documenting).

Cheers,
:D
September 9, 2006 12:33 AM
Anonymous comments are disabled

About Fregas

Craig is currently the Lead Developer in Fort Worth, Texas for Enilon Group, a web development firm. He has been programming since 3rd grade (using the Commodoore PET) and professionally for the past 7 years. He has written several articles for ASPToday.com and co-authored the book "Beginning Web Programming using VB.NET and Visual Studio .NET" Currently, his favorite programming language is C#, but he has programmed in Visual Basic, T-SQL, Ruby, ColdFusion, ASP 3.0/VBScript, ASP.NET, Javascript, Java and even Pascal. Besides programming, Craig is best known for his cooking and his somewhat offbeat sense of humor.

This Blog

Post Calendar

<September 2006>
SuMoTuWeThFrSa
272829303112
3456789
10111213141516
17181920212223
24252627282930
1234567

Syndication

Powered by Community Server, by Telligent Systems