I've started reading a book from Head First series about OOP and Design. In a first chapter it is stated I have to worry about design of my application just after basic functionality is ready.

Basic functionality is ready means you have something to show to your customer or boss.

Do you think this is a correct approach? Shouldn't I think about design from the beginning? Can't it happen I won't have time for making a good design after functionality is ready because I will have new high priority requirements to implement?

By 'design' I mean Object Oriented design, not GUI or something.

  • 2
    Can you please elaborate on what you mean by functionality? I want to believe that you mean functional requirements, but I am not sure that is true based on how you worded the question. – Pemdas Jan 24 '11 at 16:15
  • The answer would depend on whether you&co subscribe to a scrum, waterfall, or other religion.In general, I am a big fan of running toward a fugly but functional prototype ASAP - you never know if the client will actually pay XYZ dollars, and you would never know how long/much it would cost you before you flush out 80% of the issues that you did not think of at the start by building a prototype. So, neither top-down or bottom-up is THE WAY. You need to find a en.wikipedia.org/wiki/Golden_mean_(philosophy). – Job Jan 24 '11 at 17:09
  • (flagged so the mods can merge with the question here; no need to close as dupe) – Ripped Off Jan 24 '11 at 19:18
  • @Will - Done... – Walter Jan 24 '11 at 19:50
  • What if you show your basic functionality to customer/boss after elaborate design, and it turns out you misunderstood something slight, but with great consequence to your extensive design? – OJFord Aug 20 '14 at 14:31

10 Answers 10



Design can come later, core functionality is key to a deliverable product.

Disregarding design, the key is to get a deliverable functioning product out the door sooner rather then later. Design is a secondary objective. If you can't make it work, then all the flowers and pretty colors won't save you. Having a working product, with minimal design work will.

Perfectly adhering to a pattern or OOP principals are great, but often you will find that for the sake of producing something that works they will have to be ignored in some cases.

|improve this answer|||||
  • He's talking about design in the application architecture sense, not the GUI bells and whistles. – Adam Lear Jan 24 '11 at 20:10
  • @Anna: So was I, just taking a more liberal use of words. If all your objects perfectly align with OOP it's great. If it doesn't work it's not worth anything. – Josh K Jan 24 '11 at 20:11
  • Yeah, I thought that's what you meant until I got to the "pretty colors". :) Thanks for the clarification. – Adam Lear Jan 24 '11 at 20:12
  • @Anna: Needed some edits anyways. :) – Josh K Jan 24 '11 at 20:13

It is not uncommon (and in some ways is recommended) for application design to evolve over time. It is very difficult to guess up front what exact things you're going to need in the end, so it's best to start small and build up over time. Your features will guide your design.

There are also techniques like test-driven development that will help flesh the overall architecture and design out.

You shouldn't ignore design up front, but be mindful of not trying to engineer the whole thing right away. As you gain experience, you will get better at picking the "right" design sooner.

|improve this answer|||||

The bottom line is that you have to have a basic functional specification before you can design anything. You could think of design first, but what would that mean? What are you designing? Suppose you have a web application that allows users to manage their bank accounts. Obviously, you need some sort of database to accomplish to this. You probably also need some sort of secure authentication mechanism. These are basic functional requirements that need to be in place before you can even have a discussion about design. Other things like how the page is laid out or what functions the user has the ability to execute are largely mute points in terms of the overall architecture of the system.

I would say that you should always have some sort of design consideration in the back of your mind, but you need to know what are you making in order to really make any significant design decisions.

|improve this answer|||||

Design requirements directly follow from functionality requirements. In order to determine how a program's components/classes will be organized, you need to know what the overall functionality of the program is and what features it will have. Once you have this down, you can decide what design is best for implementing that functionality.

It may be the case that you make a design, and then upon determining functionality you have to redo your design, which is extra unnecessary work.

On the other hand, it is useful to think about what kind of design might be best and definitely jot some ideas down, but I would put off any implementation until you know for sure what the best way to go about implementation is.

|improve this answer|||||

It might be a bit of a chicken/egg problem, but if you have NO functionality, you cannot design anything: you do not know what you want to do, why, where, how, etc.

So the first start should always be functionality. You cannot start with "hmm, it will be blue", and then think. Ok, what would my blue code do?.

You would start with "I'm building a concept that would save a users dvd collection for easy finding". Then you might start thinking about some design before you specify if it's necessary to save the barcode of your dvd's. But that tiny bit of functionality will be first.

|improve this answer|||||
  • +1 basic functionality tells you what your app should do. Without this you can't design. – Qwerky Jan 24 '11 at 11:54
  • It's also at this stage that new projects become paralyzed by over thought and too much talk. I particulary like Vincent's answer, though Ive never seen the idea put more stylishly than here: boingboing.net/features/morerock.html – Danny Thomas Jan 24 '11 at 11:59

You should be thinking about design from the beginning. This is especially true of your use of data structures and your overall application architecture.

However, it is extremely useful, in an agile context, to do functional prototypes and get feedback from the customer as you develop them. This insures that you and the customer are aligned in your objectives, and gives you some hands-on activity to assist the design process.

|improve this answer|||||

It is probably describing an agile approach to software development. You only do as much analysis and design as necessary then write code to create a system that can actually run. Based on that you get further requirements, design, refactor and add more functionality.

At each step the system is in a working state and it is slightly more advanced.

|improve this answer|||||

Usually, when it comes to functionality specification there are two scenarios:

  1. You specify the full functionality before starting the implementation. This means you will design after specifying;
  2. You define a high level specification, which evolves during the project. This way, you define a high level design before starting and then refine the design during the project.

There's a third scenario, which involves requirements magically popping up during the project, but let's not get into that :-)

So, the common theme here is that yes, you do specify before designing, even if it's a high level specification. Designing before specifying functionality is dangerous, as you risk coming up with a design that doesn't accurately model the problem you want to solve (or even worse, over-design and use a cannon to swat a fly).

|improve this answer|||||

You need to find what will work for you in your environment. I suggest you start with some prototype which you may have to re-write, then design the system and implement that. Repeat as often as needed.

|improve this answer|||||

The act of programming is the act of design. If you have written any code, your program already has a design. In fact, the code IS the design. As soon as you understand this, then you will understand why the question is strange.

In other words, if you already have functionality, then you already have a design.

|improve this answer|||||

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