3

I have been going through various system design examples to understand how we approach any system design question. Here is what I have understood till now.

  1. Know the system first and find out how it works.
  2. Think of all use case.
  3. Identify key components and their responsibilities.
  4. Connect all the components so that they can communicate to each other.
  5. Use all standard practices while integrating components and if possible use standard design patterns.

Sometimes we make assumptions about the system, so those assumptions should be used to remove one use case or to add a variation.

I will put this question in context of Parking Lot design.

If I assume that Parking Lot is not commercial, and it is free parking lot, then design of parking lot should handle free parking lot as one of use cases , and it should be generic. OR Simply design parking lot which will never work for Commercial parking lot.

Main idea is that if someone asks you to design a parking lot and that is free parking lot, then design should be generic or specific?

  • 2
    ask whether the assumption is valid or should be rejected outright – ratchet freak Aug 14 '13 at 15:10
  • 4
    at the very least document your assumption if you are aware you are making one – jk. Aug 14 '13 at 15:20
  • 1
    @AKS that depends on the interviewer. Go too generic and you end up spending a lot of time (money) writing and maintaining stuff you won't need. Whether the interviewer knows this or not is another question. Also, consider that the question may be in there to see if you how to tell when you will need the more generic one and when you will want the more specific one – JohnL Aug 14 '13 at 15:50
  • 1
    @JohnL Got the idea!! learning new thing so getting lots of questions in mind. And there are not much resources on net specific system design, and even if they are, they are all different views on same system. Like if I talk about Parking Lot, there are different designs i can find. I think thats how it should be, System should execute same functionality, even if internally it has been designed differently. – AKS Aug 14 '13 at 16:01
  • 1
    @AKS there can be different designs, but at some point you have to pick one of those designs and run with it. Otherwise, you end up trying to develop all of them at once, which doesn't really work. – JohnL Aug 15 '13 at 11:07
6

Personally, I'm a big fan of YAGNI - (you ain't gonna need it).

Designing the general solution is hard.

The general rule I've seen (but naturally can't find a link to when I want it) is

  1. Write the first block of code to solve the problem.
  2. When you see a second instance of the problem, copy the first code & make changes to suit.
  3. When you see a third instance of the problem, refactor to a general solution.

You might find the story about the Object Toaster useful reading. It's a cautionary tale about the dangers of over thinking a problem.

  • 2
    Why do you say that designing the general solution is hard? I find that with experience it's no harder than the specific. Every time I attempt YAGNI, by that second iteration it has already cost me more time than it would have cost to just build it the way I thought it should have been the first time. So I've just gotten in the habit of building it that way up front. Maybe it wasn't needed 10% of the time, but it saved time the rest of the time, so it was more efficient. Possibly the instinct about what you're going to need varies among individual programmers? – Amy Blankenship Aug 15 '13 at 18:01
  • @AmyBlankenship designing tends to get harder the more general the solution becomes, but even a slightly-general solution to a very complex problem can be much more difficult to design than a more restrictive solution. – Mike Partridge Aug 15 '13 at 20:17
  • 1
    Hm, you didn't really back that up very well. My experience is that there's not that much difference, and that the more general solution is often easier. – Amy Blankenship Aug 15 '13 at 21:13
  • 1
    I'd say it depends primarily on two things: your skill/experience as a developer, and your knowledge of the domain. If you are a relatively skillful programmer and you have a complete understanding of the problem, then it is likely that a general solution will be easy to produce. I find that when my subject knowledge is insufficient, it is far easier to produce a specialized case and generalize from there. – AlexFoxGill Aug 16 '13 at 10:10
2

Assumptions are a fact of life in IT projects.

Requirements change, and no matter how often we wish they would be locked down, they often are not.

So you need to deal with your assumptions and keep an eye on them.

Maybe keeping an issues log or something similar. Marking items with statuses levels to indicate how big an issue they could become etc.

With your parking lot example, you could assign a time estimate to each "level" of design and have an assumption in your issue log that talks about the assumption you have made, and what the cost would be of doing it one way or the other.

  • 1
    I also believe in "Walking on water and developing software from requirement spec, both are easy, provided they are frozen" – AKS Aug 14 '13 at 15:31
1

Rule #1: Never make assumptions, develop a bare minimum
Rule #2: You Aren't Gonna Need It: http://en.wikipedia.org/wiki/You_aren't_gonna_need_it
Rule #3: Start by writing unit tests

  • 3
    Rule 1 can not be met, you always make an assumption somewhere – jk. Aug 14 '13 at 15:19
  • Why not? That's why we have project requirements. If you start assuming something, it can cost you a lot of time and money. Developing a bare minimum doesn't cost you anything. – šljaker Aug 14 '13 at 15:27
  • In the company I work for, we charge our clients 150 - 250 EUR per hour. Assuming that some feature might be needed, and then spending X hours on actual development can be quite pricey. – šljaker Aug 14 '13 at 15:33
  • 3
    YAGNI is in itself an assumption. You mitigate its risk by identifying it and preparing for it (Rule 3 + SOLID). Other assumptions shout be treated similarly. – Dan Lyons Aug 15 '13 at 18:25
  • My father used to say, "Don't think, know!" He also used to confront my unconscious assumptions by saying, "If you didn't know, why didn't you ask?" – user251748 Oct 5 '17 at 18:01
0

It's always a good idea to instrument systems and have a communication path back to the developer with the results of the instrumentation. (I'm not talking about spyware; a log file or a "stats" screen will do).

Part of good instrumentation is providing data relevant to the assumptions. Ie; a parking lot app should report the number of cars it's supposed to handle, and maybe add a special warning flag if it's suppose to handle a million cars...

  • A pay parking lot near me has a glowing "FULL" sign which is, strangely enough, illuminated all weekend while the gates are open and there is no charge. I wonder what assumption was made there? – user251748 Oct 5 '17 at 18:04
0

Main idea is that if someone asks you to design a parking lot and that is free parking lot, then design should be generic or specific?

Avoid a specific design as much as possible, as you would need to modify it once requirements clarify or change.

Eliminate your assumptions by clarifying requirements and minimizing/simplifying the scope of work. Usually, over-architectural design introduces unnecessary complexity to the project.

The rule of thumb while designing a software, with pre-mature requirements and assumptions, is to keep it simple. There are number of posts on this topic that combined in a famous phrase YAGNI!

In another words, best design patterns to stick with are KISS and YAGNI !

  • YAGNI - You aren't gonna need it
  • KISS - Keep it simple stupid
  • Did you mean to say avoid a specific design? The generic design, by definition, offers the flexibility to change later without so much pain. – Amy Blankenship Aug 15 '13 at 18:03
  • Many times I have created a generic solution for a problem space much faster and easier than I could have coded a very specific design. The hard part is if I have to justify my design beforehand, because people are so afraid of "silver bullets". It is hard to convince people that vampires do not exist. So I try to say as little as possible, have a fallback plan in case my optimistic approach doesn't work in time, and wait to explain how I pulled it off until after it is complete. Usually, no one really cares about my gee-whiz generic solution anyway, so it is Business As Usual. – user251748 Oct 5 '17 at 18:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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