The Problem with Design and Implementation
Linked by Yamin on Wed 9th Sep 2009 16:17 UTC
General Development I've been developing software for quite a few years. One of the issues that seems to come up again and again in my work is this concept of design and implementation. I recall it being a significant part of my education at the University of Waterloo's Computer Engineering program as well. The message was always the same. Never write code first. First you must design software by writing a design document, flow charts, pseudo-code, timing charts... then it's merely a trivial matter of implementing it. Make note of the attitude here given towards implementing. The real work is in the design, and it's just a trivial matter of implementing it. It sounds so simple doesn't it? Now, how often does this work out in real life?
E-mail Print r 8   · Read More · 82 Comment(s) http://osne.ws/h2v
Permalink for comment 383679
To read all comments associated with this story, please click here.
RE: Interesting, but still wrong...
by cb_osn on Sat 12th Sep 2009 12:14 UTC in reply to "Interesting, but still wrong..."
cb_osn
Member since:
2006-02-26

However, that still doesn't get down to the root of the problem you are trying to solve. The biggest problem in programming, aside from Academia - though Academia is also partly to blame for it, is not so much theory and implementation, nor how programmers are taught to program, but rather the lack of discipline in the field and the arrogance of programmers themselves.

I appreciate the interesting discussion here, but I respectfully disagree with this. From my point of view, the problem is the attempt to pigeon-hole the practices of traditional engineering into software development. We don't need more discipline. We need less.

There is a major difference between someone who is a programmer and someone who has a job as a programmer. It takes years of dedication and a tremendous investment of personal time to become a good programmer. Those types of people simply aren't going to accept (or if they're forced to, they certainly won't respect) jobs where their primary task is to translate 10,000 pages of poorly worded specification into code. So the people you're left with to fill that role are those who barely made it through a CS program and have no other option but to accept the job. It's not surprising that the resulting implementation is typically poor.

Give the programmers more freedom; give them more responsibility. Throw out the ideas of requirement gathering and design as separate and disconnected phases and give the programmers-- the ones actually implementing the code-- a direct, open dialogue with the clients. Allow programmers to do what they love to do: solve problems. You'll attract more competent programmers to your company and produce better code as a result.

As long as the practices of software engineering continue to view programmers as laborers, akin to someone who drives a rivet or welds an I-beam, the process will continue to fail. If we desperately need to map traditional engineering onto software development, I'd suggest that the best analogy is that the programmers are the architects and the compiler represents the labor force.

This is not to say that the code is the specification. I've been involved in enough large scale projects to recognize that up front design is supremely important. I only suggest that insulting programmers from that process and then expecting them to be code monkey translators is a recipe for failure.

Reply Parent Score: 2