Geeks With Blogs
.NET Nomad What I've learned along the way

Software development is complicated. Everyone has their own opinion on how it should be approached and from time to time you get little clusters of folks that follow the same mantra, whether it be “agile methods”, “extreme programming”, “waterfall model”, etc. The underlying argument tends to be whether one thinks of programming and development as a science or an art. Before we get into the good stuff I thought it’d be nice if I could express my view on the matter and set some expectations when it comes to my code and even the topics I choose to post about. To me, software development isn’t an art or a science. It lives in that happy middle ground I commonly call a craft.  That's right, I'm a digital basket weaver.

First let's talk about my view on science.  Science is a well defined method of making observations on laws and systems that you did not create and therefore have no control over.  If you understand the system well enough you can influence it and that is what I like to think of as application of scientific principles, or engineering.  One thing is very important here: scientists don't create or produce anything.  For example, Newton didn't create gravity he discovered it.  Further, an engineer building a bridge doesn't defy or change gravity to make the bridge stay up he simply offsets its effect with other forces.  Eventually gravity wins and the bridge falls, the engineer just applied scientific knowledge to delay the inevitable.

Given my definition of science software development doesn't really fit in there.  Sure, you can take a look the basic principles of the theory of computation and say, "Look, there's the science!" You'd be right of course, that is science, Computer Science in fact which isn't what we are discussing. 

Software development isn't exactly engineering either, is it? One could argue that development is just the application of those scientific principles that Computer Science gives us and in some cases I think that line of reasoning would bear fruit.  What makes software development different from traditional engineering and allows us to call it a craft boils down to two things.

  1. Software development introduces the concept of easy way and hard way
  2. Software development introduces the concept of beauty

As to item one, the theory of computation has the potential to tell us exactly what is and is not computable (it hasn't given us that yet, but I digress).  Further, it can tell us the optimal way to compute something.  It can not, however, tell us the optimal way to build the computation in terms of time, materials, and customer satisfaction.

Item two is most likely the biggest digression from engineering.  Bridges are functional.  Machines are, or can be made to be, ergonomic.  Rarely is beauty considered and when it is, it is approached solely from the perspective of pure art.  That is, what the human mind and eye see as beautiful.

In software development beauty has some of those elements, predominantly in the user interface, but it also has a structural element.  Even in architecture who is looking at the beauty of the steel girders holding up the building? In software  development, the girders are supposed to be beautiful too.

No method can provide that beauty with any form of guarantee in the same way that calculations can be performed to build a functional bridge.  We are victims of our own minds.  In software development there is no golden ratio.

So, like a basket weaver, we as developers must produce using nothing but the most basic of principles and to our own (or our client's) perception of beauty.  This typically requires long apprenticeship under more senior craftsmen and a whole lot of trial and error.

Methodologies, or perhaps more accurately philosophies, of software design and implementation like extreme programing don't map to science because they don't provide a universal system that works in all cases.  Science is predicated on a single methodology called the scientific method.  Employing the scientific method guarantees that a scientist's work is valid. 

There is no such guarantee when a developer uses any of the prevailing design philosophies because even if you end up with a working product it may not satisfy the client.  Nearly everything is subjective and the developer is at the mercy of the client, the product either isn't fast enough, not pretty enough, or not easy enough to use and it isn't going to matter to the client whether it was built using extreme programming or agile methods.  This doesn't occur with science as we can see with another Newton example.  I doubt anyone pointed at Newton's work and said, "Gravity isn't elegantly constructed or convenient to use, we are opting to wait for Gravity 2.0".   

Alright, so what is my philosophy and is it universal?  I don't really have one, so no it isn't universal.  I try and organize my architecture in the way that best allows me to execute on my client's wishes and I try to keep my client's involved as much as possible by delivering relevant iterations of the software.  The relevant part is the key as a typical client isn't going to care that in this version we structure our stored procedures thusly while blah blah blah.  A client only cares about the parts they care about (makes sense right?) and our job as developers is to show them that.

I am not saying that extreme programming or any of the other philosophies don't work, I am sure there is enough evidence out there to show they do in fact work.  What I am saying is that you don't know if they are going to work, only that they have.  Methodologies are developed from a set of project post-mortem's so they are only going to have good coverage for projects that you've already completed and maybe a project you think might be close enough to the others you've already done for this particular approach to work. 

Well, as Forest said, that's all I have to say about that.  From here on out it will be

Posted on Thursday, November 8, 2007 3:01 PM Philosophy | Back to top

Comments on this post: Development Philosophy

# re: Development Philosophy
Requesting Gravatar...
Interesting post, as a future Masters grad in Software Engineering I think writing software and designing systems is engineering. Why cant you associate software engineering with beauty? It may not be beauty in some peoples eyes but to the eye of a developer it is. Beauty is perception; there can of course be common ground but generally ones perceived beauty differs from anothers.

Although I havent picked the word out I think you would agree that flexibility plays an important part. Agile etc processes are great but like any engineering project, one size does NOT fit all and thats where the skill and experience comes in...would you not agree?? I'm no seasoned expert mind i said "future grad" !!
Left by Steve Clements on Nov 08, 2007 11:43 AM

# re: Development Philosophy
Requesting Gravatar...

It isn't that software can't be beautiful. My point is that it has to be. That is what makes software development unlike science and traditional engineering and more like an art or craft.

You are correct in saying that flexibility is important, which is why I pointed out I follow no set development methodology. I do what makes sense for the current project.

Good luck with your degree!
Left by newman on Nov 08, 2007 1:02 PM

# re: Development Philosophy
Requesting Gravatar...
"Science is a well defined method of making observations on laws and systems that you did not create and therefore have no control over."

Perhaps this is nitpicking, but science is not a method of observing laws. A "law of nature" is a generalization of empirical observations.
Left by Chris Eargle on Nov 08, 2007 5:53 PM

# re: Development Philosophy
Requesting Gravatar...
I really like what you have written. The great thing about software development is that it does actually incorporate some science, some engineering, some beauty, some performance, and a whole bunch of creativity. It is this creativity which in my mind really distinguishes software development since not only are the technical folks being creative, but also the users, customers, and other stakeholders. Software development is almost always a group creative effort and I find that one of the most fascinating things about it. It is this idea that actually makes me think that it goes beyond "craft", since that word is usually associated with individual efforts not collaborative efforts.
Left by Mishkin Berteig on Nov 09, 2007 12:26 PM

Your comment:
 (will show your gravatar)

Copyright © newman | Powered by: