A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
Many people in the software industry remain unaware of the importance and time it takes to understand frameworks, build foundation classes, and keep code clean.
I have written a short, non-technical blurb on the subject:
I welcome and desire your constructive feedback.
Monday, December 03, 2007
The whole "framework" thing drives me a little batty.
You almost always have a framework of some sort anyway. But some people insist on wrapping what's already there, creating proprietary gilded lilies. I admit some "instrinsic frameworks" are minimal to non-existant, often leaving you to call system level APIs yourself and calling it good.
Still, the lack of a "native" framework in a language toolset must horribly fragment the community around that toolset over time. Extensions are natural of course, since Day 1 it isn't possible to accomodate everything.
I assume that was why VB and Delphi provided extensibility in theirs.
Monday, December 03, 2007
The other problem is, in software, everyone has their own idea of what constitutes a solid foundation. In many cases really smart people with tons of experience will disagree in significant ways. I don't think this is so true of castles; if you built an actual castle, I suppose a building inspector would make you adhere to various standards. Not so of software.
Some of the differences are silly, like which line to put your opening braces on. But others are quite profound, a key one being how much time you should spend trying to make things flexible enough to allow future functionality (vs. the YAGNI principle).
There are no pervasive standards for software development in the real world and if there are they change every 5 years at a minimum. Every company/employer/co-worker does things differently and the amount of 'human' input to the system I find frustrating. There is no 'one true way' or most efficient way of doing things, just a million ways to accomplish the same thing in a single progreamming lanugage nevermind different languages. This lack of 'best practices' leads to confusing code or artifical standards enforced by a particular employer - "Oh..We don't ever do it THAT way around here"
You say "Building a castle without a foundation or frame is inviting failure." The problem is that building a foundation without the castle is even harder to get right.
I've built frameworks before. It was great fun but it was guesswork at what might be needed and always wound up with a fair amount of wonderful stuff that nobody ever used. Including me.
That makes me very reluctant to dive into a framework with a zillion neat features when I might use only a couple. A mature framework that's been around and grown from requirements contributed by many projects might be a solid investment, or it might be a dense knot of interdependent parts that forces me to drag along much weight that I don't need.
Software is not like a building. If you manage dependencies carefully, you can modify the framework at any time at very nearly the same cost as doing it up front.
If a system has only one component that depends on the file system I can replace it with a database in a day. If a castle has only one stairway to the dungeon, it's still impossible to replace the dungeon.
Tuesday, December 04, 2007
Well, you mention "tangible outcomes" but don't actually give any "tangible benefits" of actually using a framework in your design. Don't get me wrong, I actually completely agree with you. I certainly advocate spending more time up front (but not too much) laying a solid foundation for the software because you will be paid back many times over the lifetime of the product. But it is hard to convince non-technical people of this. It is virtually impossible to give any tangible evidence to support this position.
But I've seen it many times in my career. Products that are hastily slapped together with little thought toward initial design/architecture will cost significantly more to maintain over the years. Poor designs can cost thousands of hours when the product enters maintenance mode.
I used to work with a guy who was "quick". People used to be so amazed at how quickly he could get a solution out the door. If we both started the same project at the same time, he would be way ahead of me after one month. But I'd catch and pass him at the end of the second month. And two years later he would still be fighting bugs and design flaws that were costing him hundreds of extra hours and crippling what he could actually do with the product. Meanwhile, I would have implemented 10 times the functionality in the same time and would have a very low bug count. New programmers would be easy to train on my product and the cost savings over the life of the product would be staggering.
But people just don't understand that. Because we can't do any more than give anecdotal evidence to try and convince them.
Wednesday, December 05, 2007
I came across the term "Technical Debt" through some posting in this forum and I think it is a good way to help non-technical users 'get it'.
Thursday, December 06, 2007
"But others are quite profound, a key one being how much time you should spend trying to make things flexible enough to allow future functionality (vs. the YAGNI principle)."
This is a question I often struggle with. One doesn't want to second-guess the future too much, but on the other hand, it's been my experience that if something is implemented in a reusable or extensible fashion the first time, it tends to be useful for more than the original problem it was intended to solve.
On frameworks, a related question arises. Is it sensible to spec your own internal, say, implementation/interface for a unit of work that then uses a specific ORM, so that if you ever need to change your ORM framework, you don't have to rewrite your entire app? At which point do you tightly couple to the framework -- or switch to a metaframework (like Spring)?
Friday, December 07, 2007
First of all, people do use frameworks! Programmers tend to think in terms of programming languages, but in most cases, once you pick a language, you've also picked the framework that goes with it. Of course, certain languages (such as C++) have multiple frameworks to choose from.
What you are trying to say (or should be wanting to say) is that the tradeoffs between frameworks in software construction are different than the tradeoffs in any other kind of construction (buildings, electrical circuits, etc) due to the abstract nature of software.
In software, it is possible to rebuild everything from scratch, whereas it is out of the question for a constructor to make his own raw materials, or for an electrical engineer to make his own DSP, capacitors, resistors and other components. Furthermore, components in other disciplines are more standardized in terms of interface and other usage parameters, which makes development (and second-sourcing) much easier.
In short, the abstract nature of software makes it a different kind of beast to develop.
Wednesday, December 12, 2007
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz