|
I generally work from bottom-up, and get the work done, nothing special...
#include <iostream.h><br />
<br />
int main()<br />
{<br />
cout << "Hello" << endl;<br />
return 0;<br />
}
cl
|
|
|
|
|
But virtually all my successfull products in the field have been bottom-up. Weird, when I think about it. I guess time is difference. Given enough time, I will burn it all doing top-down.
Please excuse the tube, but I haven't eaten today.
|
|
|
|
|
Actually. I like to see the big picture first; work out the domain classes involved then start on the Unit Tests, filling in as I go.
Sometimes there are swirling analysis and design passes that cause some tests and code to go away, but usually the frame survives and the details change.. Is that the Top Down logic, bottom up operational choice?
It's more iterative than that..
Jonathan Harley
- Eschew obfuscation
|
|
|
|
|
I start from all CListCtrls i have in my application. 
<font=arial>Weiye Chen
When pursuing your dreams, don't forget to enjoy your life...
|
|
|
|
|
Weiye Chen wrote:
I start from all CListCtrls i have in my application.
That has merit.
Actually if the App isn't just one CListCtrl I'm not really interested.
Regardz
Colin J Davies
* WARNING *
This could be addictive
The minion's version of "Catch ![Green Alien | [Alien]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/alien.gif) "
It's a real shame that people as stupid as you can work out how to use a computer. said by Christian Graus in the Soapbox
|
|
|
|
|
Jon Harley wrote:
Actually. I like to see the big picture first; work out the domain classes involved then start on the Unit Tests, filling in as I go.
I agree with you there. I like to see what I am getting myself into before I commit to anything. It is then that I can decide on the team to work with, or the team to do the project if I am not going to be involved.
I can work out the classes to be made etc. I can also determine which features to implement first depending on their priority as I do various releases of the app.
Let's make things simpler than possible.
|
|
|
|
|
Well it all depends, how you approach a problem. The structured or functional approach is Top-Down, you start from a bigger picture and apply divide and conquer technique. In Object oriented philosophy, things work opposite. You need to find out the objects responsibel for fulfilling some use case and then go upward, find categories/groups of related objects and then relateed groups form domains. Once you have domains, you can allocate resources or find resources ahead of time.
While in top down techinque you cant plan ahead of time, you have to wait, until you reach some point, where we you need a domain expert at that time, so you cant plan properly in this case.
Lemme know if you need further detail
|
|
|
|
|
Mukhtar wrote:
Lemme know if you need further detail
Naturally, I was trying to say I wasn't sure I saw a 'correct' choice in the survey for me; but you knew that..
|
|
|
|
|
I do what needs to be done when it needs to be done. Sure, not the best way to develop apps, but that's what happens when your company's more interested in meeting the deadlines than quality of the product. 
"if you vote me down, I shall become more powerful than you can possibly imagine" - Michael P. Butler.
|
|
|
|
|
That is so true. If a company don't pay for quality, don't give it.
Norman Fung
|
|
|
|
|
But i expect myself to write quality code. Help! 
<font=arial>Weiye Chen
When pursuing your dreams, don't forget to enjoy your life...
|
|
|
|
|
I also work very fuzzy in my code. But I always check whether it's bugfree or not. I cannot afford bad code I run my own company, so I have to pay for it when my customer starts complaining about a low quality program.
It really depends. I usually start with a skeleton applications and extend the posibillities of it while implementing my business model.
"Every rule in a world of bits and bytes can be bend or eventually be broken"
|
|
|
|
|
From my side ...
A small number of IT companies give priority to quality. thay just want the product to work anyway 
Mohammed Derbashi
|
|
|
|
|
As a Software Architect I have to be concious of the larger picture; of infrastructure, business need, politics, et alia. In that sense there is a very top-down approach -- however, as subsystems are modelled, pieces come in more manageable support structure sorts of things. Occasionally, I set the tone of an architecture and then have junior architects "fill in" the details. This, obviously, is prior to implementation and possibly during a prototyping phase.
When actually programming, I like to create the broad strokes with stubs to flesh out use-case realizations and or additional services/applications -- this also assists my QA teams in creating their scripts as well as allows for better unit testing and coverage.
How do I program? Top down, bottom up, the project left turn with a course correction maneuver to keep scope and clients in line, 90° to reality and Mrs. Whatsit always watching *wink*
Ian Mariano - Bliki | Blog
"We are all wave equations in the information matrix of the universe" - me
|
|
|
|
|
I drive a car like this one[^], and when the going gets tough, I drink ![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif) ("bottoms up!")
Software Zen: delete this;
|
|
|
|
|
Software Zen: delete this;
|
|
|
|
|
lol...
"Every rule in a world of bits and bytes can be bend or eventually be broken"
|
|
|
|
|
I still remember my old school days, almost 20 years ago, when the IT teacher told us something that made sense to me at a time:
- "Take any problem of any size, and try to cut it into smaller chunks, then cut down those chunks into smaller chunks and so on until you end up with small, managable chunks."
This sounds like bottom up, but actually, I feel that the "top down" part would be the "problem cutting" while the "bottom up" part would be individual chunks.
My own technique, once I have cut down my problem and started to manage some of the smaller chunks is to glue things back together until I have one or more "large" chunks of solutions. Then I play with those.
The only problem is: The total number of chunks that I started with is never the exact same as what I had at first, because, for any problem that is big enough to force us to go through this technique, there is a learning process that allows one to "discover" new chunk of problems, and realize their solutions. There is also, from time to time, some unexpected solution that turns out to be re-usable and that solves a considerable abount of problems.
|
|
|
|
|
- "Take any problem of any size, and try to cut it into smaller chunks, then cut down those chunks into smaller chunks and so on until you end up with small, managable chunks."
I was told that too, and I would call it top-down, but it seems very naive to me. Top-down implies that you already understand the problem. In reality, I always find you don't understand your problem until you've tried to solve it. I think refactoring is inevitable except in trivial cases.
I usually start with 'proof of concept'. I'm not sure if that's bottom-up or top-down.
|
|
|
|
|
At first I thought combination, because I write mostly Windows programs using MFC. So I am starting with the interface. But, I have also written code for embeded systems (no interface), which required starting at the bottom and working my way up. Therefor, it depends!
INTP
|
|
|
|
|
|
Mmmm...In-n-Out. Double Double...
When I can talk about 64 bit processors and attract girls with my computer not my car, I'll come out of the closet. Until that time...I'm like "What's the ENTER key?"
-Hockey on being a geek
|
|
|
|
|
David Stone wrote:
Mmmm...In-n-Out. Double Double...
Yeah, they don't have those here on east coast. Guess it's a Southern California thing, you lucky guy!
Marc
Microsoft MVP, Visual C#
MyXaml
MyXaml Blog
|
|
|
|
|
I know they don't. I was in Alabama and Virginia for three weeks. The first thing I got when I came back...Double Double with grilled onions.
They're only in Cali, Arizona, and New Mexico. They might be in Oregon or something...but I don't think so.
You just gotta move back out here. 
When I can talk about 64 bit processors and attract girls with my computer not my car, I'll come out of the closet. Until that time...I'm like "What's the ENTER key?"
-Hockey on being a geek
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
