ENGINEERING BY CRISIS
This is Sparta!
Engineering by crisis is defined (by self) as the process of actively learning a new technology, methodology ,language,tool..etc .. while simultaneously incorporating the aforementioned stack into production with all prior conditions and restrictions that come with the process of launching a software product — ,release dates ,workflows, tests ,etc still in place. Not to be confused with ,though related to ,the more established term Software Crisis
The process of Engineering by Crisis is initiated ,sometimes by fairly innocuous actions. A good example would be the current crisis at Zoom where developers suddenly had to implement end-to-end encryption NOW within their product.
More commonly though they come as a result of a shift in strategy to keep up with current best practices , e.g implementation of Microservices , SAAS vendors ,TDD or CI/CD in projects.
Engineering by crisis is easily identified by high levels of developer turnover , increased number of missed deadlines , lower quality code , and the usual push and pull between QC ,testers ,project managers ,product owners and engineers becomes especially tense (to put it lightly).
Unfortunately however ,it is how most developers especially those working in rapidly expanding start-ups tend to learn their craft. Small companies cannot afford to have timelines that are 12 months long with deep dives into whichever tool is being planned .Most times ,project iterations and progress is measured in days and weeks, sometimes less ,with team members wearing multiple hats and being responsible for larger and more diverse sections of the product.
The result is that Engineers become jack-of-all trades but unfortunately masters of none. In the rapidly evolving field of Software Development ,engineering by crisis is unfortunately inevitable at one point or another in the course of your career. It is possible however to minimize or at least prepare for this situation. The best way is by:
- Anticipating future demands on your skills and being aware of coming trends and equip yourself with these tools or at least be more than familiar with these by constantly building and learning on your own.
- Before switching jobs, as engineers frequently do , be familiar with the stack your chosen future potential employers use and learn how to use those tools well or better yet choose the stack you want to learn and only apply for positions where those are used. It will save everyone involved a lot of pain. If you don’t want to dive into the deep end completely ,then go to a place where you will build on what you are already familiar with rather than starting from scratch.
With that here are some of the tools and trends to become familiar with in 2020 and 2021 :
Microservices
Microservices are the resulting standalone services after breaking a software application down into separate components that perform their function(s) without being embedded in the application itself.
This is simply extreme modularity ,(OOP anyone? ) Where your objects are now seen as mini-programs ,doing one specific task very well ,accessible via a standard set of rules by any other object (mini-program) or application globally , for example companies may choose to have a single database access object used independently by multiple apps and services within the organization. A good explanation can be found here.
Message Brokers
A broker ensures communication between different micro-services is reliable and stable, that the messages are managed and monitored within the system and that messages don’t get lost. here are a few message brokers you can choose from, varying in scale and data capabilities. The three most popular brokers: RabbitMQ, Kafka and Redis. Make sure you are more than passingly familiar with at least one preferably two, I would recommend RabbitMQ and REDIS
Containerization
A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another. A container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings. ( By now I hope you can see a trend in my suggestions.)
Cloud Computing
All the above mentioned tools are designed to run in the cloud and thus being familiar with how to write ,deploy ,and mange applications to take advantage of cloud computing power and flexibility is now compulsory. Get certified!
- AWS — Amazon Web Services
- GCP — Google Cloud Platform
- Microsoft Azure
CI/CD Pipelines
A CI/CD pipeline helps you automate steps in your software delivery process, such as initiating code builds, running automated tests, and deploying to a staging or production environment. Automated pipelines remove manual errors, provide standardized development feedback loops and enable fast product iterations . Checkout an explanation of Github Actions .
NoSQL
NoSQL is a non-relational DBMS, that does not require a fixed schema, avoids joins, and is easy to scale. The purpose of using a NoSQL database is for distributed data stores with humongous data storage needs. NoSQL is used for Big data and real-time web apps.
The last statement is especially important since most successful apps will be expected to scale eventually therefore should be designed as such even when they are not successful ..yet.
Popular examples include,
OpenAPI and Swagger
If you are involved in API development ,use services exposed as API’s (absolutely everyone) then you have ,knowingly or otherwise, come across OpenAPI and Swagger , and will have to use them in future ,willingly or otherwise. Thus it is best to understand the Open API specification sooner rather than in the middle of a project later. For an explanation of what OpenAPI is and what Swagger is check out Ryan Pinkman’s blog.
Load Testing
Load testing or stress testing is done to determine the performance benchmarks or breaking points of your application e.g what will happen if demand suddenly spikes ,(rihanna follows you ..inexplicably) . Every developer must do stress testing if only to avoid having being told to do the job all over again . Some good tools include:
- LoaderIO (my recommendation) ( https://loader.io/ )
- Loadninja (https://loadninja.com/load-testing/ )
- Loadimpact ( https://loadimpact.com/ )
Honorable Mentions
- Code Profilers
- Package managers — NodeJS NPM, Yarn
- Build automation tools — Gradle ,Maven
- Microfrontends
I intend to provide working sample applications and tutorials for some of these technologies over the coming months so feel free to follow me to get updates.
Thanks a lot. 👋
