1. 5
  1. 2

    It’s fairly lengthy, but this quote is the gist that’s important in my mind.

    When I start a new application or feature, I always start with the database design. This gives me a solid base on which to build my mental model and my ColdFusion code. I then work up the stack, creating larger “building blocks” that can be used to perform larger operations. As I build out these operations, though, I will often have to work back down the stack adding new capabilities. This in turn allows me to work back up the stack, fleshing out business logic.

    I mostly agree but have found better success with my team of developers when we build the database schema and mock the UI then connect them. The process he describes is still important (up-and-down the stack). But keeping them separate as long as possible allows the best data model and the best UI. Once they are connected it becomes difficult to make changes, so I try to put that off as long as possible. There’s also an element of “unfinished” that’s easier to communicate to the customer when you show them a mockup vs a partially working prototype.

    1. 1

      How hard does connecting the two end up being, once you finally do it?

      1. 3

        Good question. What I’ve found is that the difficulty of hooking the two sides up seems to be representative of how well each side was designed and an understanding of the overall architecture. When it is difficult, it almost always reveals a problem that would have needed to be solved anyhow.

        For example, in our last big project, one group designed the data model based on our understanding of the data, while another team did the UI. We discussed overviews of both and they looked good. Immediately, when trying to connect them, we found a problem that I’ll try to simplify by saying the data model had A->B->C but the UI showed the relationship was more like A->B, A->C, B<->C.

        Customer examples supported the data model view but actually thinking through how the user will use the UI exposed the proper usage. Trying to do bottom-up would have committed us to the data model too soon and would have caused big changes later, even though all customer examples supported it. You could argue that top-down would have been fine in this situation but in many cases that causes a shallow, poorly designed data model.

        1. 1

          And, because the data model wasn’t tied to the UI yet, it made making the changes need for the relationship easier than if it had been, I take it.

          That’s a really interesting approach to it all, thanks for sharing it!