Being part of the IT industry for many years as I am, is really common to hear many buzzwords meant or intended to transform something into another, but not always necessarily to a better version. Whom of you haven’t heard anything about Full-Stack developers, DevOps, Cloud, Cloud-First, Mobile-First, Disruptive Technologies, just to quote a few recent ones.
For a time in the recent past it was really important for an IT professional to become a specialist in something, focus on some technologies and really understand how it works under the hood. Being a specialist in something was something really good from a career perspective. You were always involved in some really complex projects, projects which most of colleagues couldn’t get them done. Because of all of that, you could ask for your price and companies would pay for you to get the project done. I’ve been there and done that with SharePoint projects.
More recently, most because of Node I’d dare to say, the term Full-Stack developer was forged and with that, professionals were encouraged to be more generalists rather than specialists. Suddenly, the developers that were part of a Silo (Back-End vs Front-End) had to leave their own island and take a journey towards the unknown.
The same thing happened with the DevOps. Developers had to leave their comfort zone and get their hands dirty with some infrastructure knowledge. I don’t think this was a bad idea, au contraire, it is important for a good developer to have some infrastructure knowledge, to understand where his code will run and understand the impact of something that he wrote may have on the hosting infrastructure. It is even more important to be able to automate tasks that you had to do manually in the past, so you could really concentrate on what really matter the most, writing the code 🙂
The bottom line is, after I’ve had experienced all those “changes” in the industry and worked in a lot of different projects, quite often the issues that I encountered in the projects I’ve worked on is a lack of a properly defined workflow, how the project will evolve throughout its lifecycle, from its conception to the delivery; how easy will it be to create new releases, to onboard new developers, to implement changes.
In my opinion, having a well-defined workflow is a really critical factor for the success of the project. Automate everything you can, make it easy for incremental deployments. Take sometime at the beginning of the project to setup such things, it will pay off.
Start with just a Hello World. Define the project name and that’s it. Create a repository to host the code and configure the Continuous Integration/Release right away. There aren’t many dependencies yet, so it would be easier to configure the build and the release of your project. Check the outcome of this process in the released version (if the application is a website, just navigate to the url and check if everything is running).
With these steps, you will already have the procedures required to build and install your application. When you add new features, you’ll always think about how the new feature will be installed upon the previous version, the impact of the new feature and the steps required to make it available. You’d also reduce or completely remove the “it works on my machine” and will be confident that a deploy will work, because you have been already testing the very same process since the beginning of the development. Time and money saver!
So, whenever you think about your next project, take a deep breath and start thinking about the workflow first. It is really nice to go directly to the bits and start working on a new project, but I assure you, the planning time will bring a great benefit for you and your company!