|
|
|||||||||
|
|||||||||
| |||||||||
|
|
|
| |||||||||
| View Poll Results: Most important aspect in developing data-driven applications | |||
| A well designed Database | | 8 | 42.11% |
| Good Application Code | | 1 | 5.26% |
| A solid written Project Specification | | 9 | 47.37% |
| Other | | 1 | 5.26% |
| Voters: 19. You may not vote on this poll | |||
![]() |
|
|
«
Previous Thread
|
Next Thread
»
|
Thread Tools | Search this Thread | Rate Thread | Display Modes |
|
#1
|
||||
|
||||
|
Most important aspect in developing data-driven applications
Please give a breif description on why you believe one aspect is better than the other. If you choose other, please specify. Thanks...
__________________
~ Joe Penn |
|
#2
|
||||
|
||||
|
I went with a well designed database because if you got great code but crappy db you'll be having to write more complex querys or go out of your way with weird code to get something done which could be done with a well written db.
__________________
Miscellaneous Software Viper_SB Developershed E-Support Anyone else play chess? Challenge me |
|
#3
|
||||
|
||||
|
Agree with Viper on this one, for pretty much the same reasons.
__________________
--------------------- -- SilkySmooth -- --------------------- Proxy | Little Directory |
|
#4
|
|||
|
|||
|
As much as I believe database design is more critical than application code, I don't believe you can arrive at either without a good spec (IE the "business rules"), so I voted for Spec.
|
|
#5
|
||||
|
||||
|
I also voted for spec- creating anything, no matter how good it is, is worthless if you have to scrap it down the road. I've found the more time you spend developing a spec and running it by the relevant parties, the better the end result and the less time it takes to build.
|
|
#6
|
||||
|
||||
|
Oh dang, forgot to mention that I chose spec also. Not only do I think it is very important before starting anything on a project, but it is also as equally important to have the solid specifications done before even providing firm pricing on a project.
Honestly, I can't even see how anyone can even provide pricing on a project that involves custom database programming, application programming and UI design without specifications. |
|
#7
|
||||
|
||||
|
I should note then that this question should be somewhat rephrased because there are two entities. Developing for someone else and developing for yourself, however this does not change my point of view.
Agreed having a good spec is important but it is not my primary concern and I can certainly say that I would not have won some of the larger contracts I have, if I hadn't been so flexible with the spec. When I am developing for myself, I very rarely write a full spec because I know for a fact that no matter how far along the project got, I would deviate from it as I am a *thinker* I generate ideas all the time, I have 3 or 4 note books here full of things I want to create / learn / do etc. So I would build until I am satisfied with the end result. Yes obviously there are certain goals that must be achieved but they would be in my initial notes when I first thought of the project. As for working with clients, it depends on the client I suppose but I have yet to work with anyone who has provided me with EXACT specifications no matter how long we went over them prior to starting work. Because people see new things, they have ideas, they change their minds etc etc. Pricing a project in my opinion is easy, you just allow / add some leway for additional development. So yes a Spec is important, but it's not MY primary aspect and I feel the question should be categorized a little more clearly ![]() |
|
#8
|
||||
|
||||
|
Yep I agree with SilkySmooth (what do we call you for short? Silky or Smoothy?
)I rarely have a contract that doesn't change there specs along the way, you have to adap to it as you go. It's gotten sometimes where they rethought the whole thing and I had to redo the db layout all over again. So I suppose it could depend on the project you're working on at the time. |
|
#9
|
|||
|
|||
|
I would have liked to have voted for a good spec, but most of those pretty much go out the window as the project progresses. I call it "Feature Creep", "Oh Chris, we would like to be able to do this, and that, and that...."
I went for the database. If I have a good db layout I can add new features w/o much problem. But if my db is crap not only do I have to fuss with complex queries, but I may also have to redesign the db. That generally means there is lost data or some other problem.
__________________
The Dude I'm the Dude. So that's what you call me. That, or Duder, His Dudeness, Or El Duderino. If, you know, you're not into the whole brevity thing |
|
#10
|
||||
|
||||
|
Quote:
He is Ade |
|
#11
|
||||
|
||||
|
ah true
|
|
#12
|
||||
|
||||
|
Quote:
The Maste.... :cough: Ade or Silky is fine ![]() |
|
#13
|
||||
|
||||
|
Quote:
A specification is a living document that serves three-fold in any project, from developing applications to building high rise towers. The first purpose of the specification: To provide to the purchaser a written document specifying your obligation as the contractor, and their obligations as the purchaser. The second purpose of the specification: To provide a roadmap of the project, from start to finish to show the exact inner workings of the project. This can be viewed as a blue print and something that can be referenced in the future if the application needs to be expanded to provide more services or features - by you or by another company. The third purpose of the specification: The legal aspect. Signed specifications will go a long, long, long way in a court of law. A signed specification is a legal document. As to always changing the specifications, thats why they are called living documents. All specifications are living documents, thats why there are such things as modifications and adendums: -------------------------------------- Specification Blah Dated Blah Blah Blah Blah Approved by: Mr. Blah Company: Blah purchaser -------------------------------------- -------------------------------------- Adendum # 1 to Specification Blah Dated Blah This adendum affects paragraph 3 section 3.8 of specification Blah Blah Blah Blah Approved by: Mr. Blah Company: Blah purchaser -------------------------------------- etc for each change to the document. As for personal projects of any size, the specs are just as important. The very first thing an investor will ask you for is the specification documents... ![]() |