|
He is most definitely a Legend Author. Especially with his 0 upon 0 amounts of articles he wrote 
Wow! I must say I think I am short 20K author points by the look of it 
Loading signature...
. . . Please Wait . . .
|
|
|
|
|
It seems to me that it is "enterprisey" to write layer of abstract code.
In fact I am often criticized as "not liking layers"
So first I'd like to say what I thing about architecture then ask my question
A crux of contention is:
=======================
I would argue writing layered code is not an end of its own (at least not reasonably).
I would argue an end of its own is (simple maintainable code, i.e.) probably be these few properties:
- modular (people can work on their bit independently)
- dependencies flow down (top level use low level, low level do NOT use top level)
- simplest / unobtrusive as possible shell / architecture to glue stuff together
this *might be* layered / interfaced too but this is not the purpose...
What I often see and I wonder how prevalent and wonder how common it is
=======================================================================
Layered / interfaced as hell code which takes weeks to understand to solve problem as simple as adding 1 + 2.
Is that a common pattern? I suspect it is!  
|
|
|
|
|
Super Lloyd wrote: is not an end of its own
Correct.
Super Lloyd wrote: Is that a common pattern?
Not in my experience. But it depends on the how big a project it is too. I have written only one application with more than a Data Access Layer beneath the application.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
I always keep my UI layer and any DB layer separate - it is simpler to just ram code accessing the DB directly from a View, but so totally unmaintainable beyond trivial examples that I just don't do it. I also almost always have a 'service' layer which stitches the two together, rather than calling the Db later from the UI layer.
Other than that, I tend to be fairly flexible on layers depending on the project.
I agree about the over-complexity introduced sometimes - my logic is that a well written and modular project can be expanded into more abstract layers, should that be necessary, quite easily if it is easily maintainable and modular in the first place - and building abstraction on abstraction just because it makes some intrinsic sense to a developer, in my experience, slows development and can increase bugs as new developers don't understand how it hangs together - and nobody ever spends the time to train newbies!
Quote: Super Lloyd wrote: simplest / unobtrusive as possible shell / architecture to glue stuff together
That's the one that gets me most. When someone uses some framework or other (especially if they use something and then modify it, and don't document anything) I have often found that the use of the framework has been chosen without much knowledge - so the developers learn on the job, invent work-arounds, until the whole thing is a bit of a mess, nobody really understands how it is meant to work, and new devs coming into the project don't have a cat in hell's chance of being productive for weeks.
Still, I'm an old fart, so what do I know?
PooperPig - Coming Soon
|
|
|
|
|
I usually keep some sort of scheme like in these two excellent articles 
1. Building a Framework - Part I (DAL)[^]
2. Building a framework - Part II (Utilities)[^]
although that can differ a bit from project to project. My major concerns regarding this, is code separation. It forces me to keep things simple. It also allows me to reuse things, which is handy when you're working on multiple applications.
|
|
|
|
|
What? Something like this?[^]
Regards, Stewart
|
|
|
|
|
Yeah!.... 
|
|
|
|
|
Layering can be essential to avoid spaghetti and headaches.
Imagine a collection of diagnostic tests written into a prototype, then re-written into a CRM wizard.
Then keep adding new tests, and testing would require rewriting the prototype and the wizard each time.
Or- write each test into a dll, referenced in the prototype and wizard by simple xml.
Adding new tests means just extending or altering the xml and a little wizard interface adjustment.
|
|
|
|
|
Simon O'Riordan from UK wrote: Adding new tests means just extending or altering the xml and a little wizard interface adjustment.
Which is only true if in fact there is a prototype and wizard.
If there is only one or the other then there is no benefit.
Problems arise when developers (plural) or developer (singular) decide that even though there is one instance that in some mythical future there might be more. (And I want to emphasize that they do this without even a glimmer that such a possibility exists.) And thus conclude and require that extra layers be added to support this mythical functionality.
|
|
|
|
|
My principles(I do REAL software in an ENGINEERING company - you've probably heard of that) are rolling out new extension requirements regularly. Now I know you want the five pound argument, but unfortunately you are not paying my bills.
|
|
|
|
|
Simon O'Riordan from UK wrote: My principles(I do REAL software in an ENGINEERING company - you've probably heard of that)
And management of your phone at least at one time was written by me.
And a very good chance that if you used a credit card in the US in the not too distant past then you had a transaction processed by software I wrote.
So now that both of us have proven that we are actual business professionals - my point stands.
If you have extensions being regularly rolled out then you
1. Do in fact have multiple examples already.
2. Probably do in fact have an idea of new instances in the future that will require more flexibility in your design.
Those two factors however are exactly what I said some developers do NOT have. Yet they insist on inserting the same flexibility and of course they will be paid for that time even in cases where it will never be used.
And in point of fact I know of specific example where at least one developer (could have been more) added a complex feature into an API and after several major versions of the software there was NO use of the feature. (This by the way was an API and not a UI toggle that no one bothered pushing.) And when I queried business analysts with years of experience in the industry they could not come up with any idea at all why this feature would ever be used.
Actually for that feature the reason I figured out it wasn't used was because it in fact was coded wrong. It would not have worked if used. Which is why I went looking for the answer for why it existed in the first place.
|
|
|
|
|
Ah, cool. Yes, I was stateside 2008. Kudos, mate. I am looking after operating systems and various other stuff on a tall stack for the Equator robotic gauge. The company was founded by the ex-chief designer of Rolls-Royce Aero Engines specially to do metrology.
Look us up on the web; 'Renishaw'.
The gauge is a beauty; it uses the 'comparator' method to be extremely repeatable rather than absolutely accurate. Ideal for volume production where the product changes frequently.
|
|
|
|
|
Well layered code provides for shearing layers[^] which allow different parts of the application to evolve somewhat independently.
The value of this increases with increasing application/team size so yes it is more "enterprisey".
|
|
|
|
|
I would say that if the app you are working on calls for "simple maintainable code" then yes, what you list is just fine, but typically what I have seen is that apps dictate the architecture - or at least they should!
If an app needs maintainability and features that layering provides then yes, use layers. If it doesn't and needs to be fast as hell, or meet some other requirement that layers does not provide, then don't use layers. I guess my point is that the apps I have seen don't always have the same requirements and therefore need to be architectured differently to meet those requirements. My 0.02
- joe
|
|
|
|
|
Layers are an architecture design pattern that's often applied to help break the design up into manageable pieces or to isolate levels of functionality. Done right, they also define an interface that developers can write to, which makes breaking the work up across multiple developers much easier and makes it easier to replace large sections of functionality.
Developers that came out of large enterprise organizations do seem to be more prone to apply that architecture pattern, in my mind sometimes without much justification. And yes, needed or not, it does gum up the works to some extent. However, I wouldn't consider it bad, merely a design choice.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
Any reasonably sized system (i.e. anything that isn't so small you wouldn't be hiring pros to write it for money) can generally benefit from at least the classic 3 tier model (data source or data access; application logic; presentation and user interaction). These layers should, as you say, be genuine layers (one directional dependencies) and that usually requires interfacing if data flow can be two way.
It certainly shouldn't be done 'just because', but layering is a common architectural pattern for good reason, and if I see an architecture without layering in it, I'm going to assume it's just a horrible mess unless someone can give me a good reason why they haven't done at least the classic 3 layers.
|
|
|
|
|
Super Lloyd wrote: I would argue writing layered code is not an end of its own (at least not reasonably).
Seems reasonable.
Super Lloyd wrote: What I often see and I wonder how prevalent and wonder how common it is
At least in my experience people seem to become enamored and/or comfortable with some idiom that requires layers and defend it by quoting what the model does and are incapable of explaining how it applies to the current business need.
Since I get paid either way and, very likely more with the more complex models, and since those very same people, given their inability to even tie the idiom to the business need, I figure trying to make them understand why it is overkill and just let it go.
|
|
|
|
|
Well, there is truth to that! I sometimes say it to myself too!
|
|
|
|
|
I know that after I'd been programming for a few years I began to really fall in love with the potential offered by writing layers. "So powerful! Flexible! Re-useable! So CLEAN!"
Repeatedly bloodying my nose trying to understand and debug my own past code, for simple problem sets, has slowly but surely taught me to temper my infatuation.
For me its been about gaining a better big-picture perspective on my design decisions (viewing them an integration of a larger environment that includes not just other systems and users but also the solutions life cycle).
Better judgement of when not to abstract has saved me a lot of pain. For me that's been like learning when to succumb to the temptation to rewrite from scratch and when to just add a workaround - its only come with experience and had to be learned the hard way.
|
|
|
|
|
I think the teach lead is a bit young, he probably still going through such phase!
|
|
|
|
|
I enjoyed RogelloP's current post on this topic, but, on reflection, I found such a variance between the person-types listed in his post and my actual experience working in various software companies, including a start-up, that I feel compelled to publish my own list:*
1. schizophrenic creative visionary who typically communicates in grunts
2. best college friend of #1 who never held a job for longer than two months before this one, and is into S&M
3. ex-felon convicted of securities fraud, and tax evasion
4. manic-depressive hyper-verbal former philosophy master's degree holder
5. former assembly language programmer only familiar with printer-drivers for long-discontinued ink-jet printers
6. alcoholic former zookeeper fired for willful negligence of the animals in their care
7. programmer from India, or China, or Taiwan
8. vegetarian meditator recently convicted of spiking trees
9. drag-strip racer, gun hobbyist, military memorabilia collector, amphetamine user
10. anal-retentive compulsive-obsessive high-Asperger savant
Relation of these persons to their job titles:**
1. only one person can have the following titles: CEO/President, CTO/Chief Scientist, CFO/Accountant
2. more than one person can have the following titles: programmer, marketer, public relations (aka 'booth bunny,' or 'booth stud'), janitorial, massage therapist, psychiatrist, janitorial, network/site admin, unpaid intern
* Note: Any resemblance of the persons described here to certain well-known CP members is purely serendipitous, although, given quantum electrodynamics, one cannot rule out extra-sensory influence, or the possibility of hive-mind thought-control.
** Note: This is not to imply there is some causal relationship between background, experience, and capability, of these persons, and the job title they may hold.
“I have diligently numbered the days of pure and genuine happiness which have fallen to my lot: They amount to 14.” Abd-Ar Rahman III, Caliph of Cordoba, circa 950CE.
modified 22-Jul-14 18:28pm.
|
|
|
|
|
I guess I would fit into the #10 category?, but with Alzheimer's thrown in.
As I grow older I've found that pleasing everyone is impossible but pissing everyone off is a piece of cake.
|
|
|
|
|
There are not enough upvotes for that one.
I too dabbled in pacifism once.
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
