Real Life Design Methodologies

[etienne_marais]

So I find myself constantly over-analyzing on how to best approach a new application, trying to foresee how it will all fit together, what to pop into a separate class and where (which components) responsibility of tasks should lie. I always end up wasting a lot of time with thinking and analyzing, and then some.

When push comes to shove I end up compiling/running the app and implementing what I see is missing. Admittedly I perform better under the pressure of the deadline approaching.

The spider's-nest of thought entails the following:

* modularity/encapsulation - trying to write proper reusable classes, or at least have it meaningful for the relevant app.
* Top-Down programming - write the 'outer' code with plenty of stubs to ensure that it is right from the start
* Bottom-Up design - write some code and move it to relevant classes later
* KISS - Keep It Simple Stupid - over analyzing is not getting me anywhere
* Get A Foot In The Door - just do something, the proper implementation will become clear later

How do you approach your design, how do you stick to it and optimize productivity ?

 

[icyrus]

A story from Art and Fear:

The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality.

His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot”albeit a perfect one”to get an “A”.

Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work”and learning from their mistakes”the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

In short have a basic idea of what you want to achieve and how, then iterate.

 

[etienne_marais]

A story from Art and Fear:



In short have a basic idea of what you want to achieve and how, then iterate.

Thanks, I wish MyBB had a like/thank/reputation button !

 

[_kabal_]

A story from Art and Fear:



In short have a basic idea of what you want to achieve and how, then iterate.

Nice

 

[sp4ceman]

you're suffering from analysis paralysis.
what i would recommend when you're stuck like that is do it ****ty.
while you're typing you know its wrong, you know this needs a base class, this should be an interface, this should be something else blah blah blah. realise most of those changes are called refactoring. refactoring is after coding. its cleaning up.

don't feel bad making a mess as long as you intend on cleaning it up after.
a ****ty working product is better than nothing.

in reality i practice tdd.
i test first.
see it fail.
write code to make it pass.
see it pass.
clean up.

red
green
refactor

 

[Hamster]

That old saying that states "you have to code as if an axe murderer is going to maintain it" sounds silly, but it's very relevant. Your work will need to be maintained so always do it in a way so that the other guy reading it doesn't call you an idiot and swear at your stupidity under his breath. "Smart code" is a nightmare.

To be honest I work in a way that is common sense to me:

If it is complicated, do a rough POC
Keep your classes focused on one task
Split complicated/long pieces of code into smaller focused methods - it will document itself
Keep the integration points simple and contain the "mess"
Consistency - coding style, layout, patterns...keep what you are doing consistent
Avoid using too many third party libraries

Dunno how else to say it, just keep it elegant and simple with maintenance in mind. If you have the slightest doubt on whether or not code is too complicated it probably is. Stop and rethink it.

And read the ceramics story again


EDIT: And ****ing AVOID inheritance hell. People abuse it. Seal your classes and stop others from ****ing up.

 

[etienne_marais]

you're suffering from analysis paralysis.

Yes, exactly that

what i would recommend when you're stuck like that is do it ****ty.
while you're typing you know its wrong, you know this needs a base class, this should be an interface, this should be something else blah blah blah. realise most of those changes are called refactoring. refactoring is after coding. its cleaning up.

don't feel bad making a mess as long as you intend on cleaning it up after.
a ****ty working product is better than nothing.

in reality i practice tdd.
i test first.
see it fail.
write code to make it pass.
see it pass.
clean up.

red
green
refactor

Thx, I have a bad habit not to clean up after the code is working (but still messy), the relief after publishing can be overwhelming and then I jump to the next task at the cost of looking at spaghetti or messy code later when changes are needed.

 

[Hamster]

don't feel bad making a mess as long as you intend on cleaning it up after.
a ****ty working product is better than nothing.

This is up for debate. I agree that a mess is fine if you go clean it up afterwards before it is put live. Once stuff goes into prod nobody bothers to fix it immediately (deadlines etc). A ****ty working product is only better until the next batch of requirements come in. I say push back and do it properly the first time.

 

[etienne_marais]

That old saying that states "you have to code as if an axe murderer is going to maintain it" sounds silly, but it's very relevant. Your work will need to be maintained so always do it in a way so that the other guy reading it doesn't call you an idiot and swear at your stupidity under his breath. "Smart code" is a nightmare.

To be honest I work in a way that is common sense to me:

If it is complicated, do a rough POC
Keep your classes focused on one task
Split complicated/long pieces of code into smaller focused methods - it will document itself
Keep the integration points simple and contain the "mess"
Consistency - coding style, layout, patterns...keep what you are doing consistent
Avoid using too many third party libraries

Dunno how else to say it, just keep it elegant and simple with maintenance in mind. If you have the slightest doubt on whether or not code is too complicated it probably is. Stop and rethink it.

And read the ceramics story again


EDIT: And ****ing AVOID inheritance hell. People abuse it. Seal your classes and stop others from ****ing up.

That's how it all began, I have the axe-murderer in the office so to speak, then the over-analysis just got worse because I wanted to do it all right from the start... Your advice is how it should be, but I'm not quite there yet.

 

[Hamster]

That's how it all began, I have the axe-murderer in the office so to speak, then the over-analysis just got worse because I wanted to do it all right from the start... Your advice is how it should be, but I'm not quite there yet.

Practice. Lots of practice and giving a **** about your work.

Some "axe murderers" are nothing more than "I-veto-cos-I-can" douchebags.

 

[walter_l]

I've recently read Harry Percival's great Test-Driven Development with Python (webcast). His approach is very simple and has most of the other items on the wishlist as emergent properties: Double-loop (functional- and unit testing loops) Outside-in (or "top-down") TDD ("red, green, refactor"):

• TDD (the refactoring step, specifically) allows your application's design to "emerge" organically, rather than forcing your application into a preconcieved design. No over thinking required.
• The outside-in approach makes you comply with the YAGNI ("You Aint Gonna Need It") principle, so no code is added that you don't need.
• Refactoring with DRY ("Don't Repeat Yourself") in mind, will automatically resolve spaghetti code and (mostly) ensure that common functionality is factored out into smaller functional units.

 

[walter_l]

This is up for debate. I agree that a mess is fine if you go clean it up afterwards before it is put live. Once stuff goes into prod nobody bothers to fix it immediately (deadlines etc). A ****ty working product is only better until the next batch of requirements come in. I say push back and do it properly the first time.

I'm sure sp4ceman said that in the context of TDD, where "after" likely refers to the refactoring step. But this is still before committing, so it never gets to prodution (or even QA) and no-one needs to know how messy your code was at one point.

 

[sp4ceman]

yeah i did. refactoring is before committing.

 

[Hamster]

My bad. I deal with guys that chase story points instead of quality. I'm a bit on edge

 

[Kilgore_Trout_Redux]

I don't agree with doing it messy and iterating. Not because it is a bad approach per se, but because very few developers have the discipline and time to clean up after themselves so you end up with a mess.

My approach is to get an overall idea of the extent of the project, then think of the approach which will result in the cleanest, simplest architecture to get the job done.

Then you implement that. If you find that your understanding of the system's size and conplexity changes (And more often than not it will.) you iterate within the original design to keep the simplest approach to the problem.

 

[Kilgore_Trout_Redux]

Also that analogy up thread is pretty poor. I wouldn't want to be one of the first 50 clients who gets a crappy pot. The knowledge that some client in future will finally get a good pot is hardly consolation when money changes hands.

 

[icyrus]

Also that analogy up thread is pretty poor. I wouldn't want to be one of the first 50 clients who gets a crappy pot. The knowledge that some client in future will finally get a good pot is hardly consolation when money changes hands.

Who said ship the first pot?

 

[Kilgore_Trout_Redux]

Who said ship the first pot?

Marketing and accounting.

 

[Hamster]

Also that analogy up thread is pretty poor. I wouldn't want to be one of the first 50 clients who gets a crappy pot. The knowledge that some client in future will finally get a good pot is hardly consolation when money changes hands.

Think the analogy was aimed at developer skill and not releases

 

[icyrus]

Marketing and accounting.

If they are making your product shipping decisions then you have bigger problems.