Tony's thoughts
Knowledge sharing is invaluable.
Be quick, but don't rush
I am a huge advocate for iterative development and releasing in small chunks, however we should be mindful of the potential technical implications of moving quickly.
I have found that when developers rush and put something together without a clean and scalable approach, it can seem that the team has saved time when shipping a new feature. However in the long term, it's most likely that you'll be losing time.
Such approaches are great for proof of concepts and there are times where technical improvements can or should be made afterwards, but if a pattern of "clean it up later" evolves, it will cascade and create a large backlog of technical debt.
Unscalable code can seriously hinder future development. Things become difficult to maintain and reuse - causing additional time and effort to deliver new requirements.
Ultimately, this scenario can cost a business a lot of time and money, with probable instabilities and technical frustrations.
For example, a developer could quickly put together some logic in say 30 minutes, but in the future, another developer may need to spend 2 hours debugging and cleaning it up in order to start working on a new feature.
In this example, 2 hours has been spent cleaning up a single piece of rushed logic. If this type of scenario is repeated, it can cascade into months or even years of additional effort and funding - delaying features or enhancements that provide value.
Make sure that what's moving quickly will not make you move slower in the future.
The web was built to be accessible
Imagine a scenario where your application has 500 thousand users and after some marketing, user acquisition scales to 1 million.
If 20% of the new users have for example sight or reading disabilities and your application is not accessible, 10 thousand of those new users could be unintentionally rejected and/or have a frustrating experience, probably to never return. This also introduces reputational risks.
Only since some certain technologies and patterns were introduced and become commonplace, have websites and applications run a risk of becoming inaccessible.
There are many great designs and features out there that look fantastic, but for some users, it can hinder the experience and even make the user journey impossible to complete.
I recently worked on a project that passed an accessibility audit with the best possible level of compliance (WCAG AAA). We achieved this by prioritising accessibility from the very start.
Keeping things simple generally helps with accessibility - this can also help to get a product to market. Therefore, if a design starts with a simple MVP approach, it can be delivered quicker and simultaneously address accessibility concerns.
Moving forward, the design can be iterated to enhance or streamline the user experience, without affecting the core accessible journey that has already been built. This also removes the risk of having to spend additional time retrofitting an application to become accessible.
Keep it simple - for accessibility and delivery.
Maybe we could build something together?
I'm very friendly and love to collaborate. My email address is tony@tonybarnes.me