In the book "Crossing the Chasm", Geoffrey A. Moore describes the characteristics of visionaries (early adopters) and pragmatists (early majority), and the chasm between these groups of people. For myself, I tend to think I'm half visionary and half pragmatist, as part of me wants to explore new cool technologies by building something (visionary), and another part of me tends to make sure my choice is suitable for production and that can last.

Lately, I've been working on two projects: a hobby project and another for my company; or a GUI app and a web app. While kayaking from initial conception, design, until implementation and testing (up to now), I derived some clearer guidelines for myself when it comes to investing myself into a technology. I use the term "technology" to cover libraries, plugins, frameworks, languages, protocols, etc. The following guidelines are not limited to web apps, but to software in general:

#1 Create a testable and distributable toy project

Make sure the toy project:

1. will work on all platforms to be supported (Browsers, OSes, etc);
2. can be built and tested in an isolated environment (In containers, virtual environments, etc);
3. deployable within a few lines of code using CLI.

For example, if I were building a cross-platform GUI app, the minimum step to verify the feasibility and viability of a framework would be:

1. Set up an isolated environment in your development machine (Docker, virtualenv, etc);
2. Clone and run the demo/example app provided;
3. Make sure that it works on all platforms (MacOS, Linux, Windows) supported with no or minimal hack-around;
4. Is testable;
5. Can be easily packaged (Eg: freezing in Python) and/or built-in isolated environments;
6. Make sure the packaged size is acceptable compared to the functionalities/complexity of your app;
7. Can be built using CD pipelines (Eg: Github Action);
8. Can be distributed via package managers of OSes.

#2 Focus on the solution of the problems, not just the hype

If you are in web development, you are probably familiar with the term " JavaScript fatigue ", with new frameworks/libraries popping up from nowhere all the time, some developers find themselves chasing after new frameworks for insufficient sensible reasons to the point they became fed up.

I believe, if we are evaluating a new technology, we should focus on the problem statements and understand how exactly a newer technology could improve the lives of users (developers, or product end-users).

To exemplify, GraphQL solves the issue of over/under-fetching, allows us to delegate simple data validation (type checking), and supports complex queries. With the help of proper tools, it is apparent that it could help developers to reduce development effort. The issues it tries to solve is broad enough for us to invest even at an early stage.

#3 Understand the hidden/unknown cost for production

You may find this absurd, how could one predict the unknown? Well, learn from others' experiences.

Often time, hidden cost incurred for production build is unaware of. A quick example would be configuring AWS IAM permissions to backing services (S3, SES, SQS, SNS, etc) for your application. In a development environment, developers may get as much permission/privilege as they desire. However, when it comes to production, the principle of least privilege should always be applied and this is usually a daunting task of piecing together a puzzle (You know what I mean if you ever attempted to configure permissions properly in AWS IAM).

The time and effort required for production configuration and optimization are sometimes, being neglected. A quick Google about the feasibility to create a production build is generally recommended.

Conclusion

Lastly, I believe no technology is ever-lasting. Just take a look at the history of Adobe Flash. With a myriad of open-source software in the wild, all we could do it to try our best to reduce the risks.

I appreciate any feedback or suggestions. You can always leave a comment or find me on Twitter @melvinkcx2

Cover image by kjpargeter