Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I liked the question about favorite program layer: What is your favorite program layer to work on?

What order do you build them in or do different team members develop corresponding parts simultaneously?

share|improve this question
show 1 more comment

18 Answers

up vote 4 down vote accepted

I think a lot of us, not being designers, tend to go for the layers we like to work with more first, those being the data and middle tiers. We tend to neglect the UI until we are forced to work on it. That said I think we go about it backwards, and that building a UI for the end user first would help to drive the other layers, and keep them more in line with how the application needs to work for the end user. How many times have we had to kludge stuff in the "real programming" layers to fit what the end user needs in the UI?

share|improve this answer
show 2 more comments

Risk First

Whatever layers that have features with the highest technical or social risk should be developed first. If you were to try bottom-up, you might spend a lot of time on making a layer that will need to be radically changed, because something above it has too many unknowns. (And similarly for top-down.)

In the case of parallel development, I recommend mocks or stubs be used. Mocks are better, because you can simulate some of the functionality and quirks of the interaction. Real, executing code seems to be a better form of communication than any specification document.

Your layers might match something like Conway's Law. If that is the case, then I think mocks are all the more important.

share|improve this answer
show 2 more comments

Generally I go something like:

  • Sketch out top level.

Iterate over the following steps for each "stripe" of the program's functionality:

  • Database layer.
  • Complicated stuff, e.g. calling unusual APIs, or multithreading.
  • UI.
  • Glue between db and UI.

Examples of stripes would be a report, or an input form, or a configuration screen, or a data extract.

And finally:

  • Tie stripes together.
  • Refine UI.
  • Performance.

So it's basically get an overall view, then work from the bottom up, then refine from the top down.

A common exception to this order is getting into a concrete piece of work in order to keep making progress, so for example if I'm tired of fiddling with CSS on a web page, it might be better to jump ahead and do the database work for the next stripe.

share|improve this answer
1  
Are you a lone developer? –  JeffO Dec 2 '10 at 19:27
add comment

First I dream it...

Then I spend time, simulating it my head. Here in the playground of my mind I'm free to explore it from multiple angles, until I have convinced myself of the solution.

Sometimes I write down the solutions briefly (high level designs) as rough sketches.

I then create it, iteratively grow it over time piece by piece until the dream a becomes reality.

Dream it -> Design it -> Grow a design into Reality.

share|improve this answer
4  
Yes I imagine myself as a user. And Imagine how a user would want to get things done. This is really important because for users this is the only form of interaction that they will have. Its easy to get this wrong if we don't put ourself in that mind-frame. –  Darknight Dec 3 '10 at 10:06
show 2 more comments

If I am really developing from scratch, I prefer to develop them organically. Which I guess means, from the inside out (start in the middle, work out to the ends).

So in a hypothetical, probably web-based application, if I had the following layers...

  1. DB Access
  2. Data objects
  3. Business logic
  4. I/O
  5. GUI logic
  6. UI visual/interactive polish

I would probably develop in this order:

  1. A single layer incorporating 2, 3, 4
    • If persistent data is important early on, possibly 1, 3, 4
  2. Separate data from interaction: 1, 2, and 3, 4
  3. Separate business logic from I/O
  4. Separate DB Access from Data objects
  5. Add UI: 5, 6
  6. Separate and polish UI

If a team-based project already has most of these layers established and you are talking about adding a new feature that has parts in every layer, a member of the team would most likely take responsible for one layer and develop simultaneously (assuming you have an architect/lead engineer who is able to look at the process as a whole and do a rough technical breakdown of the tasks required for each layer).

share|improve this answer
show 1 more comment

For me, it usually goes like this:

DetermineStakeholderNeeds();
GetUserStories();

FigureOutProgramFlow();         // Some rough sketches are often made of UI
VerifyWithStakeholders();

BreakDownProgramIntoPieces();

foreach (piece in pieces)
{
    PlanPieceOut();             // Visio, Pen/Paper, WhiteBoard, etc
    BuildDatabaseTables();
    BuildObjectClasses();
    BuildDataAccess();          // Get, Update, Insert, Delete, etc
    BuildBusinessLogic();       // Validation, Business rules, etc
    BuildUI();
    VerifyWithStakeHolders();
}

PolishUI();

Release();
share|improve this answer
1  
Sketches normally involve dumping the controls onto a form in Visual Studio, then print-screening it into Paint, and moving them around till they like it. Because of this, the users have a good idea of what to expect. I normally don't go into colors/themes until the end... just control positioning and layout. –  Rachel Dec 2 '10 at 20:13
show 3 more comments

The process is usually iterative, but I go "ground up".

Data first, the business logic, then UI.

In a multi-developer environment, I spec them in that order, then start each stage slightly in front of the later stage to give the subsequent teams something to build on.

share|improve this answer
show 1 more comment

I try to figure out what it would look like to the end user first, so I guess I go "top-down." This helps to clarify exactly how the program works so I can't screw something up later on.

share|improve this answer
add comment

I like the incremental "thin-slices" approach.

This means I complete one small user requested feature at a time. The idea is to write only those parts of each layer that is needed to complete the current feature, as simple as possible, developing parts of the architecture only when a specific feature calls for it. After each added feature, refactor the code so it doesn't get stale and let the layers and abstractions emerge when they are actually needed.

With this approach, there is no specific order layers should be developed, rather it depends on the current slice you are implementing.

This has a few advantages:

  • It makes it possible to release after each feature is added, rather than having to wait for whole system to be completed.
  • You can starting making money much earlier. See image below.
  • It helps make sure I create actual working software and not an architecture.
  • The client can test a the system early and give feedback as soon as possible.

I think this is an improvement compared to the more traditional write-each-layer-separately-and-glue-it-together-at-the-end method.

To visualize this, consider the system as an empty box, data storage at the bottom and gui at the lid. Adding features is akin to "tying threads of code" between the bottom and the lid until we are satisfied, box filled or not. A traditional method can maybe be compared to pouring code into the box, slowly filling it from the bottom up until it is 100% full and then be ready for release.

Here is an image to illustrate the idea of early releases (Shore):

alt text

share|improve this answer
show 2 more comments

25 years ago I sketched what I call the "Greek Temple" method of development. This models softare as a top layer of user interface, a bottom layer of hardware access, and middle columns of features.

First you do the foundation, to make sure that the app is feasible. That's low-level stuff like getting packets through to the server. It can also include user interface components.

Second you do the roof, which is the master menus, the way for some outsider to nagivate into and through the system.

Then you proceed onwards to building the columns. These can be done by separate programmers, or one at a time by one programmer. The pieces fall into place, hanging from the roof and supported by the foundation.

So that's the order I do things in. The foundation, then the top level user interface, and then the features, one pillar at a time.

And it still works, 25 years later.

share|improve this answer
add comment

I think unless we know in advance the dependency between the layers (which while not rare is not that common either) it is difficult to begin development with only focus on one layer at time. Usually I will start with business layer as ultimately this encapsulates the solution space to the problem, then after first draft I will do some UI because in initial stage UI has more affect on the business logic than DB, once UI and business logic are in some sort of agreement I focus on Business logic and DB layer. So there is a lot of going back and forth, iteration and feedback.

share|improve this answer
add comment

The project I am working on is creating templated user controls for Silverlight and WPF. With this project, my preferred starting point has been the GUI design. The reason for this is simple, this is what our users see and use to gauge how well we are doing in our development process.

That being said, we have also be slowly breaking up our development teams in to smaller and smaller groups that work on different layers. So most of my work has be with the GUI, so I am probably biased.

share|improve this answer
show 2 more comments

It's a nice question, but I believe the answer is pretty much dependent on what exactly you're programming.

For me it's really an iterative process. Now I have to admit that the GUI part is more or less omitted in the applications I write. Most of it is command-line interface. But this demands a design as well, to get the parameters as logically as possible into the main functions.

Actually, I neither go top-down or bottom-up, I go concrete-abstract-concrete. The first part of programming is actually on the drawing board, creating every class I believe is necessary. Then I start to create one, including the functionality. While doing so, I often find pieces of code that can either be used by other classes, or classes that could be adjusted so they could fit multiple objects (generic classes so to speak). They go next. When that is done, I concretize the inheriting classes and specific functionality, using the generics I've made earlier.

In the meantime, all of this has to be checked, so I need a crude interface for testing. This crude interface forms the basis of the final interface, and again points out which functionalities I need extra. So back to the classes and the process starts all over again.

During this process, I keep a clear record of what I've done, and what I believe I still have to do. "Done" can mean two things : functioning but can be optimized, and finished. "To do" can mean to things : optimize or create. So I can't really give an order in which I do things, as the whole project is continuously reshaped.

Regarding the reshaping, off course I don't keep on fiddling around with new ideas. Every step has only two reasons to be taken: 1) easy of use and 2) reduction of calculation time. As I work on scientific applications involving huge datasets and considerable calculation time, optimalization is really an issue that shouldn't be taken lightly.

share|improve this answer
add comment

I try to develop features horizontally, instead of adding layers vertically. That being said, I liked the latter approach a lot, but it usually resulted in overengineering about every layer involved.

Of course, there are certain things shared accross features, but I rather implement it for feature A and while implementing feature B, I look whether I could abstract the implementation of feature A to be reusable in feature B, without introducing dependancy (i.e. although I have a lot of similar code for A and B, I only unify what performs the same task).

  • I usually start by modelling the data layer.
  • After that, I build a mock layer, that gets its data from a single file (the data being simply serialized. I have an extra source file to define the initial data. Any time I need a reset or modification, I just compile and run it).
  • Then I build the views to display that data. Then, view by view, I add controls for the planned user actions and the neccessary methods to the data layer objects to perform the business logic.
  • At this point I start gluing the application flow together (hooking certain views into central menu, navigation between different views etc.), and find a suitable backend for my data to be stored.

If it makes sense, I have different storage mechanisms for different data objects and so on. I don't try to punch everything into one mechanism.

share|improve this answer
add comment

First of all, you must have a functional proof-of-concept where there is functionality all the way from the top layer to the bottom layer and back. Make all the assumptions you need (network is never down, database data is perfect, user reads your mind) and all the duct tape you can get (data is transferred manually using ftp or email and saved in the right location, and the data is perfect).

When you are done with that, you have a very good idea of where it is hardest to get it into production quality. If there is any places where you have no idea how hard it is to finish, it is by definition exceptionally hard.

Then you sort the things you need to do with the easiest on the bottom, and then you start from the top....

share|improve this answer
add comment

in the order required to get the first test of the first user story of the first feature of the first iteration working [XP/TDD]

EDIT: for those that missed the implied point: the order in which you implement the layers does not matter. As long as the interfaces are correct it will work regardless of which one you concentrate on first. As an XP/TDD fan, I do it in the order determined by the test cases in the implementation queue. If I have to do a big up-front design on something, I start with screen mockups and the object model, then the underlying database, and tie it all together using DDD. But the short answer is: the order doesn't matter

share|improve this answer
1  
Only build enough of each layer to get a working solution to the first story. It really does work. –  Tim Williscroft Apr 11 '11 at 4:33
show 2 more comments

Will identify the Business objects and create classes and interfaces, next will move to DB design and last will be the UI

share|improve this answer
show 2 more comments

In my current shop, there is some design and mockup done first, then I work from the bottom and a UI person works from the top. Though when we meet in the middle we sometimes find gotchas. I would be interested in hearing a well-thought out answer (too late at night for me now) on the part of the question involving what we like to do vs. what is best to do.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.