Hi,
I'm beginning to formulate an hypothesis, that I haven't designed any experiments for yet, so I can't call it a theory. It is this:
That Computer Science grads are taught C (C+, C#, whatever) and therefore have a "top-down" approach to software development. This top-down approach I define as being concerned with proper class definition, inheritence, polymorphism, etc. first, and the data layer takes care of itself, often via some Object Relational Mapper (ORM) tool.
Conversely, Information Systems grads are taught VB (and often SQL as well) and therefore have a "bottom-up" approach to software development. This bottom-up approach I define as being concerned with proper entity-relationship definition and the presentation layer is merely an extension of the database.
I do not believe either approach is superior in all circumstances: both may be better in certain instances.
It is less of a problem than the divide between Engineers and Developers. We really don't talk the same language!
I'd be interested in formulating debate around this topic, if anybody out there is also interested?
Comment by sleemanj, on 17-SEP-2007 19:22 ( IP: 202.78.155.23 , user id: 27497)
ReplyDeleteThe end user, the people commissioning you to design and build whatever it is, speak in terms of top level use case scenarios "I want to be able to do this, I want to see that, I want to ...", if the systems designer tries to design the system bottom up then they are not going to get a very good match to those top down requirements for the end user.
That's why a systems designer (I'm purposfully avoiding the term "software engineer" because it's best not to anger the traditional engineers who think that designing software is some menial task that any joe schmoe can do and shouldn't be in any way associated with "real" engineers, I might disagree with them, but they are the ones who often work with large heavy steel objects that hurt when applied cranially) MUST start at the top and work thier way down, otherwise they are not doing the job correctly.
Desired result dictates the implementation detail. The implementation detail should have as little bearing on the end result as possible.
Author's note by JamesHip, on 18-SEP-2007 07:44 ( IP: 146.171.254.65 , user id: 29914)
ReplyDeleteLet me guess, sleemanj. You're a Comp. Sci. grad, right?
This is interesting, because while I agree that the implementation detail should have as little bearing as possible on the end result, it seems from your comments that it does impact the design methodology. I hadn't realised before, but now I do:
Top Down requires use case scenarios, as per your explanation.
Bottom Up requires "black box" implementation. Let me explain. I built a relatively successful career as a system consultant by doing the following:
1. Interview the customer/user
2. Design the data model
3. Test the design by virtue of "what are the inputs and desired outputs"?
4. Code the black box in the middle that turn the inputs into the outputs.
This works for any database/business implementation. It wouldn't work for creation of games, frameworks, toolkits, etc.
Comment by sleemanj, on 19-SEP-2007 16:41 ( IP: 202.78.155.23 , user id: 27497)
ReplyDeleteYour guessing powers are indeed astute. I am a Canterbury Cosc grad from some years back.
I think you're wrong to say (or at least imply) that a top down approach doesn't use black boxes. It certainly does.
In fact, any time you see a black box it is by it's definition a top-down approach, you are at a high level, on top, you can see what goes in and what goes out, the rest is a blurry mass of black which isn't important and you hand wave it until later (or pass it to somebody else).
When it comes to designing that blurry blackness you are decending from the top to the next level, you determine that to implement this you will take that data, and through using some more, smaller black boxes in the middle, produce the data that goes out.
So you decend again, designing those smaller black boxes, and decending into thier black boxes etc until you have a complete top down design which you can descend into one black box at a time to see all the details.
You seem to assert that because you can/do design the data model at an early stage that you are using a bottom up approach. Again I would disagree with this, the data model is by definition actually at a high (near top) level in the hierachy in terms of the design process, even though it could be considered to be the foundation of everything.
The data model is defined to a very large degree by the functions that the end user requires - which we have determind right at the Level 0 of our top down approach.
That combined with experience allows a developer to put togethor the data model with a high degree of correctness far in advance of actually investigating the stack of black boxes.
Author's note by JamesHip, on 20-SEP-2007 13:49 ( IP: 146.171.254.65 , user id: 29914)
ReplyDeleteI'm getting an education here. Please indulge me a little further. What is the purpose of DLINQ?
From my "bottom-up" perspective, I have a Visual Designer that will create 4 CRUD procs for each of my tables. It will then create a strongly-typed dataset for me. I have a Business Layer that I can copy/paste to create System.ComponentModel.DataObject. And finally I have an ObjectDataSource that will allow me to declaratively use my data objects.
How does DLINQ improve my design process?
Comment by Richard Carson, on 29-NOV-2007 21:38 ( IP: 125.239.38.218 , user id: )
ReplyDeleteI've sat on most of the different sides of the fence in the VB/C/C++ discussion (and Java too, and a bunch of others, but not Perl or Php... I have higher standards than that ;-)
The thing that strikes me when writing software is that there is usually an easy way, and usually a hard way. And some people seem to without fail always end up doing things the hard way. (As Wesley Snipes would say, "there's always some [deleted] trying to ice skate uphill".)
And code that is written with the purpose of clearly expressing the intent tends to look the same in all the imperative languages.
So in the context of whether you start at the DB and work backwards, or start at the UI and work... forwards? sideways? I don't think it matters. By taking a 'holistic' approach to writing software, understanding the needs of the user, understanding where the different pieces of data are coming from, understanding how the different parts of the page work together, and understanding how the whole app fits together, then it becomes possible to see the parts of the application where we are trying to bang square pegs into round holes, and then we can consider fixing it at the design level.
Example: everything on a page comes from one of two main tables which have a simple relationship, except this one piece of data which is coming from half the database away and involves 15 nested joins to get. Something is clearly wrong here, and yet I've seen numerous examples where the developer would quite happily build the appalling (and buggy) monster of all SQL queries... and then wonder why their application performed badly and did strange things occasionally to their data.
It is actually something that puzzles me, because I've somehow always ended up with nice simple queries that are blazingly fast. I did an interview earlier in the week and they asked me how I ensured good performance, and I didn't know what to say. I knew that I was thinking something like "if you design it properly, you won't need to optimise it later", but I didn't know how to articulate that I can have both of those things you were talking about, nice SQL queries and _also_ a really nice Object Oriented design.
One of my other insights about the way that I code is that I tend to hit _everything_ liberally with the Divide and Conquer algorithm. E.g. break it down into smaller and smaller parts, stress test the smaller parts, build confidence that they do what I want them to (by torturing them till they confess their bugs), and then put things together and test the larger and larger chunks. Whereas commonly in the Java world the so called "unit testing" is just about testing the smallest chunks and never looking at the bigger picture, which I find extremely dodgy.
So I'm aiming for:
Readability
Correctness
Simplicity
And instead of this being a "pick any two", what I find is that this is a feedback cycle. If something is hard to read, it will be hard to debug, if it is not simple, then it is hard to verify its correctness etc.
And to my mind these factors encompass the vague concept that most programmers strive for which is "elegance".
I think different people express this in different ways. I know some for instance whose main criteria for elegance seems to be compactness (e.g. "can I do it in fewer keystrokes"), and then also complexity, that something which is not complicated cannot be elegant.
But I think this attraction towards a complex solution (and we are problem solvers, and these people can sometimes solve fantastically difficult problems, whereas sometimes I can come along and shortcut the process by figuring out that the problem being solved is the wrong problem, which leads to the much simpler solution) encourages these people to bang square pegs into round holes. After all, the mightier the battle, the better the bragging when we win?
cheers
Rick