Obvious things we did not do while developing our app

We started working on our product like we had all the other times, list down the features and start implementing them. No standards, no mockups, just hacking our way through it. And as the application progressed, we started to realise the practical importance of the theories we learnt about software planning and engineering. Following are some of the important lessons we learnt during our process of development.

1. Do it well or don’t do it

If you are planning to release any product, do not focus on the number of features you can implement but rather the quality of those features. It is better to have a single feature implemented perfectly rather than many improperly implemented features. We also started with implementing more than 10 features that were whole systems in themselves. As we progressed, we realised how naive that decision was and how important it is to make a minimum lovable product.

What we did: We cut down the huge list of features down to our core beliefs, promoting the creativity of the students. We kept the other half implemented features and ideas on hold so that we can focus on the core and make it perfect.

2. Don’t expand your team unless you have a good code base

As we got new developers on board with us, most of them new to the framework, the already not so good state of our code base worsened. Since the new guys were using the existing code as a reference, the rate of worsening became exponential. Some of the bad practices, like using inline CSS attributes, were being used repeatedly throughout the system.

3. Choose a mature framework with long term support

A very major problem was that we picked an immature (and now deprecated) framework — angular material. This resulted in the framework being more of a hurdle than a help. Some functionalities, like ‘md-autocomplete’, weren’t completely implemented. Also, elements like typographies were completely edited wherever they were used. We should have gone for something stable and with promised long term support. (A good metric can be the number of stars on the GitHub repo).

What we did: We didn’t want to change the whole system at a stage when we are almost ready to launch. What we did instead was reduce the dependency on angular material at all places possible. With this, porting to any new technology would be much easier.

4. Keep the code readable

The whole software system should be easy for anyone to understand. There are some good practices that help make the development lifecycle easier. Fundamental practices like using standard variables, commenting etc could have saved a lot of our time. We had big chunks of complex functions, manual tweakings and CSS that were implemented without any explanation.

What we did: We followed some very fundamental good practices for software development.

a) Made the code base simple by removing excess hierarchies of elements and excessive unused Javascript code. It made the code base smaller and easier for new people to grasp.

b) Made standard variables (using the almighty SASS) for spacings, fonts and colours. Any usage has to be done by referencing the variables.

c) Divided the code from the single CSS file according to functionality. (The naming structure has a ‘_’ prefix to give priority during compilation and to prevent from generating the CSS file for the same. For a more detailed explanation, refer here.)

5. Use a logical directory structure

A logical directory tree is very helpful when you are developing or debugging. It helps the developer to locate and edit the file quicker. There are many ways you can structure your directory tree. Like sorting by type of file or sorting by functionality. In our case, we mixed up multiple methods for managing the directories and made an unintelligible mess as a result.

What we did: We restructured the directory tree, using file type as primary segregation and functionality afterwards. For a more detailed explanation, refer here.

6. Don’t build with powerful devices in mind

Not every user is going to have a heavy duty device that can handle the load of complex processing. We have to aim for a smooth experience for everyone and for that we have to develop for the slowest device. In some places, in order for an easier and quicker implementation, we wrote code that required too much processing. For instance, we had too many hierarchical DIVs made hastily that hampered the loading performance of the application. Also, try to shift the load of data processing from client side to server side. The front end should only get data that can be plugged to the views required. Nothing else.

What we did:

a) Removed redundant code from the DOM and simplified the hierarchy of the structure.

b) We shifted the data processing logic to the backend so that the data can be served faster and in a directly displayable format.

7. Prioritise mobile design before desktop

Ideally, if we support both mobile and desktop view, we have to design and optimise for both. But due to many factors, it is not possible to give equal attention to both. So, since our major audience is visiting us from mobile phones we should have given priority to designing mobile views.

What we did: Optimised the mobile experience and separated the views for desktop & mobile. Also, made a global variable for a threshold of screen width so that all the views can be synchronised to width changes together.

8. Design before implementation

Most of the times, we tend to dive into code without any planning. And as the saying goes “No plan is a plan to fail”. Without any clear image of what we were trying to make, we wasted most of our implementation time in designing. We did this with our dashboard page and it resulted with a clutter of multiple theories.

What we did: We began with pen and paper designs for both desktop and mobile views for the dashboard. Using that as a goal we built the front end system and made improvisations from that point.

9. Follow basics of UI design

Most of the times the problem with our design was that it was missing some very basic guidelines. Like elements of the same hierarchy were placed at random spacing, messing up their vertical or horizontal alignment.

What we did: We removed all the existing spacings and built from bottom up. Starting from the smallest element first, we placed each element using predefined variables. Doing this fixed major overall look of the website. There are other fundamentals that you can refer here.

10. Make the experience intriguing for the user

The product was not a fun experience for our target audience. Even if we ignore all the other problems, the major one was the experience of any one visiting our website. The experience was not indulging and fun for anyone using it and did not promote community feeling.

Conclusion

All this might sound very obvious to most but for the impatient guys out there like us, these things are not even considered during the development process. We also never knew the importance of the processes until we were hit with the same problems we were warned about in theories. Hope you will NOT ignore these and save yourself from the infinite loop of restructuring and management.