How Far Do You Go Architecturing Your App?

I've noticed a few things on starting up a project or creating a product that is based on community customers (meaning not the private customers that you design custom projects with).

We as developers and designers, always try to make perfection out of our designs. Develoeprs spent a lot of times make it object oriented, resuable and designers want to design the css so flexibile that it can accomdates all the possiblities of changes.

My question here is how long and how far do you go? Can these actions be justified against time and investment that you spend on it?

The reason I'm asking this is because I've noticed on brand new projects or products, in v.1.0, we spent so much time discussing on the possibilities of the features we will do, the potential features we might do and guessing on what features the customers might like, such we try to make the product so "resuable" to the point that a simple project turned into this gigantic hurdle and the terrible reality is? These supposely "resuable" scenarios, people rarely touch them due to its complexity or it's just too much hassel to touch them.   Have you noticed these two most important issues:

• Are we doing it because it's NEEDED or because we can?
• How likely will your "resuable componets" be "resued"?

My point is, in v1.0, it's very likely that you DON'T know what your customers want and therefore, you can't be sure if in fact, it will be re-used again. Spending a ton of time on aritechuring the things that customer might not want to even touch(even if you can  it's possible), the time and money you invest into doing this does not justify such actions. In addition, you are risking two more issues

• Market Time
• Moral

By over complicated your project when it's not needed, not only you risk delaying your product launch date, risking your profit and more importantly, you risk loosing morals among your team.  By extending your project for too long, your team will loose steam, feel bored and the uncertainty and self-doubt would increase, what's worse is that everything is based on assumptions because with no customers, there is no justification and confirmation of your actions.

I've seen so many projects started out in v1.0 with all these fancy architectures which supposely will accomdate and reduce the time of upgrading the software later, only to find out in v2.0 or 3.0, they have to start up from scratch completely to accomdate the feedbacks from customers during the previous version. 

So my thoughts is that when you start a brand new project, you should targe these goals instead

• Design the features that are attractive enough to build customer interest.  
• Make objects reusable for the features IN current version
• Deliver the product v1.0 fast and on time.
• Last and formost, collect customer requirments in v1.0

Once your product is out of the door, the features satisfy the current version requirement. Only then, should you start worry about make the product truely object orietned and re-usable by hearing from the customers on what they want and the differnt kinds of business scenarios that your customers are facing. 

The honest truth is that you would never be able to imagine the things that your customers might request and you will always get those good feedbacks from your customers that you never thought of. By guessing, imagining and try to architect for all the possiblities of business scenarios is NOT something that you should do in v1.0. If you are doing this right now, then it's time to think twice about what you are doing.

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS