developer.* Blogs - Open Comments Thread for "Code As Design: Three Essays by Jack W. Reeves" - Comments

Higher or lower

paper shredders — Wed, 06 Dec 2006 23:36:03 -0800

As computer power increases, level of abstraction is raised, allowing the programmer to "design" at a different level, while the design decisions that used to have to be made at a lower level.

One of 'THE' best article

Krishna — Mon, 12 Dec 2005 11:41:29 -0800

One of 'THE' best article about software design. For a person who wants to be a good programmer, he should be able to read others WELL written programs.

Which is the good code base that you guys can think of (ofcourse, open source), please share your thoughts.

Design

Ashly Varghese — Sat, 20 Aug 2005 02:48:31 -0700

IMO,the development process goes through follwoing phases.

problem specification
[there may be many ways to solve a problem ]
|
^
we select one way to solve the problem
[generally accepted as the top level design.
but the top level needs refinements..for example
at algorithmic level]
|
^
We accept ceratin solutions and stick to them
[generally accepted as the detailed design.From this
point or roughly at this point we will be
concerned about the implementation
(analogous to which materials to use
in construction), we might choose some
technology, language ,platform or what
ever which is feasible and acceptable.]

|
^
we implement the detailed design.some
refinemnts may be made here as well(some thing
specific to the technology used).
[please note that from the top level we may have
a handful of solutions for the detailed design,
or from the detailed design a few other ways
to implement the design available but as we get
more and more specific we get a ready to build stuff]
|
^
Just produce the output!

*) Now its up to us to pick what is the design. I would say the detailed design docs are the actual design statements.From this point onwards we worried only about a specific product [ie, we have already made the choice for the materials that we are going to use in the construction process].

*) I can point to the implementation output[the code] and say that this is the design for this particular build.Thats it.

*) the implementation is no mean job, sheer choices and complexity associated with this in itself is 'the' challenge.

*) this is pretty anaogous to a motor car design.Whats the design here. Is it the final spec that says -
a)use 20mm nuts here,use aluminium alloy to coat the surface at .2 mm thickness?
OR
b) say the detailed design saying the nut size can be 2mm-4mm[essentilly use 2.5% of the length of the bolt]

I would say option b is simple and every body understands.we maintain sufficient abstraction but we have a certain level of specification as well.

#1)Jack is right if we say that this is the design for version 2.1.1 of SOFTWARE.

#2)I am right if we say this is the design for 2.1.X of SOFTWARE.

#3)The conventional architects are right if we say this this the design doc for 2.X.X of SOFTWARE.

Its a matter of choice.who ever we are either belonging to group1,2or group 3 our aim, as well as the end users aim, is to make say release 10.0.0 a complete one.

many thanks,
+ashly

A Foundation For Everything that is Software Engineering

Ryan — Tue, 12 Jul 2005 14:31:44 -0700

Brilliant...yet it's so simple I find it difficult to understand how there has been so much opposition to the concept. It is fundamentally in line with concepts developed and used in all other engineering disciplines.
As Software Engineers we have a distinct advantage and distinct disadvantage over our engineering counterparts. The distinct advantage is that the computers we use are powerful enough to "build" our product very quickly and cheaply. This makes concepts such as TDD (Test Driven Development...which should be more appropriately known as Test Driven Design) so powerful because we can immediately see the impact and validity of our design. The distinct disadvantage we have is that we have to make our design readable to a machine...and currently that machine has a limited vocabulary and cannot make decisions on there own. We have to fill in most of the blanks. Imagine the size of construction design documents if it was necessary to tell the manufacturers how the wood was to be made...or the steel.

RE: What is design?

Kevin — Fri, 01 Jul 2005 12:53:27 -0700

I think you missed the analogy the author was giving. If you compare source code as the instructions to the compiler the same way engineering design specs are instructions to the non-engineer manufacturers on the shop floor, then a typo is very similar to a mistake in the engineering design spec. In this case, a source code typo is part of the design; the design just has a flaw.

What is design?

Chui Tey — Mon, 25 Apr 2005 04:47:03 -0700

In the following code fragment, what is the design?

int multiply(int a, int b)
{
  /* Returns the product of a and b */
  return a + b;
}

Surely a typo does not count as a design, as much as a missed brush stroke by a master painter. Source code is the outcome of the design phase of a project, plus errors, omissions, and workarounds. As computer power increases, level of abstraction is raised, allowing the programmer to "design" at a different level, while the design decisions that used to have to be made at a lower level are done with prebuilt software libraries or optimized by specialized software such as compilers, runtime optimizers and query plans.

Source Code Stretch

Rob MacGrogan — Tue, 29 Mar 2005 14:45:25 -0800

I'm not sure I agree that the definition of source code needs to be overly stretched to incoroprate the artifacts you mention. I'm not 100% sure that I understand what it is that you're talking about re: "the world of domain-specific languages and transformations", but I believe that the definition of source code should be basically anything that is used to build your final product. This obviously includes such things as configuration files and build scripts. And I think it should also include any documents or artifacts that are used to generate other source code.

For example, if you create UML diagrams and then use these to generate basic source code files and subsequently modify the UML and regen the code, then your UML and your generated code are both source code. Further, the argument could be made that if you simply compile and use the generated source code files as-is, without modifying them, then the only source code is the UML. The generated "code" files are more along the lines of compiled class files--the results of your source code, and not the code itself.

However, if you simply create UML diagrams to guide you in the design and writing of your code (in other words, nothing automatic happens) then your UML diagrams are documentation and not source code.

This may sound like so much semantic tap dancing, but I think there's an important distinction to be made. The term "source code" should not be limited to simply programming language code. A broader understanding of what source code is helpful in understanding the ideas behind agile programming and xp.

'Source Code Listings' are a narrow world view

Guest — Wed, 23 Mar 2005 09:07:07 -0800

I'll buck the trend here. Most of both (very nicely written) articles are based on a basic assumption: source code listings (in your choice of programming language) are the only things that can be debugged, hence the only things we can have confidence in.

The world of domain-specific languages and transformations allows us to express (solutions to) problems as models (text or graphical, but not what you would normally consider a 'source code listing') expressed in the language of the problem domain, and to test and debug at that level.

Somewhat separately we describe the mappings to other (implementation) languages. These mappings can also be more incomplete, customizable, or requiring explicit guidance than the command-line switches of your typical programming language compiler. And they can cover much more than c++ to machine code: they can target languages for include platform configuration, deployment, security, and more.

All creative parts of "design" are then located either in the choice and design of the languages themselves, in the models that describe the (solutions to) problems, and in the mappings to other languages.

I think the 'Source Code Listing' view will need to be stretched quite a bit to accomodate this.

C++ vs Smalltalk

Margaret Unger — Tue, 15 Mar 2005 07:59:22 -0800

The article says how C++ is a very expressive design language. That may be true, but I don't understand why the world doesn't give Smalltalk the recognition it deserves. There is no more expressive and source-code-as-documentation language in existence that surpasses Smalltalk. It's object-oriented and has been around since the 70s, so C++ is not exactly a breakthrough in comparison. Not to mention it's infinitely easier to read and debug and making something useful out of it can be done very quickly. Many claim that Smalltalk just isn't fast enough to compete with C++, but there have been virtual machines made for Smalltalk that make it just as fast, suitable for embedded systems. But somehow this beautiful language never really caught on, and that is real shame, because this language can really fulfil the criteria for advances to which Mr. Reeves refers.

Re: Educating IT decision-makers

John Rusk — Thu, 10 Mar 2005 00:13:56 -0800

Well said Claire!

Maintaining the system

Guest — Tue, 08 Mar 2005 02:33:53 -0800

As far as maintaining the system is concerned, I don't see how someone would be better off reading code rather than having a look at some well structured *models* of the system, highlighting a particular view and shielding you from the noise of irrelevant implementation details.

Thanks

Educating IT decision-makers

Claire Henning — Fri, 04 Mar 2005 02:41:13 -0800

I enjoyed the article because it is an exploration of questions and issues that I have pondered over myself. The comment that I want to raise is more of a spin-off from your article than a direct comment. There's a lot of debate about how to develop software by people who are actually doing the work. What I find difficult and frustrating is the fact that the work we do is often ultimately commissioned by people who have no programming background. Because they don't understand the nature of the process which delivers them a piece of software they are often the people who drive unreasonable expectations for projects.
I like the article because it's written (I think) in pretty simple terms and could be understood by people who aren't programmers. (You don't need a degree in Computer Science to understand the 'less able physician' analogy, for example.) Maybe articles like this and debate about articles like this should be part of the curriculum for people who study law, accountancy, etc - basically anyone who might end up as a project sponsor or a decision-maker for an IT project.

Design versus Programming

Eric Helvey — Thu, 03 Mar 2005 19:32:20 -0800

Jack, I'm glad I had the opportunity to read through your views on software design. Your insights have helped me to crystalize my own view points on the nature of my profession.

I'd like to relate my experiences to you, hoping to add another voice to chorus seconding your views.

About five years ago, I joined a rapid application development team that was floundering. We were a loose affiliation of contractors and junior programmers without a guiding force. After I had been with the team for about six months, I suggested that we start creating formal designs for our projects. At the time, I thought I was doing it to help ensure that the code we generated was more correct and so our development times would be shorter.

It turned out that even though we generated the documents and went through the design cycle, we still weren't able to produce software as reliably and quickly as I thought we could. Shortly after this round of design documents were produced, we went through the industry-wide IT purge and lost roughly half of our developers. After the purge happened, we stopped doing the formal design documents, but the tools we built were built faster and with fewer bugs - even though we didn't have time to go though the formal process.

I think the real key is in the "Less-Able" Programmer concept. Looking back now, I think the reason I pushed so hard for design documents is not that I felt like I needed to have a design document, but that I wanted the less experienced programmers or the weaker developers to have to go through the process so that their designs could be reviewed and modified as early as possible. Perhaps I even thought that I could teach these people how to improve their software designs.

In the end, though, even though design documents were written and reviewed and approved, the people responsible for building the software couldn't do it. They wrote the documents, but still couldn't write the code. And this was for a design that they had written. I find it hard to imagine that any large software projects ever succeed that have different teams doing design and implementation.

I've been thinking alot about the Less-Able progremmer concept in relation to CMM levels as well, because there is a push at the company I work for to attain CMM level 3. I believe that you need the overhead of CMM level 3, 4, or 5 class processes to ensure that the producitivity and quality you get out of each developer is the same. That's not to say that you raise the productivity and quality of all your developers - just that all your developers look alike. This helps to build schedules, timelines and budgets, but doesn't do a whole lot to build better software faster. I'm not saying that having a process is bad, just that large, cumbersome processes do not accentuate the abilities of great developers - it mitigates the failures of "Less-Able" developers.

Eric

"What" is in the spec

Yatheendra — Thu, 03 Mar 2005 08:18:39 -0800

[quote]
IMO, design is about the separation of "what" from the "how", as far as possible.
[/quote]
I believe the "what" would be the S/W Specification, and the "how" would be the S/W Implementation.
But, by definition, the S/W Specification does not contain any implementation-level information. So the utility of the view that they need to be separated, is lost on me.
Also, the S/W Implementation does not exist at the time of S/W Design, in the majority ot today's S/W development scenarios, anyway.
Ultimately, you end up promoting as the (maybe not the only) right way, one of the author's observations that
[quote]
As just a small point, all programmers know that writing the software design documents after the code instead of before, produces much more accurate documents.
[/quote]
You also say about S/W Design that
[quote]
It's a valuable process, because it clarifies thought and intent.
[/quote]
I submit that, source code with disciplined comments, and the "auxillary documents" mentioned by the author, sufficiently "clarify thought and intent". So, in a way, you seem to agree that the S/W Implementation is the S/W design.
I would be interested in hearing from others on your point of view.

Yup! you are right

Arun Kumar — Thu, 03 Mar 2005 01:10:49 -0800

This was the same view I had before being rudely shocked by people who had learnt software engineering.

Open Comments Thread for "Code As Design: Three Essays by Jack W. Reeves"

Daniel Read — Wed, 23 Feb 2005 17:55:41 -0800

This an open comments thread for the three part essay published in developer.* Magazine called "Code As Design: Three Essays by Jack W. Reeves."

The featured essay, "What Is Software Design?," was first published in 1992. Also included is a new essay entitled "What Is Software Design: 13 Years Later" and the original letter to the editor that inspired "What Is Software Design?"

If you haven't already, you can read it here, then add your comments below.