Design!?...when?

[lastcraft]

Hi...

This poll arises out of a Trad vs. Agile agile debate on when to carry out design work. Note that it is public. Boy am I interested to see how this turns out .

yours, Marcus

[sweatje]

Seems like recently what works for me is the best requirements you can get up front, then design as you go pushing as many iterations as possible in front of the user for approval.

[Phil.Roberts]

My personal philosophy for designing web pages is that it's best to start with something simple and add to it than it is to start with something large and complex abd try to fix it. I think this can easiliy apply to programming as well.

[sweatje]

Didn't know that the poll was not anonymous. That'll teach me not to choose the funniest sounding answer

[seratonin]

I think that you can arrive upon an initial design specification only after proper requirements have to formalized. Both the requirements and design will undoubtedly change, but if the documents are "formalized" and "tracked" this change can be managed. I like the iterative and spiral models of software development but I am not willing to accept XP or Agile software development quite yet (I need more experience with them). I don't think there is one particular software development methodology that is best. I would like to emphasize, however, that both requirements and design should be incorporated (and documented) in some matter. Design needs to be documented in the form of use-cases (scenarios, diagrams, etc) and class diagrams. The database ERD is pretty important. Two other tools I find helpful for Web applications are site org charts (hierarchy) and storyboards. Another technique that has interested me as of late is that of CRC cards: http://ootips.org/crc-cards.html.

JT

[lastcraft]

Hi...

Another technique that has interested me as of late is that of CRC cards: http://ootips.org/crc-cards.html.

I have attended a seminar on the use of these (by Joseph Pelrine) and immediately started preaching on their behalf. It is an excellent way of getting a team that is new to design up and running. Also it allows everybody to participate.

I find it works best as follows. Start with a task, such as logging in. One person (A) says "I want to see a private page". They pick up or create a card called "Top level script"...

(A) Do I have a session? I have to ask the session manager.
(B) I'll be the session manager.

A writes a collaboration of session manager, B creates a card if none exists. A notes that the script can create a session manager.

(A) I need to get some permissions, I'll call getPermissions() and give you the PHP $_COOKIE hash.

B writes getPermissions() on the responsibility, A writes $_COOKIE on their's.

(B) I need to find a session for that cookie. I'll have to ask the database. Shall we assume I know the SQL query? OK, I'll pass the query to teh database connection.
(C) I'll be the connection. I already have a select() method. Who created me?

And so on. Eventually, control will pass back to the caller and that task will be complete. If you lose track of who is executing the imaginary code, then a throwable soft toy is useful. This is important; we once used a paperweight and it hurts .

yours, Marcus

p.s. Gonna vote then?

[Mandibal]

I'd say that design up until about a year ago was minimal. Now i've been trying to incorporate refactoring and unit testing into my every day practice.

[seratonin]

p.s. Gonna vote then?

I voted already, but it looks like I am in the minority. All of these PHPers like refactoring... My opinion is probably kind of biased, because although I have built many Web applications over the last five years, my day job is in embedded systems.

JT

[HarryF]

Reminds me of chess.

When I first started playing, I used to plan sequences of moves far ahead, in my head, attempting to see all the possible outcomes at each point. Against another beginner was sometimes quite effective but more thanks to luck. Most of the time, I'd end up forgetting where I was or some move I hadn't predicted blew the whole plan. Either that or I'd forget something and have to rethink all those moves ahead again.

Now chess is a "controlled ecosystem"; pawns don't go on stike, the knights don't turn up late to work after a night on the town, the Queen doesn't use MS Project to "plan" with and the King isn't looking to retire early.

Anyway, before I drag the analogy too far, one day ran into someone good at chess who finally explained there's no need to plan far in advance. Simply think about the next move and ask "Is this improving me position or not? What's the next move that most improves my position?". Sounds simple and it works although the prerequisite is to have built up alot of general experience playing chess, to be able to make those value judgements.

[I'm still not very good BTW although I might be up for a game of PEAR::Chess one day ]

Anyway - think software projects are similar. There's far too many unforseeables up front to come up with any sort of detailed plan.

My view is start with a rough idea of where I'm going and plunge in. Then when the overall picture is starting to get clearer, go back and clean up then plunge on again etc.

No doubt pair programming could help reduce the lengths of the "clean up" (now I call it refactoring) stages but I don't have opportunity right now so it remains an internal dialog. A language like PHP is important here, because it provides the freedom to hack through the "exploratory" stages quickly, while at the time time shaping up into tidier code later.

And the more I find out about eXtreme programming and Agile methodoligies, the more I find that they formalize common sense - "Rediscovering the obvious".

Coming from a Science background, have always found it an interesting phenomenon how groups of people are often willing to sacrifice their own good sense for what someone labelled "scientist" tells them is the truth. Later on the the obvious gets rediscovered e.g. "Scientists have now discovered that watch lots of horror films really does harm your children.".

Anyway, just wearing out the keyboard.

[ghurtado]

I loved the chess analogy, Harry. One that I can identify with very well (although I'm no Grandmaster)

[sweatje]

So, to carry the chess analogy further, your opponent would be...the users?!?

[lastcraft]

Hi...

I voted already, but it looks like I am in the minority. All of these PHPers like refactoring...

I am surprised at how fast the XP thing is catching on. I was expecting more requirements driven or use case driven answers. I guess the real XP test is whether you carry on refactoring once the job is done. If you do, then you are designing by refactoring, if not then you are just testcase/use case driven.

There is another categorisation of techniques. Top-down, bottom-up and tracer bullet. Bottom up is forced if you want to get everything working for testing. I had to do this before mock objects came along.

Top down is possible, but by the time you start implemented the lower code you find the top level has changed. It lacks the "hardness" of genuinely working code and leaving teh infrastructure to last can be risky and difficult to estimate. Good for quick jobs though. I am writing a blog this way.

Tracer bullet is my weapon of choice these days. Take aim, fire off a quick solution, see how far off you are and get it on target. Then back fill related functionality and refactor the design. A balance between safety and waste.

My opinion is probably kind of biased, because although I have built many Web applications over the last five years, my day job is in embedded systems.

I used to do embedded. I used to play Chess too .

yours, Marcus

[ausurt]

I usually think about what I need, think about the requirements on the classes and then code each class at a time, I guess I refactor as I always come back and modify.

[sleepeasy]

Generally speaking, when I have a project to do I sit down and write pages of notes and UML diagrams (mainly state chart and class diagrams). This is the what I refer to as the "initial/concept design"

I won't start coding until I have the Rough Idea of how all the objects are going to interact, and what roles they all should have. I don't know what every object is going to look like (methods etc.) but I think I know why it needs to be there. The first time I start coding it's exploratory really - just because I'm not experienced (or clever?) enough to get the initial design right - so I'm coding whilst designing aswell.

I'm a big fan of milestones. Without them I would try to implement every feature in the requirements spec. at the same time which is not a good thing (for me at least). They help you gauge how complete/incomplete the project is in terms of features, and every time I "hit one" I sit down and look at (design) how I'm going to implement all the features to get me to the next one.

And chuck in some random refactoring madness aswell. Is there anything more satisfying (and slightly embarrassing) as when you reduce 100 lines of 2 week old code to 3?

[ghurtado]

So, to carry the chess analogy further, your opponent would be...the users?!?

Or your project manager / boss depending on your situation. Problem is, sometimes you have no chance of winning the game

[Selkirk]

Interesting analogy, Harry. Chess playing is a well studied area of problem solving in cognitive science. Your experience exactly mirrors the research into the differences between how novice and expert chess players view chess problems.

[Travis]

Doh, I had to pick the funny one on a public poll....

I usually go with the little design in the beginning idea. I decide the general roles my app will have and ways to do them, then I start coding. When I realize I need something I didn't have in my design I stop, think about how to implement it, and go from there.

[lastcraft]

Hi...

Doh, I had to pick the funny one on a public poll....

I think you chose the deadly serious one. I have been in a use case driven project and there were two main problems.
1) No one seemed to know what was going on.
2) Code quality was pretty poor.

I really didn't like it .

I think use cases are great for getting a specification. That specification can be enforced by testing (although never completely), but without modelling alongside there just doesn't seem to be real communication. When I get requirements off of somebody I don't just want to know the immediate tasks, but also the structure of the domain. That way future requirements are more likely to fit the code. With all the programmers working with the same business model there should be less duplication.

Thus there are some distinct modelling phases (whenever the client is available), but these are requirements gathering operations, not coding.

yours, Marcus

[yoritomo]

chess and programming, something to read

hxxp://membres.lycos.fr/astrobe/chess.html

the article is in french

here is a translation

I find a strong analogy between programming and chess. Chess has the reputation of being a game for intellectuals, for maths wizards because it seems complex mostly because of the movement of the pieces. Programming and IT have the reputation of being complicated, and of being the domain of maths wizards, mostly because of its cryptographic aspect [or appearance]. The first thing a chess neophyte must learn is the movement of the pieces. For as long as he hasn't mastered [learned] his pieces, the novice player cannot play correctly, because he spends most of his time "remembering" the movement of the pieces; he has a lot of trouble anticipating adverse play. The first thing a novice programer must learn is the syntax of the language and its primitives [low-level library functions?]. For as long as one doesn't know all the possibilities of the language, one writes bad programs; one sometimes writes a lot of code which [already] exists as a primitive [library function], which complicates the programming. Languages like 'C' seem to me like a game of chess where each of the 32 pieces have a purpose [direction, order] that is [would be] appropriate to that piece.

After the purpose of the pieces has been acquired and mastered, comes the learning [apprenticeship] of positional play. Positional play is the art of placing pieces at strategic positions, for the purpose of maximising their effectiveness. The judgement [assessment] of a position depends on certain well-identified [well-defined] indexes [criteria], for example a castle's occupying an open column, occupying the centre, or the structure formed by pawns; but the ability to combine them and to gauge some pieces with respect to other pieces is acquired as games are played. Evaluation the position is the major characteristic that distinguishes the amateur from the master. In IT, once the syntax and the primitives have been learned, it's necessary to learn to program. The art of programming can be reduced to factoring, which means isolating sequences of instructions that will eventually recur and which accomplish an identifiable operation. The most common programming error is to use the editor's copy-and-paste instead of grouping recurring statements into a subroutine. This wouldn't be a bad error if it only cost kilobytes; unfortunately if such duplicated code contains {"une faute de frappe" ... I think this this means "a typo"} or a bug, copy-and-paste has multipled the places and the time required to correct it. Another error is creating functions which fulfills several roles (in chess if a piece defends several strategic points then it's an ideal place to attack and is consequently a weakness). One can factorise a program in different ways, one can even choose to not factorise certain parts of a program (usually the most inner loops) to make it run faster. The ability to determine a program's requirements, and to factorise it accordingly, improves with practice.

Certain quotes from chess masters could well supply an equivalent to the quotes of Chuck Moore, or complete them: (from the "Breviary of Chess" of Xavier Tartakover) avoid {"touffues" ... I don't know what this means ... perhaps "complicated"} positions which make defence difficult. Economize your pieces, especially in attack. Think of your reserves. Don't waste time wanting to win one. (A. de Rivière) Help your pieces so that they'll help you. (Morphy) Don't be too dogmatic in your decisions. Hold high the banner of "rules" without at the same time lowering the tent of "exceptions". The pieces serve you devotedly [faithfully]; use them skillfully. Beware [mistrust] the brilliant, enjoy simplicity, which exists at the peak of art, and which therefore also has reason to exist in chess. Beware also plausible attacks, they don't always respond to the needs of reality. Each position, no matter how simple it seems, needs to be made deeper. Make, as soon as possible, a plan of action: it's better to have a bad plan than no plan at all. (Tartakover)

[lastcraft]

Hi...

I am not sure how far this chess analogy can be usefully stretched. Both are intensely human activities, but in Chess you are trying to knock things down and encourage mistakes. In building software you are trying to work together to avoid mistakes .

{"touffues" ... I don't know what this means ... perhaps "complicated"}

Possibly means "sharp" or "double edged". Basically, one wrong move and it's game over. There is a style of play where you deliberately seek complications with aggressive (even dubious) play in order to push the game into the realm where neither player can see clearly. Kind of like in a wrestling match where you try to get your opponent close to the edge of a cliff. Either of you could fall.

Paradoxically, this is the style you should adopt against a stronger player. You will still probably lose, but if he does make a mistake...

yours, Marcus

[astericks]

I definitely design before even starting the coding phase, which I believe is the right tihng to do. It allows me to address issues that might be a problem later on and of course, minimise the time i waste trying think about how to do something when coding.

notes, UML, pseudo code later on...everything that'll make my task easier...sometimes a cigarette will do too.

[Widow Maker]

...sometimes a cigarette will do too

What about coffee eh ?

[DmS]

Interesting topic indeed
I recently built www.detfinns.nu (a swedish site for personal ads) together with another guy.

This is OOP all the way and built in several layers, a simple db-api layer, a query-layer, a business layer that utilizes a session based cache and last a presentationcode generating layer.

What we did was to id all nessecarry base functionality and write skeleton code for them, then we sat down and identified processes through the site, prioritized those accordingly to the clients testplan and how the site should evolve through development.

In other words we did the base design first, coded a bit, then for each process/milestone we designed for that process before coding.

This worked very well and it's definatley a way that I will keep on doing to different extent, all depending on the size and timeframe of the project.
/Dan