The Code is the Design
Recorded at:
- Share
-
- |
Read later
My Reading List
Bio
Mark Haskamp is a Principal Consultant with Pinnacle Solutions Group, Inc. located in Cincinnati. He's a curious geek with almost 30 years experience writing software. His current focus in the office is Asp.Net MVC but he's delivered solutions across the technology spectrum of C++, Perl, Java, .Net, Ruby, Rails, and Jquery. His current shiny pennies are jquery, sinatra, and clojure.
Code PaLOUsa is a conference designed to cover all aspects of software development regardless of technology stack. It has sessions revolving around Microsoft, Java, and other development platforms; along with session on higher levels that are platform agnostic. The conference schedule will feature presentations from well-known professionals in the software development community.
Video Chopped Out
by
Gonzalo Vinas
Design not = source code. Design not = OO design.
by
graham berri
Sure:
Source code should be documentation that the next programmer wants and needs.
"Software is not hardware" (name of paper bottom right of Library at avancier.co.uk.)
TDD and Refactoring are right and proper.
And everything you say sounds fine - except for the premise in your title.
I put it to you:
Documentatation (source code if you like) tells us what code does (its intent).
Design tells us what shaped the logical structure of the code.
Design tells is what decisions were made on the way to the code.
I put it to you:
Software documentation using the likes of UML is way too low level.
We have to manage the complexity of large systems through abstraction to a much higher level.
Documenation of the design should be 10 to 100 times more abstract than the source code.
Design not = OO design
Bob Martin likes to make fun of a UML class diagram for a 10 pin bowling game he codes using TDD. The trouble is: a class diagram is the wrong design model. The right design model for the code he codes is a simple regular expression that describes the input data stream (basically, an iterated sequence of two ball throws).
P.S. TTD is typically unit test level - what about system and acceptance testing?
Design documentation should record decisions like:
- what data structures shaped the code?
- how mamy client-server layers? what is the purpose of a layer?
- does a client use request-reply or fire-and-forget?
- does a server act in a blocking or non-blocking way?
- are components stateful or stateless?
- is request-reply by point-to-point or message broker?
- superviser control or distributed control of procedure?
- components are spawned by supervisors? and deleted if no proper reply?
- which design patterns are used? and why?
Trouble is: programmers learn and talk only about technologies. They no longer learn and talk about technology-independent design - as we used to 30 years ago.
Too simplistic?
by
Kelvin Meeks
There are different parties with different concerns - who need access to design information at different levels of abstraction. For example:
- Non-functional requirements may often be handled by strategies that are external to code. For example: often these types are concerns are addressed by processes (IT or Business, and often manual); hardware architectures that change over time - independent of software design; network architecture that changes over time - independent of software design; etc.
- User Interface design is poorly documented in the code imho - and is better served by other artifacts - such as wire frames, mock-ups, etc.
- Requirements traceability anyone? I shudder to think of cluttering a module of code with traceability mapping to requirements.
- When dealing with external 3rd parties - you are often limited by legal or intellectual property concerns from sharing the actual source code - which begs for artifacts at a higher level of abstraction than code.
I think you can get the general idea of my line of argument from these examples...
Re: Too simplistic?
by
graham berri
Re: Design not = source code. Design not = OO design.
by
He Mike
I like your lists of what should be recorded in design documentation and your thoughts on technology-independent design.
But my 2 cents is that learning technologies and design is not mutually exclusive. It is not uncommon to see a project using and combining myriads of technologies to achieve a design goal esp. in distributed systems. Although, many of the times people are talking more and more about specific technologies in public. It is understandable as we need them to help tackle our problem after all.
Re: Design not = source code. Design not = OO design.
by
graham berri
Graham at avancier.co.uk.
Re: Design not = source code. Design not = OO design.
by
Mark Haskamp
You and Kelvin both do a decent job of pointing out one of my chief struggles with the talk: it IS simplistic. One reason for that is because of the constraints of a time limit but another reason is that it reflects a large majority of projects that I've worked on over the past 30 years. The type of documentation you suggest would be useful but it seldom exists, which leads back to the code as my primary source of documentation.
Re: Design not = source code. Design not = OO design.
by
graham berri
Graham at avancier.co.uk
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think