The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

X is overkill for Y

Something I see and hear quite a bit is "That would be overkill in this situation." I've been known to utter that phrase myself from time to time.

I'm starting to wonder if maybe the real 'overkill' is to be always looking for the perfectly 'sized' implementation.

Is it really such a bad idea to use an existing fully-featured tool or framework or component or whatever to do that dinky little task that uses only a tiny subset of the available functionality? Especially when rolling your own means what it always means: time spent on solving ancillary problems instead of central problems.

For example, I write dinky little CRUD apps and there are some things I don't like about the results of just using Visual Studio's own Dataset Designer and other wizards. Instead, I use the CSLA framework and run CodeSmith with the CSLA templates. I might never get close to using the full power of these tools, but there is clearly room to grow. I also get what I want quickly and easily. When I describe what I'm doing to others, they get this funny look in their eyes, like maybe somebody left a rubber room unlocked.
Ron Porter Send private email
Thursday, June 05, 2008
 
 
Well, you had me agreeing with you right up to the point where you mentioned Codesmith! ;) Code generation is one of my many pet peeves. But I won't go into the details here.

Anyway, I agree that it is fine to use a slightly bigger hammer sometimes if you are skilled at using that hammer. In most cases the net impact is completely negligible in the long term.

But clearly there is a whole spectrum of possibilities to consider. And you don't want to opperate at either end of the spectrum. It really peeves me to hear people harp on the "simplest thing that will work". I'd rather hear people use "the simplest thing that will work and provide the lowest long-term maintenance costs". It is fine to opt to use something simple. But that doesn't mean that you get out of actually having to consider maintenance costs and supporting future requirements.
dood mcdoogle
Thursday, June 05, 2008
 
 
I sat down to write a treatise on the merits of proper application of technology to the task at hand, but I figured that would be overkill for this reply...

I think the things you want to watch out for in these cases are tools with high "fixed" costs for small projects and tools without enough depth to scale to support bigger projects.  In the first case, you might spend more time than the whole project should have taken just getting infrastructure and architecture set up.  In the second case, of course, you're stuck with a rapidly-developed system that needs to be re-architected in order to scale as needed.

The best tools and frameworks will let you get started quickly and add sophistication and complexity as you need more capability, but on a blank slate, the choice is still far from straightforward.  As an organization, you can help your cause by limiting the palate of choices - ie, we're going to use this tool (or maybe one of these two tools) unless there's a good reason why that won't work well.  Give yourself a default, and move from the default only if you need to.
D. Lambert Send private email
Thursday, June 05, 2008
 
 
@dood: I like the 'slightly bigger hammer' bit, but I was also thinking along the lines of 'pick up a whole toolkit that includes a few hammers, screwdrivers, wrenches'. In the right toolkit, the right hammer will be both easy find and part of a matched. Not only can you easily select the right hammer, once you learn how to use one, you can use them all. Now that I've effectively bashed that analogy into a shapeless heap, thanks for not hijacking on code generation :)

@D. Lambert: Maybe you didn't write the treatise, but you sure seeded one. Now I have go think and that usually just gets me in trouble.
Ron Porter Send private email
Thursday, June 05, 2008
 
 
To me, "that would be overkill" means not that the technology itself is too much but the implementation is too complex.

"I want to generate lists of things to do.  Please write an application in C++ for me to do that, with a SQL Server back end."

"That would be overkill in this situation - have you thought of using Excel, which is already installed as part of your Office suite?"
Karl Perry Send private email
Friday, June 06, 2008
 
 
I find I keep falling into this trap with my personal projects, because as a developer, my first inclination is to boil 'Y' down to smaller parts that can be re-used for the next project.

In January i cleaned up about 20 personal projects from my source control from the previous year. And out of those 20, exactly ONE was ever completed. That utility was completed because i needed something quickly and built it dirty - almost as a throwaway app. I've never had to go back and refactor that app even though I use it every day.

IMO we're exposed to way too much hype as developers today.  TDD, MVP, Codesmith, DAL, UML etc. these are all enterprise development paradigms but how many of these really need to be brought to bear on smaller projects?

I've now adopted a new development methodology 'STFU and code'. I literally say this to myself when i find I'm being distracted by some new paradigm.
Dravidian Send private email
Friday, June 06, 2008
 
 
Yeah, but it's easier to talk about UML and Design Patterns than to get stuff working.
PeterR
Saturday, June 07, 2008
 
 
"Overkill" should be looked at in terms of the cost and difficulty of the implementation, not the complexity of the underlying technologies.  The right tool for job X is the tool with which the actual people who will be doing job X can best achieve their goals.

For once I absolutely agree with dood mcdoogle here: maintainability is a key term in the equation.  There are few things worse than some smart alec in a Java shop thinking "Java would be overkill for this simple web app; I can whip it up in five minutes with Python!" -- it's not much benefit to the company if you save a day now, only for your successor-in-post to have to lose a week deciphering your elegant masterpiece and rewriting it in a language they can support.
Iago
Sunday, June 08, 2008
 
 
yep. "Overkill" by itself is neither good nor bad characteristic of a solution. It's other things related to it (or not so related) - available alternatives and comparison of the effort to learn, implement, maintain, and sell - which make solution acceptable or not.
DK
Monday, June 09, 2008
 
 
I love it when people throw down the code generation is evil blanket statement when they use all sorts of code generation themselves without even knowing it.  What do you think the .NET compilers are?  How about any of the designers included with VS?

Code generation isn't evil itself.  What can be evil about code generation is when people use it as a keystroke saver to start a project and end up with a huge code base that you dont understand and that you have to maintain by hand.

That's why CodeSmith puts a lot of emphasis on A) using active generation and treating your templates as your source B) and trying to make it as easy as possible to customize the generated output so that it can be your own code and something you understand and are able to maintain.
Eric J. Smith Send private email
Friday, June 20, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz