Rapid Development

dynamic-python-developer
Feb 22 · 7 min read

Rapid Development should mean all your developers are able to immediately get up and running with your codebase to become as productive as possible.

Photo by Ian on Unsplash

Let’s say you’re an up-and-coming company with lofty ideas about building a SaaS offering that gathers data from platforms like AWS or Azure or GCP or all of them. Your code features “connectors” that grab data from all those platforms so you can provide a real service to your customers, to give them insights into their I.T. Infrastructure they cannot get elsewhere. This is a common enough scenario for a good number of companies out there.

Let’s say now you want to add more developers. Will your newly engaged developers be able to immediately know what your code does so they can become productive quickly? This should be a big concern but is this rapid development? Maybe not. Newly engaged developers will have to learn your code over time, typically this takes 2–3 months. Can you afford to pay those newly engaged developers for 2–3 months until they can learn enough about your code to develop effectively? Will you have the patience to wait for your newly engaged developers to learn-through-osmosis? Some may not have this level of patience.

What if you, as the Development Manager, had been smart enough to task your newly engaged developers to dig into your code by building a rapid development environment? Would this 2–3 month effort bear any fruit for your organization?

How might Rapid Development come to pass?

The thing you should want as a Development Manager is a robust offline test environment for your software developers where they can run your whole stack locally via Docker. This is what you want, believe it or not. This is always what you should want. But is this what you have, now?

But how can you build a development environment that takes data from all those public cloud platforms while being able to fully test your code offline before deployment? Keep reading.

I think both terms are entirely interchangeable, in my universe where I do my work. If you have read some of my other articles you may have noticed I have spent a good deal of time talking about Microservices and REST APIs. I have built two complete frameworks for this purpose, one of which could be used for a SaaS offering and the other is a Lite version with no support for SaaS.

Now consider the idea of building a faux public cloud where you can get the data you need for your own SaaS offering you are building without having to be connected to any public cloud platforms. Huh? Yeah, you want to enable your developers to fully test all your code offline in a simulated environment where all your code, your databases, and your UI can be fully tested without having to connect to any public cloud platforms. This might sound like a crazy idea and for you, this might be true but I like crazy ideas that run counter to the way the rest of the industry is working to see if there is any value in thinking about what seems “crazy”.

So you choose to do the crazy thing just for kicks, let’s see how this might work. You build out several Docker containers, one for database another for UI, and another that simulates public cloud platforms. Two of the three you will need anyway because you want to deploy your code via Docker because you want your code to run in Kubernetes, in case this becomes advantageous.

The only part of my proposal is that 3rd Docker Container because it simulates all those public cloud platforms. Actually, it simulates one public cloud platform because this is all it has to do. Simulate one public cloud platform and you have simulated them all, trust me.

You should have plans for building out a REST API to gather data from all those public clouds anyway, this is a requirement. This REST API will take a parameter that tells the system where to get data from which will be AWS, Azure, GCP or etc. One REST API for all public cloud platforms because this just makes sense, I think. Let’s face it, this is the smart approach. You might be surprised to learn this may not be the smart approach for most companies that are engaged in this kind of development. It should be.

Let’s say you did the smart thing because you are secretly insane. Well, you would have to be secretly insane to do the smart thing in this world, anyway. You have one REST API for your data sources which means you are halfway to the rapid development goal. Now all you need to do is add one more parameter to your REST API that says the data will be simulated and now you have achieved rapid development and your newly engaged professionals can simply run your whole stack offline where they can do their thing and quickly build new features for your SaaS.

Is this still a truly crazy idea? Or has it become the smart approach? This would be my approach were I the Manager of Development for this fictitious company. I would do the crazy thing because I have. Well, I have the code sitting on the shelf I could use for this purpose because everything you might ever want to do with code will require or be enhanced by being able to quickly build and deploy Microservices or REST APIs. Everything.

During a raging worldwide Pandemic when the economy went into the toilet and was swishing around the proverbial toilet bowl I spent several months building the means to rapidly develop and deploy Microservices or REST APIs. I did this with no money and no prospects for having any money. I did this because I recognized the value in having this capability because everything requires Microservices and REST APIs. So I embraced this seemingly crazy idea because the whole world was going crazy over COVID and I did not want to get that disease so I rejected the opportunities where I might get to get sick in favor of staying healthy but this meant I had a ton of time on my hands.

So now that I have embraced the crazy thing I am here to share my thoughts about rapid development because this is how I develop my Microservices and REST APIs. I build my Microservices and REST APIs entirely offline but I deploy them on the interwebs. Rapid development.

I would build out that third Docker Container or task someone new to do so because I would want rapid development and all the benefits of doing so. This is also why I will never be asked to do so in the real world because this is not the smart approach for all those companies out there who are now engaged in building their amazing SaaS offerings. Trust me, I should know.

But consider one REST API for all public cloud platforms. Adding more public cloud platforms would be very easy and simple with minimal effort. This is the benefit of doing the seemingly crazy thing.

Firstly it makes too damned much sense and corporate America despises things that make this much sense.

Secondly, I will only get hired to do this by those who are doing this rapid development thing and since none are then I will also not. People hire based on their own current practices but not based on someone else’s current practices.

Thirdly, this sort of thing will probably always be seen by business people to be crazy because business people know virtually nothing about technology and they will prove this to you when you have interviewed with enough of them. This is why they cannot grow the talent they need for their development efforts; they can only harvest existing talent. Growing talent would mean hiring people without direct experience and they cannot do this.

Everyone loves a crazy idea when it works.

This is how we have electric grids and airplanes. Both were considered to be crazy ideas early on but now both are indispensable where people can die without either or both. Cold snap hits Texas and some people die due to the lack of electricity. This happened.

In the meantime, I get to write about my seemingly crazy ideas and I am here to tell you they work.

What did people do with electricity before they knew what it could be used for? Parlour tricks. Making hair stand on-end. Yeah, that was electricity.

Did anyone think the Wright Bros were crazy? You can count on it. Did that cause the Wright Bros to give-up and stay on the ground? Hmmm. Maybe not.

But think about how crazy an idea electricity is the next time you hear about people dying in the cold when they cannot get the power they need to stay alive. Not so crazy.

Airplanes are a crazy idea. No getting around this one. Heavier than air! Really? And it flies? Crazy. But it works.

Do the seemingly crazy thing!

Dynamic Python

Python is so dynamic

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store