Good From The Beginning

Arrows Up
 

How often did you face a situation when some temporary (and usually quite mediocre) solution became the most used feature? How many projects stuck on the proof-of-concept stage and can not advance because of internal issues? The main reason why it happened is that things were not done correctly from the very beginning. It is what we are going to discuss in this article using a software application project as a test subject.

Brand New Project

Blank Notebook

The new project is nice and easy to work with. You do not have to worry about the existing customers or use cases, and you can start everything from scratch. There are several recommendations for the new projects to maintain them in a proper state for a long time.

New projects are often started with a prototype to make sure that everything works as expected. There is nothing wrong with the prototype itself. However, everyone should know that this is a prototype and not an expected solution. You should clearly understand when and how to convert it to a proper solution (or rewrite it from scratch).

When the project is new, it is very flexible — it is easy to improve architecture, add configuration options, and change overall behavior. Please make sure that none of the new features block possible extension points. To do that, you should think ahead and imagine potential future scenarios that customers may request. Knowing these scenarios, you should adjust the architecture and configuration to support them in the future.

Iteration Over Iteration

Apple With Hypodermic Needles

Almost every project development is iterative. Each iteration brings new configuration options, new features, and new possibilities for the future. However, all existing features have to work precisely they worked before, and new features must not break them.

These requirements make project support complicated because every time somebody introduces new features, you have to check all related features. Most companies use automated tests to make sure that the application is fully functional after such changes.

Another tricky part here is maintaining an appropriate level of flexibility as every new change or feature brings new restrictions. Application architecture has to not only accommodate them but also support possible future scenarios that customers may need. So, the project manager and the architect have to think ahead about these scenarios to maintain the required level of flexibility and do not stuck because of architectural or functional limitations.

Maintaining Quality

Buildings

Maintaining quality becomes harder with each iteration. The application has more features to support, more use cases to check, and more customer requests. You need to handle all these items to maintain the application in a good state.

Another related issue is maintaining flexibility. Each new feature slightly decreases the level of flexibility and adds new scenarios to maintain. That is why it is crucial to understand customers' needs and plan to refactor features in advance to keep the required level of flexibility.

There is a recommendation to deprecate and remove features nobody uses. This way, you can decrease the list of supported cases, simplify scenarios, and make your file easier. It also may free time to work on other more critical activities.

As we can see, control is essential on every iteration, and there is no way to keep the application functional and flexible without it. It is not an easy task, but it has to be done. Everybody knows that it is impossible to achieve perfection, but you have to raise the quality level to have a useful application and satisfy your customers.