Design your web application before developing


As a professional web application developer, we’ve to develop application faster with maintaining the quality, security and performance. Once upon a time, when people develop web application without further planning about structure and maintenance. Now the situation is quite different. Today’s web application are very complex. Now it’s very important to structure the application. Now I’m describing about a case study:

Case 1: Suppose you’re a team leader. Your company tell you to develop a facebook application with some requirements. You’ve a good team to develop this app. Now what will you do?

Solution: You may use a framework and guide your team to fulfill the company’s requirement to develop your application like this.

web application structure 1

web application structure 1

So, you maintain a good structure and develop a good application.

Case 2: After some days, your company tell you to develop another application that has the same functionality with this application only view and some minor features are changed.

Solution: You and your team copy APP 1‘s source code, modify that, maintain the core and change the view.  So You develop another application APP 2 that has it’s own core.

Case 3: Your company assign you to develop another 4 application like this.

Solution: You and your team develop those application like the same process. Now You’ve five applications like APP 1, APP 2, APP 3, APP 4, APP 5.

Case 4: After 2/3 months someone found some bugs in your APP 1 and notify you. Then what will you do?

Solution: You fixed the bugs for APP 1, and recursively apply the same process with other apps APP 2, APP 3 …..

Case 5: Suddenly facebook company announce to change their core library and deprecated some functions and updated some new APIs. Now what will you do?

Solution: You’ll identify the problems, replaced the core library for APP 1, integrated the new APIs by replacing the old APIs. And you recursively apply the same process with your other apps APP 2, APP 3 ….

So, I think now you realize the matter why I’m describing this situation. This type of situation sometimes happen in software firm. But If your team leader and senior developers plan and design before developing application, this type of recurrence situation might not happen.

For team leader and senior developers:

  1. Before developing any application, first time try to fully understand what is the future of this app. Would we need develop similar apps in future. Try to capture and visualize the full requirements from your company.
  2. Seniors and team leader have more responsibilities than junior developers. So, you should think and should chose a well known and best framework to give structure in your app.
  3. In professional life, developing from scratch is a very bad idea. Because you should consider security, maintainability, performance, structure and helpers. In student life or if you research then developing from scratch  is essential.
  4. Over confident is very crucial. Try to understand others. By consulting, you could choose the best solution. Value others if you want to be a valuable person.

Now, for Case 1 at the first time the best solution might be like this.

Solution: You consult with your company about the requirements and future of the new app. If your company tell you that in near future, you have to develop similar app, then you have to make another structure like this.

Web application structure 2

Web application structure 2

That’s to say, you defined the core library, helper functions, common functionalists and moved in a common directory. Then when any new and similar app need to develop, you just use the core or inherit the base. By this way, you solved several common problems.

  1. When core library changed, you update in one place. And all the applications become updated.
  2. When any bug identified in core, you changed in one place and all the applications become updated.
  3. You reduce the code.
  4. You give a maintainable and robust structure for these similar apps.

So we all should remember, “Design your web application before developing“.

mahmud ahsan

Computer programmer and hobbyist photographer from Bangladesh, lives in Malaysia. My [Business | Twitter | Linkedin | Instagram | Flickr | 500px]

You may also like

6 Comments

  • junal
    September 26, 2008 at 9:02 pm

    Mahmud, really a nice post. im sure you gave a good time creating this post. You are right we all should design the web app before developing. this is what we learned from SDLC eh? but you know what, sometimes its hard to design the whole thing at a time, cuz your company changing the requirement gradually, what you can do about it. So i better say, design such a way so that it doesn’t hamper the structure if there is change in the middle.i know company should be aware of this fact and they should give the full requirement at the beginning. another thing is, there shouldn’t be any Junior/Senior word in a team, and of course a dev who has better suggestion should participate on the design or any kind of decision, doesn’t matter whether he or she is junior or senior. again good post 🙂 and i will like to see a presentation on it, on our next tech session 🙂

  • mahmudahsan
    September 27, 2008 at 3:50 pm

    Thanks junal vai, for your comment.

  • Adam
    October 3, 2008 at 5:07 pm

    Ahsan, Nice post.
    I have some qualification in ICT and what you are describing here is known as the Systems Development Life Cycle or Software Development Life Cycle (SDLC).

    I agree that planning, requirements and design are required when developing products for 3rd party’s. I do slack off when coding small projects for myself.

    Great Post, Keep pushing those lazy developers
    Adam

  • nhm tanveer hossain khan (hasan)
    October 7, 2008 at 6:11 pm

    hi,
    wow, you have a wonderful blog world. i think your blog seems very interesting.

    well, good architecture is not possible to develop up front but it is possible to follow the path that may lead to the good architecture.

    as you have described on your above example, i think that could have been ignored very easily if you had experienced software engineer who follows standard software development practice. for example, you could have used abstract factory design pattern along the adapter pattern to hide all these implementation related fabrication. where your code were developed around the factory method.

    ie.
    instead of the above, you could have use the following code –

    so you see your code dependency is circulating through the a set of services (ie. FacebookService), which is will be presented on the top of your implementations

    this API (services) should be decided (obviously these things will be evolving when someone feels need of it) up front.

    [client code] —> [CommunityServiceFactory]
    / | \
    / | \
    [FacebookService] [Hi5Service] [NingService]

    i think you are aware of DRY (don’t repeat yourself). you can follow this policy strictly in your company.
    i think that will reduce most of your potential spaghetti code related problem.

    as i mentioned earlier you can’t come up with the best architecture from the very beginning but you can create the spike that may lead you towards the successful architecture.

    build open discussion environment with in the team, follow agile methodologies where you will take iterative development process. so you might get feeling where your architecture and software is moving ahead and you will have enough space to discuss with every team member.

    btw thanks.

  • Ahsan
    October 8, 2008 at 1:56 pm

    From my limited experience, sometimes it is not possible for the development team to fully understand the future of a code base. And as Hasan pointed out, the experience of the team (specially the lead dev) also has a big role to play here. Other than that, the product deadline plays an important part as well. But having said that, all software projects should strive for better code structure for re usability and maintenance.

    One crucial part you forgot to mention is that of “Refactoring”. Sometimes the projects are in such a tight schedule that it is not possible to make the code as much reusable as the team would have liked it to be (thx to their limited experience). But once the products are launched and the team is out of crunch time, it is possible to refactor the code to make it more reusable. But, I know, that will mean more work for the team, than if it was don’t earlier (when they might not have known that similar projects are coming). But in some situations that is ok, since the product is out in time, and the team has some time to spent in refactoring.

    So following your example, we can add two more cases:

    Case 6: Another similar App comes in, and this time the team has more time in hand

    Solution: the team decides to utilize the time, and refactor the code to use a single core.

    Case 7: The company decides to make another such family of products.

    Solution: the team learns from their last project experience, and makes the new product more mature

    But no matter what, every team should strive for code re usability, and as they get more experienced, the extend and design of their code should get more reusable and maintainable in nature.

    Thanks Mahmud for such a wonderful post. I am sure team leads and senior developers have lot to learn from this, if they haven’t learned yet 😉

  • Saifur
    October 19, 2008 at 7:28 am

    Certainly good post. But many developers in our country can think of a good design. Here are some so called renowned developers can’t even think of architectural design. They think of only visual design.

LEAVE A COMMENT