Design Dithering

When you break out of the “new programmer” mindset and begin thinking in terms of organisation, patterns, and good design, I think there’s a real danger of hitting a development wall. What actually is the correct way of implementing a shopping cart? Should you use a three or four tier application design? My outlook on this is pretty simple:

It doesn’t matter.

The Domain Driven Design book teaches a lot of interesting stuff, some of which can contribute to a brain freeze. So many new concepts can mean that there are a lot of possible avenues of approach for any given problem. But in my eyes, one of the most valuable lessons that Eric Evans gives in that book is that refactoring is key. If I find myself struggling to adapt the right approach, I take the simplest route, safe in the knowledge that if I’ve done it wrong, my application will let me know, big time. If I’m following a loosely coupled design, no single refactoring should have a huge impact on the rest of the application.

So if you find that you’re struggling for a solution, take the simplest, quickest – even do a dirty hack! – and know that next week, if that decision comes back to bite you, you can just refactor it out.

Related Articles:

    Post Footer automatically generated by Add Post Footer Plugin for wordpress.

    This entry was posted in practices pragmatism. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

    4 Responses to Design Dithering

    1. Excellent advice.

      Like the pragmatic guys say, KISS – “Keep it simple stupid”

    2. cramsay says:

      Totally. “Pragmatic” is the word which really encapsulates my post, because without pragmatism you’re not going to meet your deadlines.

    3. Evan says:

      I agree, and let me just add that there’s no such thing as “the correct way of implementing a shopping cart”.

      Know what your end user needs and don’t use tiering unless the project calls for it. Many shopping carts will live happily as an asp.net website and a database.

      If there’s no driving reason for it, don’t add complexity.

      Unless of course, you just have money and time to burn. Then by all means, go ahead. :-)

    4. Jeremy Wiebe says:

      Man, you hit the nail on the head. We’re just starting out a new project and that has to be one of the hardest parts of a project. What way do we access data? How do we do localization? An endless series of questions. Today we all agreed to do a _thin_ vertical slice in our application and try to pull patterns we like/want out of that slice. We know we’ll miss some cross-cutting concerns we’ll need, but we have to start somewhere and we figured that producing something in iteration 1 was better than a bunch of “architecture” that might miss the mark. Wish us luck. :-)