A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
i have always developed applications with the goal of keeping my code as “simple” as possible … by “simple” i mean code that most developers can look at and easily understand … to achieve this i often end up writing code instead of using some of the cool features in development environments … for example, i write methods that manually store and retrieve business objects from the database, i write methods that manually connect business objects to the user interface, I write methods that manually create xml to serialize business object, etc … my code is very easy follow and it can easily adapt to changing requirements, but there is a lot of it (i do use codesmith to automate mundane tasks so I can deliver fairly fast)
i recently adopted some code from a developer who takes the opposite approach … the application is a .net application that uses a heavy dose of generics, binding, and reflection to map the database to business objects and the business objects to the front-end … i appreciate what the developer has done, but it is very complex and hard to follow … it seems so “templated” that if the requirements for a specific area of the application changes that goes outside the capabilities of the templates, a lot work would have to be done to meet those requirements … also, while the application was being developed, the stakeholders initially thought the development was going no where because of the time it took to build these generic classes … on the other hand, it now allows an application to be thrown together rather quickly
i was wondering what approach developers in this forum take … i can see advantages and pitfalls to each approach (i think i prefer simple with more code)
> but it is very complex and hard to follow
Is it hard to follow for the other programmer?
I think you have fallen into the trap of confusing your own preferences for clarity and simplicity. This is especially true with code you have written, which you understand because you wrote it, not because it is clearer.
Hundreds of lines of code that could have been generated with a little meta programming doesn't sound clearer to me.
son of parnas
Friday, March 17, 2006
You say "simpler", I say "so much more room for error".
Duplicated logic is bad, and you've already pointed out one of the most important reasons: when something changes (or you discover an error in your original logic), you should only have to update one thing, and not have to track down every instance. The latter frequently leads to pernicious bugs, made worse because it's behavior that you think you've already fixed.
I apologize for my less-than-constructive comment.
One of the best discussions I've ever seen on this topic is in _The Pragmatic Programmer_--I recommend that book to everyone.
[ Really, everyone. I learned nothing obviously new, but they managed to take subjects I thought I already understood and forced me to think about them with a revealing clarity. This was a Good Thing. ]
Let me warn you in advance: this book is not going to take your side. To read it, you'll need to be able to accept a point of view fundamentally different than what was presented in the first post of this topic.
I'm convinced that it's worth the effort.
thanks for the suggestion mark ... actually, after re-reading my initial post, i can see why it may be assumed that i am using a code generator to create (hack) an application with lots of code duplication
this was not my intent ... i actually have very little code duplication ... i follow practices outlined in such books as "patterns of enterprise application architecture", "domain driven design", "test-driven development", "agile software development", "refactoring: improving the design of existing code", etc
the point i wanted to get across is i end up with more code by following these practises than the method i refer to as "more complex" in the initial post ... it seems the goal of the coders i adopted the complex code from was to create a generic layer that “automagically” connects the front-end with the database … this generic layer is what i find to be complex and inflexible, but it is powerful and can allow an application to be thrown together really quickly
the approach i take is focusing first on the business logic layer which i accompany with a large volume of automated tests … it is very independent of the ui and database … this results in more code when it comes time to connect the business logic to the ui and persist it to the database
my initial post was to poll the contributors of this forum to which method they prefer and practise
I agree. I don't know much about the specifics of the problem ("databases" and "business logic" isn't my bag), but as a general principle, I'm somewhat distrustful of generic solutions.
My experience with this kind of thing is that the original programmer gets it working very quickly, then makes further changes very quickly, then has to spend lots of time making some quite serious major restructurings. Because the whole way these things "simplify" is to take aspects of the problem out of the "user" code, and into the "system" code. That's nice, but it makes localized changes hard, and the "grain" is usually so strong that every request for change goes at least somewhat against it.
And, worse yet, all the other programmers will refuse to touch it ;) Give people pages and pages of somewhat ugly written-out code, and they'll be up and running in minutes. They'll work out whether something is their bug or yours, without ever needing to ask you. If you're on holiday, they'll be able to debug it and fix it, without needing to even think about phoning you up. If you're caught short, timewise, somebody else can keep an eye on it whilst you're otherwise engaged. But the cleverer you make it, the less likely it is that any of this will happen.
"Big wodge of hand-written code" is kind of like the lowest common denominator for programmer understanding. There's something to be said for that.
And it should go without saying, of course, that these "other programmers" will probably end up being you, later :)
(Obligatory message from the certainty police: this post omits vital equivocation in the interests of brevity. The reader is asked to bear this in mind.)
Sunday, March 19, 2006
Internal middleware "code frameworks" and languages should be avoided. Every time I've worked with one, it's been a disaster.
Developers see them as a way to cut the development time, to abstract the problem into XML, and let the functionality be driven from that.
They often try to guide functionality a certain way, but then something comes along that breaks it. Instead of a five-minute change, the developer has to think about the business change, and in addition make a framework change to handle what they need to do.
You can't get someone going on the code quickly. First, they have to learn the framework. So, a new employee's going to need more handholding than if they just used the language.
Because they're done quickly and cheaply, there's no documentation and they're buggy. A fault can't be relied on as being in your code. So as well as debugging your quite simple code, you're now debugging your framework too.
If you want to use a tool or language, go for a well-supported vendor or FOSS solution. People have skills in these on their CVs. Books are written about them. There's groups of people looking after them.
Monday, March 20, 2006
I used to work with a Java developer who never met an interface or abstract class he didn't like. Everything was 3+ layers deep of interface, abstract class, reflection, similar to the OP's situation. He was a competent programmer, but it was not enjoyable maintaining his code.
In some cases this type of abstraction is beneficial. However the developer must be careful not to be pedantic with excessive and unnecessary layers. That makes it difficult for anyone other than the original developer to maintain the code, and often requires the "framework" itself be modified every time some special business case comes along.
Sometimes you just have to get to the point and solve some business problem, and that's not a bad thing. It is a measure of the skill and experience of the devleoper finding the right trade off between using generic abstractions and just solving the problem at hand.
Some developers miss the patterns and end up with awkward code where logic is duplicated. Some developers go too far the other way and put in too much generics to the point where it is difficult to tell by looking at the code what it is doing. Strive to find the right balance.
Tuesday, March 21, 2006
Abstraction is never bad. What makes people feel bad is the difficulty to debug/diagnose, not to understand the highly-abstracted code itself. I believe most java developers could understand this ;)
Simple and more code is.. well, if we have to compromise everything with those incompetent, probably the majority of programmers (at least that's what I experienced), it would definitely kill all kinds of innovation. Incompetent programmers should and must learn to be more competent - or being kicked out.
No compromise, no!
Friday, March 31, 2006
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz