Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm developing kind of a modern web application - scalable, robust and fast.

I need to develop it as fast as I can.

How much should I worry about the analysis phase or writing UML diagrams or ER diagrams for it? And what should be the flow on that? What should I start drawing?

share|improve this question
How large is the application? – MainMa Jun 1 '12 at 12:40
I think this question is too general to be answered in a clear manner. Without knowing more about what the application is or the requirements, we can't advise you on anything. – Stephen Orr Jun 1 '12 at 12:40
@StephenOrr Well that's the good think about conceptual discussions. We don't need to specify the stuff to talk about it. It's supposed to be a general question. – Daniel Ribeiro Jun 1 '12 at 12:47
There is the age old triangle of "Cost, Speed, and Performance" You can only pick 2. You have to decide if you want to do it right and slow or fast and sloppy. If you do not go through the entire process, or have a process, you won't do it right. This is not to say you cannot do it right and still complete it on time, just perhaps, slower then if you skipped the part of the process. – Ramhound Jun 1 '12 at 13:24
@DanielRibeiro In that case, it still depends on the scope of the project. If you just want to get something out there to see if your idea has wings, by all means do it fast (but accept that you will have to go back and change it later). Look into Minimum Viable Product. If you had more time, perhaps you'd do the full-on analysis stuff. – Stephen Orr Jun 6 '12 at 7:57

13 Answers 13

If you're under heavy time limitations then, first of all, build something that works. Draw anything you need to make a working system and ship something the client can use. Then, if needed, you can focus on improvements, optimization and polishing.

share|improve this answer
The thing is: if I focus on building something that works fast, I will most likely have to rewrite most of the software because bad or not at all design. Am I right? – Daniel Ribeiro Jun 11 '12 at 21:21
@Daniel Ribeiro - who cares if you have to rewrite it, you probably will anyhow.. you first need to finish it so you can start making money – hanzolo Jun 11 '12 at 22:15
The problem is, once it is working and bringing in money, the non-technical decision makers don't see need to rewrite crappy quick 'n' dirty code. "Why do you need to do that? It's working, isn't it? Just add more features! The users don't see your code anyway so who cares!" – Kristof Claes Jun 13 '12 at 10:05
The thing is, with this application, I am the decision maker. Is that a bad thing? – Daniel Ribeiro Jun 13 '12 at 11:56
As the decision maker you will need to decide cost/benefit of either maintaining a product that lacked a clear design or expending the time/money/effort to rewrite it. I think a lot of good points have been raised and you really gave very little information to base comments/answers on, it really is up to you. Only you know the circumstances around your situation. – Larry Hector Jun 18 '12 at 16:30

If time is an important constraint, if I were you, I would rather search for an alternative which requires less or no development.

For example, if you are asked by a customer to build an ordinary website which has nothing extra special, and do it in a week, while in better circumstances, you need at least three weeks, then what about the services like SquareSpace?

If it is not a solution and you still need to write code, try spending less time doing "other things", in particular by reusing things you've or somebody else have already done:

  • Use frameworks. For example in .NET, don't write your own database queries, but let Entity Framework or NHibernate do the job. Another example: in PHP, don't reinvent MVC pattern every time: there are plenty of frameworks that will do lots of work for you.

  • Reuse what you've already done. It also means that if you have a lot of similar projects to do quickly, spend a lot of time doing the common trunk.

  • Pick the fastest customer relations technique. If you know that if you stay agile, the customer will disturb you a lot during the development process, gather the requirements, then keep everything secret during development, and only then show the result to the customer.

  • Use project management techniques which help you to finish the development faster. For example, enforce the zero bugs policy (see point 5 of Joel test), since the later you fix the bug, the longer it will take to fix it later.

If you still don't have time to do the analysis phase, think if you need it:

  • If you're creating a quick and dirty prototype, chances are that you don't need analysis at all, since in all cases, you will throw away the source code later.

  • If you're about to build a large scale website which will be maintained by other people for at least five years, spend time doing things in a clean way, even if the original delivery will be delayed: it's better to be late the first time than to have to rewrite everything from scratch two years later, after wasting hundreds of thousands of dollars on maintenance.

share|improve this answer

How much should I worry about the analysis phase or writing UML diagrams or ER diagrams for it? And what should be the flow on that? What should I start drawing?

Analysis of requirements is very important to get acceptance of the final product. Not understanding requirements or understanding vague requirements does not lead to faster applications. Instead, this generally leads to delivering the wrong product fast. Look at this inequality:

Cost(Analysis + Implementation + Testing) ? Cost(Analysis + Implementation + Testing) + Cost(Analysis + Implementation + Testing) +...

I argue that the "?" is "<". Even if you replace the Cost with "Quality" or "Customer Confidence". This is based on my own experience.

Some people understand iterative development as deliver something and fix it later, but this does not work well in general. This is especially true with the complex software engineering cycle that today's software has to go through.

The idea behind UML and ER diagrams in general are mainly:

1-To make you think deeply about the problem without too much syntax, code, etc.

2-To make you document what you think precisely.

3-To make others understand precisely what you think, so that knowledge is shared.

4-To produce code when possible from the diagrams.

5-Get/Give a feel of the application complexity, so that project/cycle planning can be accurate.

If you have not practiced use case diagrams, class diagrams, ER diagrams, etc. you will be surprised how many questions will arise when you try to model. Some of these questions should be answered by the customers or the users of the application and if you don't ask those there is a good chance that you will deliver less than a perfect product. The other set of questions will turn into design decisions that you will make in a code-less environment.

One of the classical funny, yet close to reality, diagrams that shows the value of requirements is here.

In summary, diagrams (and requirements specifications in general) are not just pretty pictures and in most cases, they are not a waste of time. In most cases, customers may not think high of you if you deliver the wrong product. If your application is not trivial, consider modeling as a serious activity.

As for the 2nd part of your question, the order of producing diagrams depends on whether you are going to use Pure OO approach or Mixed OO and Relational approach where a class represents a physical table. In a design leaning towards an OO approach a Class diagram is required. In the later case, you can build an ER diagram, and depending on your toolset, derive the Class Diagram from the database and possible generate the ORM code.

share|improve this answer
I have observed something that may be an anomaly just for me, but I've found that you can build in an expectation of bugs in the context of the understanding that it's the trade-off for not having to allocate additional resources for testing. The user base effectively becomes your testing resource. Also, on the topic of delivering the wrong product - I have observed that quickly delivering a half right product can yield a very precise definition of that the other half needs to be in an efficient manner. – Aaron Anodide Jun 1 '12 at 19:22
As for 1st point, the user community of the app. may vary. In most businesses, users are employees tasked with delivering work that's expected to take 100% of their time. If you sit with 2 accountants that bill their customer $80/hr 3 hours then the business is loosing $6*80 for this meeting. As for the 2nd point, one must always draw the line between missing features and wrong implementation. Prototyping amongst other tools, should close the gap without any or too much coding. – NoChance Jun 1 '12 at 20:53
Yeah, now that I think of it I'm kind of tricking them into participating in prototyping. – Aaron Anodide Jun 1 '12 at 21:01

It depends on the scale of the system, the size of the development team, and the revenue / resource ratio. You state that it needs to be scalable, robust, and fast. Those are 3 features that benefit from a bit of planning. Does that mean that you need UML and ER diagrams? Not necessarily, but if you need to communicate to a development team or need a record of decisions for your client they can be useful tools.

The question I often ask myself is, if you don't have time to do it right... do you have time to do it twice?

Sometimes simple and quick are better if it the purpose doesn't justify a more elaborate approach. But, if you haven't decomposed the problem well you may run into issues with performance or robustness. As you try to add features it may require a lot of refactoring which can cost time and if not supported by tests could lead to regression defects.

How much is poor design or lack of design altogether going to cost you over time as you try to maintain and extend it?

If at all possible, I would use an iterative approach releasing new functionality in a series of limited scope releases. Avoid unnecessary features in early releases and maximize the return on investment by delivering the most critical features first.

Leverage well tested frameworks and component libraries where you can to avoid reinventing the wheel.

UPDATED - per OP comment feedback elsewhere Only you know the circumstances around your situation. Is there a significant potential for legal implications if there are design or implementation problems? Will mistakes or design problems directly cost you money. (ie. is it a sales or investment tool) Will you experience indirect financial consequences (ie. will paying customers turn elsewhere or will opportunities be missed by downtime?)

Design as much as you need to be comfortable with your choices. Document that design only as much as you need to know what you are doing. The complexity of the system and your ability to visualized the solution are your limiting factors.

share|improve this answer

A couple of recent examples in my life:

  1. We homeschool the kids. First year of homeschooling, and the log/portfolio process was being done on paper -- bad. I spent 3 days whipping together a activity tracking web application, and at the end of the school year, another 2 days on the WYSIWYG layout program and .PDF rendering software. I was ultra-focused on getting something working, so I did not do anything but think of end result, write UI's, and make them work.

  2. A client with a tight budget needed a comprehensive web app. So I proposed that they allocate $1000 for me to work on the UI. So with record-setting speed, I spent 10 hours burning through dozens of UI pages with no focus on graphics, etc... Then a 6 more hours spent (by someone else) polishing my work, and had a complete application mocked up. The client can see the requirements are met, and provide comments accordingly, all for 2 days of work.

Your answer depends on if you actually know the requirements by heart or not. But in any event, I suggest you start with the UI (valid HTML+CSS), and go from there. Don't waste time on abstract design if you don't have to.

If it is a bigger project, then you need to document a lot up front, and think it through, because that will save you time.

share|improve this answer

As i said in a comment.. Dont worry about any of that. Even if you have created the best application in the world that does not guarantee its success... first, you need to put your time into developing your application, and then you need to finish it, hopefully with quantifiable and thorough tests. Whether you use a test framework or not doesnt really matter.. you need to get your product out there in a PROOF OF CONCEPT sort of fasion.

No matter how much time you put into it making it's foundation "solid", you're probably going to have to rewrite it anyhow.. in fact, if you need to rewrite it later on than that would imply that you successfully proved that you have a working and successful platform (if you write it and it doesnt work, that's a problem)..

so finish the product, get it out there and cross your fingers that it takes off.. there's a lot of great music out there that never was heard.. and there's a lot of great products that we dont know about..

so again.. build it fast and cross your fingers..

share|improve this answer

Draw the base design of your application. Next jot down all the things that you are going to put into your application.Forget about he UML's,ERD's if you are going to work alone that can be done at spare time. But important is Data Flow diagram (you need to make sure how the data flow is going to be).

Database design is going to change if you want to make it scalable,so just develop a basic working model.Don't bother much about the UI since your additional functionality will definitely going to change it.

Please do not change your mind on things that you have planned. Most of the time is lost when you start to realize that What if I do it this way. Once you are done get feedback from your client(users). Enhance your project with whatever needful. No matter how much you think your project is the best ultimately its up to the client(user) to decide it.

share|improve this answer

This is all a bit abstract because I don't know anything other of your requirements than scalable, robust and fast.

That said, I think you should take the time to identify potential performance bottlenecks and design intricacies that don't fall into the typical patterns.

An example of this would be if you think you need to perform some real time operation, do some quick figuring about the request rate you need to accomodate now and where it would likely go in the near future.

This might help you avoid needing to do a complete re-write for a relatively low up front investment.

share|improve this answer

I would not make diagrams for the upper layers of the application (views, controllers) since their are probably going to change a lot, especially in the initial, prototyping phase. Furthermore, there are dozens of frameworks for different programming languages that allow to implement these layers in a structured way.

On the other hand, in order to have a solid foundation for your application, I would advise you to at least sketch a class model or an ER model of the business domain and produce a database schema based on it.

IMO having a pretty clear understanding of the structure and operations of your application domain can make your whole development a lot more robust.

share|improve this answer

I think one important question is how fast is your application going to grow. If the application is going to grow slowly, I think you can spend some time thinking about future plans for scalability. If you expect that your scale will dramatically change (at least in theory), then you should carefully think about what would be the next steps require to scale the application.

Take into account that my advise is more focused on having kind of a contingency plan than actually implementing it. As others said, before spending time on scalability issues at full detail, you should have a minimum product for your clients. Also take into account, that the expected scale determines the possible steps. Some solution may be optimal for small-medium size application and may be impractical for large scale.

share|improve this answer

When I'm tackling these sorts of things, I tend to start from the User's perspective. What does the user want to do and how is the best way to let them do it. You will hear a lot of people say stick to the MVC paradigm, that's because it has been proven time and time again to be easier to maintain. Try fixing an issue where the same functionality is in dozens of files...

Getting back to the point though:

How much should I worry about the analysis phase or writing UML diagrams or ER diagrams for it? And what should be the flow on that? What should I start drawing?

You should probably start drawing the user journey. This will tell you what pages are useful and perhaps where you make things easier for the user with simple tricks such as shortcuts. From this you should be able to ascertain the entities you need and persistence between pages versus any tasks that could be asynchronous (which will help with scalability).

Once you have the entities you can start programming. Hopefully, by this point you have a model that can be implemented incrementally in an agile manner. For (a very simple) example, Users, Blogs, Employment Positions, Companies. You can see that you must have a User before you can have User's blogs, employment positions etc. Then referring back to your user journeys, you can see that the most common task (and hence the first task) should be to create Users, then add Blog posts. Then you can add Companies and finally Employment positions to link them.

One last advantage to this approach is that your logic should be in small chunks (as you add it incrementally), aiding maintenance.

share|improve this answer

Spend your time on the thing that will contribute the most to your project's success and continuation. You already have a lot of conflicting goals: scalable vs robust, fast development vs robust, fast development vs high performance.

If you're developing this for a prepaying customer who is driving requirements, then keep them happy because nothing matters if the client stops funding your project or won't buy it at the end. I would use prototypes to get requirements and workflow nailed down before you really start doing anything. Those prototypes don't have to be robust or scalable, just demonstrations. Be sure to manage customer expectations while doing so.

Also, how many people are going to use your site? If it is unreasonable for joe public to use this tool and workload for the problem isn't tremendous, then scalability doesn't matter.

If you're developing this as a startup, then focus on what your application does and who your customers are. Something that isn't wanted will not get popular enough for scalability to matter either.

share|improve this answer

As per my understanding you are going through the initial level of designing and according to me this is the right time to govern your application's performance it doesn't matter which language you are going to use but you have to analyze lots of key things right now. As you said you want your application Scalable, Robust and Fast... that simply means that you need a very strong Design Pattern and i will rec-amend you to use MVC(Model View Controller) Design Pattern because as per me this Design Pattern will make your application Most Scalable and Robustness... This Model will let you segregate your Different layers from each other and easy to Handle them.. like Presentation Layer(for forms,VOs,Actions, requests), Service Layer, DAO Layer etc.. As we are talking about Web Application So, You must have a perfect arcitecture + Development Skills because when we are talking about web apps then look and fields like JSP or HTML or CSS can be modified very easily or I can Say Presentation can be Modified, Enhanced or Enriched easily but the most important thing is its Business Layer or View which is going to handle each and every request and may access Database as well requirement so Your Business Layer is the Key Layer which will enhance you application's execution time in simple words the difference between the request time and response time is completely dependent on how efficiently you have designed its Handler or Business Logic. So, deeply analyze the workflow of you web application and plan accordingly because this is the right time... and avoid using heavy or bulky images because they exhibits some delay during low bandwidth or network conjunction....


Few Reference Links are as.. 1) FOR more about DESIGN PATTERNS :

2) FOR more about MVC :

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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