|
Would do: no email link in your profile/post (use link in mine if you wish).
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Step 1: Prepare patties from a dead cow. If cats are present, be prepared to surrender the lion's share of the dead cow.
Step 2: Prepare the secret Big Wraith hamburger sauce. It can also be used as cat deterrent before all of the dead cow disappears. I changed the recipe. Instead of sweet paprica powder, I use jalapenos now.
Step 3: Pile up the buns, cheese and other stuff before firing up the grill. These should mostly be cat safe, but the bowl with the Big Wraith sauce will make sure that the lion does not find the cheese.
Step 4: Roast the cow! (About to happen in a few seconds)
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
CodeWraith wrote: Step 4: Roast the cow!
Don't you grill on a grill?
The algorithm appears incomplete. I fail to see how these steps make one burp. 
Also, what, if any, is the cat's contribution to the burp?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
The algorithm has not ended yet. The last steps involve putting the Big Wraith together, eating it and then burp.
I would also be prepared for some exception handling:
catch(OutOfDeadCowException ex)
{
Grill(ex.cat);
}
catch(GeneralCatException ex)
{
Grill(ex.cat);
}
finally
{
Burp();
}
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Like software there's front-end and (well, to be polite) business rules and the back end.
The burp, only accounting for the front-end invocations is merely a foreboding omen as to the "final outcome". You may well lose your mind . . .
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Ha! All that has been delegated to a service (http://localhost.digestion.asmx) and the burp is the proper response when the service goes to work.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Google Argentina's domain name bought by man for £2[^]
I hope they refunded his money!* 
* But it seems not ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
After a recent post, it occurred to me that we rarely see a good balance between architecture and code.
I often see:
under-architected, over-coded.
But I've also encountered:
over-architected, over-coded.
Personally, my goal is always "under-coded" (meaning, as little code as possible), and I find that that drives a certain amount of architecture, usually during the coding, not before the coding.
So it strikes me that the missing category:
well-architected, well-coded
is something that must be done simultaneously. Not the "architecture first" approach, not the "code as a hack" approach, but rather, while coding, considering where "architecture" can facilitate "well-coded."
And by architecture, I don't mean gloriosky layers of abstractions, thousands of interfaces, DI and IoC. To me, architecture includes writing small functions and maximizing code re-use (there are more, but I'm writing a post in the Lounge, not an essay.)
Thoughts?
|
|
|
|
|
"Design (architect) from the top down, then implement from the bottom up."
|
|
|
|
|
PIEBALDconsult wrote: "Design (architect) from the top down, then implement from the bottom up."
While that makes sense in the abstract, I think it's misleading and results in compartmentalization. It's hard to express in words, but the activity of architecture and implementation is for me more of a process of moving around a lemniscate with fractal properties.
|
|
|
|
|
Quote: a process of moving around a lemniscate with fractal properties
Are you trying to compete with @BillWoodruff on the poetry front? 
|
|
|
|
|
Greg Utas wrote: Are you trying to compete with @BillWoodruff on the poetry front?
Bill takes all the poetry awards on that front!
|
|
|
|
|
Not to mention the back, sides, top, and bottom!
Software Zen: delete this;
|
|
|
|
|
Design (architect) from the top down, then implement from the bottom up.
This statement should be refactored a bit.
Try "After the intended Architect understands the strengths and weaknesses and capabilities of the proposed technology stack as fully as possible", architect from the top down, Then implement from the bottom up and refactor the entire stack as soon as the "Real" tech stack is better understood. Then race to understand what new direction the industry is heading this month and refactor yet again to be ready for it.
Rinse and repeat.
|
|
|
|
|
 Good post. Some of my take on the topic is in this post[^] from yesterday.
|
|
|
|
|
Greg Utas wrote: Some of my take on the topic is in this post[^] from yesterday.
Yes! I read that, and my subconscious must have been noodling on it while I slept.
|
|
|
|
|
I think that it can only be done with proper planning or maybe with lots of experience if you start with a design that lends itself to scalability. Often the requirements are not well defined or understood and it leads to an implementation that isn't ideal. That's where v2 comes in - redoing the way it was supposed to be done 
|
|
|
|
|
Jacquers wrote: I think that it can only be done with proper planning or maybe with lots of experience if you start with a design that lends itself to scalability.
That's the funny thing - it only takes a few lightweight architectural implementations to achieve a good amount of scalability, regardless of the project. The things that promote scalability tend to be completely agnostic to the type of project, at least in my experience.
|
|
|
|
|
Marc Clifton wrote: it only takes a few lightweight architectural implementations to achieve a good amount of scalability, regardless of the project.
If only assiduous study of your work could get me ... there ... the limit in this case is the student, me, not the guru, you !
cheers, Bill
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
Just start Coding while we figure out what we need.
There is a balance. But only a few ever achieve it and then only for like one project or so. There is not a one size fits all to all projects because everything changes with each new try. Even if the people are the same. The experience is different.
But usually everything changes.
I do agree about one point for certain. Quite often Architecture changes meaningfully after the coding starts.
To err is human to really elephant it up you need a computer
|
|
|
|
|
rnbergren wrote: There is not a one size fits all to all projects because everything changes with each new try.
I've concluded that there are common architectural elements that can definitely be reused, and yes, there are application-specific architectural decisions as well, though in my experience, many of those can become reusable (if not in code, at least in concept) implementations.
rnbergren wrote: Quite often Architecture changes meaningfully after the coding starts.
Yes!
|
|
|
|
|
One strategy I've used is to implement the simple, basic stuff first and leave the harder, more complicated stuff for later.
This accomplishes two things: First, management is happy to see "stuff" being produced. Second, it gives the customer and management time to reconsider, redesign what they think they want/need. Third, it gives me time to research and develop better techniques for the hard stuff. Fourth, the hard/complex stuff will frequently change between project start and the time it is needed.
|
|
|
|
|
The metaphor that comes to mind is a diamond cutter: you need a lot of expertise and a lot of patience to do it right. But polishing each face of a diamond takes time and perseverance and both of them are in short supply in the software world.
What is the chance of nailing perfectly the architecture the first time around? You see the pieces that can be reused and where each one fits only after you've travelled the design ladder from top to bottom and from bottom to top a number of times. On the other hand how many times do you have the chance to get back to a project and do major rework? In most cases the economics of the game forces you to leave unfinished bits and pieces and you move on with the sad taste of not having done your craft as well as you wanted.
Mircea
|
|
|
|
|
Having never actually learned to code. I just do it.
So I get an image in my mind's eye (poetic interlude) and keep also the idea that I'll have to extend it at some point; it, in this case, being just about everything. It causes a good deal of abstraction and that does increase the code size a bit . . . at least at first.
The whole thing about coding (not discussing language implementations) is that doing it right is just following the sensible path. Experience has embellished the path (not necessarily the code) to take into account what will happen (i.e., users) and what is likely to come.
I wouldn't say it fits any particular model but it does seem to work.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
The more players, the more up front work you need to do. Can't pivot a crowd easily.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
