Thoughts on build UI
• Mark Eschbach
In a bid to clean up some rough edges before the end of the year I’ve been working on some UI code. This isn’t the new green field code everyone is chomping at the bit to work on. The code I’ve been modifying is literally from two ages ago in the company with a relatively well known expiration time coming up in the near future. I drew the short straw because I’m one of the few people who has worked with this code. I know the designs, implementations, and limitations of how we implemented it. This project also preempts a lot of other improve the platform work I had previously slated.
Going through the code, I know we built everything quickly. We built it quickly because we are a startup. Ths list of tasks to be completed is ever growing for us and honestly about half the code to ever go into that code base has since gone to the great bit bin in the sky. There is also a great deal of code which we have hammered into it’s new form when we’ve pivioted.
I have a heavy bias towards building reusable modules. Generally, even in a fast moving environment, building a reusable UI component will pay dividends well in excess of the effort. This is in line with my general view point of building things to last. On the surface this appears to be a contradiction of the Startup Philosophy of “Move Fast and Break Things”. In truth some features should be built quickly. Some also need to be considered for how important they are to the core business and platform. When your problem domain or executino environment hinges on a concept then that is time to build something which lasts.