Talk:Bottom–up and top–down design/Archive 1

Archive 1

Not just software

I wonder if we can rewrite this to make it non-software specific, and then move the software example into its own subparagraph. I think the concepts are useful in any sort of design, from game design to any other sort, no? For example, I randomly came here from International_auxiliary_language.--Sonjaaa 22:31, Nov 26, 2004 (UTC)

I agree we should rewrite this article to make it less specific. Top-down and bottom-up approches are actually very important concepts in nanotechnology and microelectronics too. Guillom 07:56, 23 August 2005 (UTC)

I agree too, but unlike Guillom, I think the issue is much more general than in microelectronics and nanotechnolgy - top-down design concerns engineering design in general, including mechanical, aeronautical, electrical, electronic, chemical engineering. Sangwine 15:19, 8 October 2006 (UTC)

Merge from 'Top-down programming' ?

These two articles were apparently written independently by authors who were unaware of each other's efforts. Chris the speller 18:26, 31 October 2005 (UTC)

I dont think that the two pages should be merged. top down and bottom up where pioneared by IBM for software design, These design techinques have been developed for software other areas may have taken them on but they still remain software design techinques at heart .

I disagree. See the section above about 'Not just software' - top-down design probably existed before software. It is an engineering design methodology, and software just happens to be one branch of engineering that uses it. Sangwine 15:21, 8 October 2006 (UTC)

Well, since the starting line of the article says it's about information processing, I believe programming can rightly take its place here. Moreover, programming is becoming more universal.

• 1. Why do you know?

2. Why do you care?

3. Who do you think you are?

4. If you thought they should be merged why did you not do it yourself? —Preceding unsigned comment added by 212.219.57.50 (talk • contribs)

• • WP:NPA Your first three questions are invalid. On the fourth - while I didn't make the comment you're responding too, it's fairly common for people to ask about major merges and similar edits - a lot of information would be moving, some might be lost as duplicated, and especially it might be considered that any pair of articles that are merging might be unsuitable for merging for some reason. Compare in the same field the business and development articles for the Scrum process - while similar (and someone suggested a merge), they are not close enough for a merge. Someone going ahead and doing it themself would then be doing something that has now been discussed and by consensus resolved as two different things. That's a good reason not to just go ahead and do it. --Firien § 12:29, 30 August 2006 (UTC)

What about nanotechnology?

This terminology is also used in nanotechnolgy as can be seen from this wikibook extract:

Top-down and bottom-up approaches

Top-down refers to the traditional workshop or microfabrication method where tools are used to cut, mill and shape materials into the desired shape and order. Bottom-up refers to methods where devices 'create themselves' by selfassembly. Chemical synthesis is a good example. Bottom-up should broadly speaking be able to produce devices in parallel and much cheaper than top-down methods, but getting control over the methods is difficult when things become larger and more bulky than what is normally made by chemical synthesis. Of course nature has had time to evolve and optimize self-assembly processes that can do wonders.

Shouldn't this be described as well?Hauberg 14:06, 23 October 2006 (UTC)

Nice find. I integrated some of this text into a new Nanotech section. Antony-22 21:47, 19 November 2006 (UTC)

"Top-down" and "bottom-up" disambiguation pages

Is there a reason "top-down" redirects here while "bottom-up" goes straight to the disambiguation page? Shouldn't they be made to be symmetrical? Antony-22 15:53, 21 November 2006 (UTC)

Complete Utter Bull Dung

"Top-down programming is a programming style, the mainstay of traditional procedural languages, in which design begins by specifying complex pieces and then dividing them into successively smaller pieces. Eventually, the components are specific enough to be coded and the program is written. This is the exact opposite of the bottom-up programming approach which is common in object-oriented languages such as C++ or Java.

The technique for writing a program using top-down methods is to write a main procedure that names all the major functions it will need. Later, the programming team looks at the requirements of each of those functions and the process is repeated. These compartmentalized sub-routines eventually will perform actions so simple they can be easily and concisely coded. When all the various sub-routines have been coded the program is done.

By defining how the application comes together at a high level, lower level work can be self-contained. By defining how the lower level objects are expected to integrate into a higher level object, interfaces become clearly defined."

This is complete bull dung. Procedural coding can be done without defining one huge main procedure and dividing it into smaller subroutines. Many times a programmer thinks of small procedures and big procedures in different orders. Sometimes small little procedures are created first, to then work on a bigger procedure later. Similarly on object oriented hyped development, people will write small methods in their objects or big methods in not a black and white top vs bottom up way. In fact an object must be declared before use many times, forcing top down design instead of smaller little procedures in procedural coding. The object locks the design into the object early, whereas in procedural coding and modular programming one can rearrange his design without bonding it to a big heavily designed object.

This article sounds as though it comes straight from the OOP marketing hype department, and is void. The entire article is full of misinformation and bull dung.

In addition, methods of an object in Java, C++, modern pascal, are just procedures that have a hidden "self" parameter.

The article also made no mention of Modular programming and focused on OOP being the holy grail. I added some information about Wirth creating Modula to try and make the article at least a little more reasonable.

Another issue is real world examples.. the Windows API and the Unix API have been reused for decades, and are not developed using object methods.. but rather plain procedures. This just goes to prove that almost all DLL libraries and DSO/SO libraries out there coded in a procedural manner, are using bottom up or "reuse" style coding. In other words, the idea that traditional procedural coding is top down is ridiculous.. considering some of the Unix API's go way back to 1970 when procedural programming was popular and frankly it still is (modular programming and procedural coding are related).

Some of the most reused OS API's in the world are done in procedural and modular manner.. and there are far more "reused" operating system API's coded with procedures in modular manners, than there are OOP API's for OS's. OOP can be reused, and so can procedures... procedures can be bottom up and/or top down.. and so can objects.

The idea that OOP enables magical bottom up reuse where procedural programming doesn't is a complete utter hyped lie.

In fact the very definition of bottom up design and top down design is extremely vague and pretty much meaningless from looking at this article. LFiveZeroFive (talk) 23:00, 6 March 2008 (UTC)

WP:Be Bold, WP:Cite Sources, but WP:NOR, etc. Tag the page appropriately if you don't want others to be misled, if the content merits it. Oh, and please put new Talk page comments at the bottom of the page, thanks. Cheers! :) --NightMonkey (talk) 01:17, 24 January 2009 (UTC)

what about top-down and bottop-up approaches in portfolio selection?

I mean approaches for selecting assets for a portfolio, this would be useful to add it since it is quite popular phrase. however im afraid im not capable of doing it so im just rising the discussion —Preceding unsigned comment added by 81.129.80.176 (talk) 21:52, 11 February 2009 (UTC)

Lego picture - not good example

"Lego Racer Pro/ENGINEER Parts is a good example of bottom-up design because the parts are first created and then assembled without regard to how the parts will work in the assembly."

• In any engineering project, you will work with basic parts that were not designed for your specific project. This has nothing to do with it being top-down or bottom-up. The lego car's designer(s) may have designed the car in a top-down or bottom up way - we don't know. You can't describe top down or bottom up with a single picture. I'm removing it Fresheneesz (talk) 19:31, 5 May 2009 (UTC)

Fresheneesz, you are exactly wrong. That is exactly what bottom-up development is all about. Reuse! Generic components, not designed with a specific project in mind. Not tainted by any particular project's specifics.

The part about software development is really bad and probably needs a complete re-write

Currently many programming languages are named in the article while the concept of top-down/bottom-up is irrelevant of programming language and therefor the statements including programming languages must be off-topic.

The concept of top-down/bottom-up is irrelevant of functions, procedures, classes, methods and other language specific features. Therefor all statements involving any of those must be off-topic too.

The concept of top-down/bottom-up has nothing to do with object orientation, so all statements involving that must be off-topic too.

Also the concept of top-down/bottom-up has nothing to do with splitting a big problem into smaller problems, these are called abstractions and can be both bottom-up or top-down. (This means almost everything written about software development in this article is false.)

I agree with the person who wrote "Complete Utter Bull Dung"

Examples I believe to be correct about this concept are:

Top-Down:

* Model the users goals
* Translate these goals into a user interface design.
* From the user interface model design the business logic.
* From the business logic model design the persistence logic.

Middle-Out:

* Model the for the system under design relevant reality
* Translate this model into a model of the business logic.
* From the business logic model design the user interface and the persistence logic.

Bottom-Up:

* Model the information that the users want to receive from the system.
* Normalize this information into the persistence logic.
* From the persistence logic design the business logic.
* From the business logic design the presentation logic.

I will put some time into studying this subject before editing this article, but to me it just seems to be very wrong.

80.112.235.209 (talk) 14:52, 25 February 2010 (UTC)

Er, how do you think stuff is modeled? Using functions, procedures, classes, methods and objects! Not that I disagree about the section's quality, it's just this particular bit of your comment doesn't make a whole lot of sense. --Cybercobra (talk) 03:06, 26 February 2010 (UTC)

Instead of using functions, procedures, classes, methods and objects etc to describe the concept, it might be better to describe it using layers or components. Functions, procedures, classes, methods and objects etc can be used to implement these layers or components, but that is totally irrelevant to the concept of bottom-up/top-down which is an aspect of the software development process. This article should describe what the software developers do, not what the inner workings are of the software product that is delivered. When you are talking about functions, procedures, classes, methods and objects etc, you are talking about the inner workings of a software product. 80.112.235.209 (talk) 14:42, 26 February 2010 (UTC)

Examples of bottom-up programming

Right now, i cannot undertand how bottum-up designing is supposed to work. You always start a project with a rough plan which then is described more precisely. With bottom-up design, as it seems to me right now, you start developing something concrete, but actually don't know yet for what to use it ("oh, we just coded a program that can encode music very efficently, but don't know the heck where to use it"). --Abdull 14:03, 24 February 2006 (UTC)

Pure bottom-up design would probably be as you say ("oh, we just coded a program that can encode music very efficently, but don't know the heck where to use it"). You're correct that such a thing wouldn't work. A rough top-down plan would of course be drawn first. However, in pure top-down design it would be further refined smaller and smaller, whereas in a bottom-up plan you would jump to the bottom, solving small problems first and linking them together to solve bigger ones. For example, you'd decide that you want to make an game. From a top-down approach you'd decide exactly how you want the game to turn out, then break it down into smaller and smaller projects in order to realize that initial vision. With a bottom-up approach you might start working on a combat system, and you might start working on a story, and you might start working on the graphics, and then start fitting the pieces together and see what kind of game you're ending up with. TomTheHand 18:45, 24 February 2006 (UTC)

Hi TomTheHand, thank you for your quick reply! Your example really helped me getting an idea on how bottom-up design is supposed to work. Bye, --Abdull 00:32, 26 February 2006 (UTC)

In software and systems design, top down design is really intended for functional decomposition, not for the low level design. In reality I'm not sure that a pure top-down or bottom-up process exists in practice, or was ever intended as anything more than a concept of one extreme or the other. Requirements and design (and testing for that matter) always seem to push back on each other to some extent. That said, bottom-up design is not a model for designing something new or innovative. It is a reality however, due to the ecomony of common parts, reuse of code, the expertise of a detailed designer, and "constraints" (usually the word that someone uses when they ask for bottom-up design). Example: General Motors likes to manufacture a car (minus the powertrain) for 4 years to justify the high tooling expenses. They also like the powertrain to stay relatively stable for 4 years. But the powertrain is introduced into a car design that is two years old, and the new car is designed for a powertrain that is 2 years old. There are also some revolutionary designs, but many car platforms are evolutionary to avoid a complete shake up. So when the top-down guy is writing the requirements for the new chassis, he must take into account the powertrain that already exists. Likewise for the top-down guy that writes the requirements later for the powertrain. Bottom-up design results from a realistic compromise that always seems to creep into a top-down approach. 68.61.94.26 05:53, 9 November 2006 (UTC)

We (thinkbottomup.com.au) say scope top down, design bottom up 03:25, 28 April 2010 (UTC)

Seperate article for top down and bottom up development of countries etc. in geography needed.

Bottom-up-design discussion

I'd like to see mention of beginning the design of a system starting with the most technically challenging pieces and working down to the grunt work (the stuff that is "in the bag"). Many projects fail to take on the most challenging work and, after a lot of the easy stuff is done, come to a brick wall which cannot be overcome due to technical difficulties. That causes project failure,at last truruututyututryty —Preceding unsigned comment added by 203.147.88.10 (talk) 15:28, 29 October 2010 (UTC)

The Programming/Bottom-up design section of the article says much more about designing LEGO race cars with Pro/Engineer than it does about designing programs bottom-up. Perhaps this text should be rewritten by somebody who has actually written a program from the bottom up.

Anyway, the big advantage to bottom-up design is that you always have a fully testable system, in contrast with top-down design, where you write the main() function that instantiates non-existent objects and calls non-existent functions, and you can't even check if it compiles, let alone test it, until the entire design (which was done first, on paper) has been translated into code. Then you spend a year debugging it, or you have to rewrite half of it over again because some library you used doesn't work the way you thought it did, which leads to project failure.

In a bottom-up design, by the time you write the call to do_something_incredibly_complicated(), do_something_incredibly_complicated has already passed all its tests. Instead of being a gigantic "what-if" whose interface you might have to change, resulting in code being rewritten, it is a well-fashioned tool, ready to use.

Here's a source that can be referenced in the bottom-up section: http://unintelligible.org/onlisp/onlisp.html#SEC8 (also available as a separate essay: http://www.paulgraham.com/progbot.html)

75.186.5.185 (talk) 17:42, 27 November 2010 (UTC)

stray text

I found this text somewhat lost in the middle of the article (in the parsing section to be specific) and did't know what to do so I erased it and pasted it here:

simple example of assembly methods

"Identify the dependencies between the components of an assembly. Assembly components are individual

parts or entire subassemblies that, in turn, consist of other subassemblies and/or parts. Identifying these dependencies helps us to determine the best approach to create the assembly: bottom-up, top-down, or both.. Consider, for example, the assembly of two blocks and a bolt that holds them together. The bolt size depends on

the hole size in each block. Thus, the best approach to create this assembly is to create the two blocks as separate parts, and merge them into a blank assembly model; this is the bottom-up approach. We then create the bolt in the assembly model to relate its size to that of the holes; this is the top-down approach." —Preceding unsigned comment added by 188.82.211.174 (talk) 12:33, 11 January 2011 (UTC)

Peer Review

There are only a few citations used throughout the entire article. There is no way of knowing where much of the information is coming from. The article focuses mainly on computer and software based top-down and bottom-up processing and like another reviewer said, these types of processes were around long before the computer was invented. It would be helpful for the broad definitions of both top-down and bottom-up processing to be stated at the top and then go into sub-headings where you talk about these processes in regards to different topics (one heading for software, another for cognition/psychology, etc). I did not find the Lego picture to be a clear example of bottom-up design. It would be helpful for these topics to be two separate pages, but since you have to combine them for a class it would helpful to have examples of the ways that top-down and bottom-up work together in processing information. The State organization section seemed a little muddled when talking about the German and the French, the ideas being conveyed were not clear. I thought the neuroscience and psychology section was great and should be the example for the other sections. There are only 6 references to this article and I think there should be at least a few more. Every section should have as many citations as possible so readers can go straight to those sources for more information, right now I am not able to check some of the information that I don't understand because I cannot tell where it is coming from. The Architecture and Ecology sections should have more added to them as well. There is a lot of great information here! Some of the hyperlinks that I clicked on to get more info sent me to pages that no longer exist so those should be changed to regular words instead of links. Good job on getting information, it should just be organized a little better with many more citations! AlyssaThomas12 (talk) 21:06, 19 October 2012 (UTC)

Change in article name

The article includes the term "design", however it discusses top-down and bottom-up approaches in several contexts. I am in favour of the evolution of the article but since it is not about design, then we would probably remove the word design from the title. What do you think? Rentzepopoulos (talk) 08:28, 12 February 2013 (UTC)

Too much jargon

I feel that the introductory paragraph and initial descriptions are written with far too much technical speak and are extremely hard to understand, even for a person who is quite familiar with the concepts like myself. I am a senior psychology major, and when I read the descriptions of the two processes, I was completely confused! I believe that the goal of an encyclopedic entry should be to enable a reader who is completely uneducated in a topic to walk away from reading it feeling as if they have a better understanding of the topic. This article falls far short of that, in my opinion. Snagglepuss24 (talk) 17:01, 12 April 2013 (UTC)

I'm not sure how we can remove jargon and keep it informative and accurate. Do you have a suggestion for a change? Walter Görlitz (talk) 19:10, 12 April 2013 (UTC)

            Well, I would suggest that one shouldn't talk about top-down and bottom-up as inductive or deductive approaches.  People use these terms differently, which isn't to say that 
                there are no clear meanings.  Deduction and induction are two parts in a series of systematic thinking, which also includes abduction and inference to the best explanation.  So, 
                whether you're bottom-up or top-down shouldn't affect whether you should participate in only one aspect of thinking.  That's crazy.  

           These are attitudes based on the resources one is best fit to apply in a general problem solving situation.  I think one shouldn't even be focusing on top-down/bottom-up at all.  
                It's a red herring.  In fact, people talk about a middle-out approach (Sydney Brenner, Denis Noble).  

          As for whether it takes a different meaning for design should not be relevant unless it is to clear up some communication issues.  That is, it shouldn't affect your behavior or the 
               type of experiments you decide to run whether you find out you're a bottom-up or top-down designer.  — Preceding unsigned comment added by Gahnett (talk • contribs) 04:27, 3 September 2013 (UTC) 

Repeats the analysis-synthesis myth

Top-down design in software or in systems engineering can reasonably said to involve decomposition and analysis, though "analysis" is probably too broad a brush to be useful here. But in no way is top-down design more tied to deduction than bottom-up design. The referenced article contains an extremely poor account of deduction inconsistent with all modern and ancient descriptions of deduction from mathematicians and philosophers:

"Deductive reasoning works from the more general to the more specific. Sometimes this is informally called a "top-down" approach. We might begin with thinking up a theory about our topic of interest. We then narrow that down into more specific hypotheses that we can test."

All hypothesis testing (all empirical science) is inductive reasoning; it, in the strictest sense, affirms its consequence (see Quine, Hume and the rest). Both top-down and bottom-up design can equally be called inductive reasoning. The equation of synthesis with induction likely stems from Design Thinking nonsense, which relies on equivocation of two meanings of the term analysis: analysis is decomposition, hence the opposite of synthesis, which means assembly (in their view). Even if you accept this position, design, whether top-down or bottom-up, would be called synthesis. But no sense of the terms analysis and synthesis have any explanatory power toward the goal of differentiating top-down and bottom-up. — Preceding unsigned comment added by Bill Storage (talk • contribs) 06:07, 8 November 2013 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to 3 external links on Top-down and bottom-up design. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive http://web.archive.org/web/20121015165640/http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.57.224 to http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.57.224
• Added archive http://web.archive.org/web/20160127102314/http://search.bwh.harvard.edu/pdf/ChangingYourMind.pdf to http://search.bwh.harvard.edu/pdf/ChangingYourMind.pdf
• Added archive http://web.archive.org/web/20081012060801/http://www.foresight.org:80/updates/Briefing2.html to http://www.foresight.org/updates/Briefing2.html

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 16:53, 27 February 2016 (UTC)

Top-down 'design' is analysis - not design; semantic confusion obscuring truth.

I am concerned that this an issue arising out of careless use of the word 'design'. I would like to suggest the following argument for clarity:

The terms analysis (literally cutting up of a problem) and design (drawing of a solution) are thrown around rather carelessly, as if they could be interchanged without causing semantic damage.

If you have a problem, such as an invoice system, or building a house, then you need to perform analysis as a first stage. You have the house or invoice system as your starting point. The invoice system may exist, as a paper based system; the house doesn't exist yet. However, both problems need top-down analysis as the first stage towards finding solutions. In analysis you must ask what each is to achieve i.e. the outputs - invoices, a good place in which to live. This determines what inputs are needed and how they must be processed to achieve those outputs. In the case of the invoice system the analysis will produce a schematic/logical model of the existing system showing its outputs, inputs and processing; a flowchart, data flow diagrams and so on. In the case of the house, the analysis will produce a description that fits the requirements - so many people to live there so there must be so many bedrooms with so much space; they need to cook food so a kitchen of a certain minimum size etc.

Having thus established, down to the last detail, what is required, and the relationship between those requirements as the hierarchical structure of abstractions involved, (cooker in kitchen or line total inside invoice calculation) it is then possible to move to design.

Design cannot logically be 'top down'. I suggest that this is a paraphrase made by those who fail to realize that they are talking about analysis and design, which are two quite distinct phases with distinct methods. They think that they are 'designing' but are actually analyzing and then designing. Although you could argue that so many make this mistake that that makes them right as that is what 'design' has come to mean.

Perhaps as the products of analysis are 'drawings' e.g. flowcharts and structure diagrams some have erroneously been led to think that they were designing? Yes, those charts might then form the skeleton of the design but they in-themselves are not the design, they are the products of the analysis. A caring robot to dress someone? Analysis of the existing process reveals that the socks must go on first, then the shoes. Flowchart that. Then the design for the solution must take the same flowchart/logical sequence but the act of deriving that flowchart does not belong to the design phase, it belongs to the analysis - the logical sequence belongs to the problem domain, not the designed solution. You simply cannot break that logic - unless you are in the phone booth, becoming superman, of course. When it comes to design you stick with that algorithm but adjust the way in which the processes are performed: different agent, maybe different types of socks and shoes but not a different logical order.

Design takes the fruits of analysis, the structure of the problem, with its single top and all of the decomposed abstractions (hierarchically nested groups) and selects methods of processing, from a range of options, to be applied to the problem structure. You need entities to separate the external environment from the internal? Then find/select a material that will do this - maybe bales of straw, maybe bricks - you are the designer, you find the best solution from the options. Maybe you need to do more analysis - is the thickness of the wall an issue? Maybe your analysis wasn't thorough enough? You know that you need to move the invoice from the company to the customer. You the designer have options - bicycle, drone, internet, which will it be?

To summarize, analysis and design should be seen as two semantically distinct but related processes:

Analysis is about discovery of the nature of the problem, for which a solution is required.

Design is selecting best-fits from a range of options to produce/engineer that solution.

Therefore analysis is, and can only be, top-down (start with the whole thing and end up with a definition of every part) and produces a structure representing the parts and the links between them whereas design can never be top-down as you cannot logically start with the 'whole design' i.e. the definition of the finished structure, with all of its parts in place, and then start breaking that down to start designing those parts. If you say that you are doing that then you are going back to analysis. You did not have a complete 'design' in the first place. You had a complete name for the problem you wished to solve but that can only sit at the top of the analysis. You only get a top of the design once you have completed it in every part.

Maybe many 'designs' fail because they were designs that were attempted by those who failed to complete a full analysis of the problem in the first place, rather assuming that they knew what they were to design rather than actually finding out in detail first? Lessentropy (talk) 10:22, 8 October 2017 (UTC)