Project chaos and how to deal with that?

3 levels of mess

Design level sins:

1. For UI developers there is nothing worse than having the project design provided in a format which is barely usable. What do I mean by that? When your designer sends you designs in JPG or PDF exported from Photoshop and checking the sizes, colors and spacing is almost impossible and of course forget about extracting assets such as images or icons. Sounds like hell? Let’s jump to the next one!

2. Sometimes front-end developers are treated as unicorns and others think that besides being responsible for the implementation we are also half-designers and half-project-owners and they leave us a lot of room for interpretation. For example we are asked to code a responsive site but the client/designer/project owner totally forgot about giving us the mobile version of the design.

3. Fifty Shades of Gray and other stories such as a huge number of differences between elements with similar usage. For instance, instead of having one simple shaped button with a different background color, border or hover effect based on the place of use, we have a few differently sized, differently radiused borders and with plenty of font types. Except for the visual chaos and weak UX issue we have implementation problems.

Project level sins:

1. The so called Naming problem. Running a project using a component pattern should lead us to keep it as simple as possible. However the project’s nature is to grow up, especially when it lasts for a long time - people come, features come, clients change their mind about parts of the UI. It sounds difficult to keep the starting scheme but seeing two components named BasicButton and DefaultButton should arouse our attention.

2. Problems with the wrong files and folders structure. A General Button component file hidden in the Footer folder sounds illogical and seems to be a silly mistake? Believe me, I’ve seen that before!

3. Sometimes using toolkits or UI libraries such as Material UI, Vuetify, Tailwind or the old and well recognized Bootstrap sounds tempting, especially when the design looks like it’s based on one of them. However mixing it with your own class naming convention is messy and confusing.

Repository level sins:

1. Enigmatic commit messages. When you are dating, a little dose of mystery sounds like a good plan but when writing commit messages go in the opposite direction. Unless you would like to force your teammates to dig deeper in your code to find out what these changes are about, writing commit messages like “a few simple changes part 2” tells nothing, it only makes a mess.

2. You started the project, had a perfect plan for the development process model, described it clearly in the README file, started working, the plan failed, you changed your mind, changed the way how to run the project in development mode and forgot to update the README file with the proper information. Jola, the new junior front-end developer, joins your team, how to make it possible for her to work on this project without any problems?

3. Forgetting about the Changelog update, keeping Pull Requests aligned with the e.g. JIRA issues and being messy with your branching culture at first glance, it may seem like a minor problem but it’s a real pain in the ass, especially in bigger projects.

4. “We are such good developers that we don’t need a Code Review.” - Nonsense! Everyone needs a Code Review, but if you still think it doesn't concern you, let the others learn from your code. Jola, the new front-end teammate, will appreciate that.

Mess costs - real project value

If you are still not thrilled by the sins described above and think that these are just small things that may not make you lose money, pay attention and bear with me.

1. Time lost on introducing new people to the project.

2. Unnecessary questions.

3. 50% of development and 75% of bug fixing.

How to deal with the mess?

I hope that now you’re a bit more concerned ;) But no worries, these simple problems have simple solutions. See below.

Dear designer, your front-end developer will send you a huge kiss if you:

• Use Zeplin, Figma, Invision to provide the designs.
• Mock the functionalities using some wireframe tools - eg. Balsamiq or Lucidchart.
• Remember about providing mobile views (and for other devices if needed)
• Set the information about sizing base e.g. “I designed it in Material Design so the sizes are multiples of 8”.
• Create the color palette you used and attach it to the design.
• Provide the assets - images, videos and specific elements of the design such as icons in SVG format.

Dear developer, remember to use:

• Design tokens - create base variables for the color palette in your project then use tokens for the elements used in your project. For example:

• Known conventions for project structure, naming and so on - and remember to stick to it - Atomic Design, BEM
• UI Libraries - sometimes it’s a good idea to use them
• Tools that help you to maintain order - eg. Storybook and
• Remember about clean commit messages
• Write a change log and keep it updated
• Read about the Git flow good practices and follow them

Writing this list of advice I kept in mind that our time is of huge value so I kept it as short and simple as possible. Being aware of the sins and mistakes we could make in our everyday work life is the first step in recognizing the leaky places in your wallet. And if you try to patch them Jola will thank you, your clients will thank you, you will thank yourself and the world will become a better place to live.