Blueprinting the tools
What is the process that you go through before every new project? You set the requirements. You talk with the client, you discuss functionality and expectations and you set timeframes for releases and testing. After you’re finished with that you decide on the right tech stack depending on the needs. You do your research and planning and start coding. Now, even though everything seems simple and straight forward there are many things that could go wrong.
Let’s say you underestimate the task and give an unrealistic timeframe for execution. The project will drag on, you’ll get yourself in a lot of technical debt because you will be rushing to the finish line and end up in a big bowl of spaghetti code. Another problem I have personally encountered often is when the client starts asking for little changes in the middle of the execution. It’s important how you manage this situation, or you can end up rewriting the same code every week because the sponsor had a change of heart. Another problem developers have encountered is having to switch tools. You started off with MySQL but it turned out Postgre’s geo features work a lot faster, so you’ll have to figure something out here. Even worse, you may decide to use that hipster front-end framework that’s making a lot of noise lately. Too bad it’s badly documented and it lacks a good community. In other words, you picked something that’s not fit for the current task, because you didn’t take everything into consideration.
There are a lot of things that you need to have in mind before picking the stack you’ll be using. Recently, I had to make the decision of what technologies to pick for an upcoming big project. An experience that was more challenging than I expected. This article will be focused on some of the enlightenments and thought processes that I went through.
The chainsaw or the axe?
Q: What framework should I pick? A: What’s your project?
You’ve got something of a larger scale coming up? It has specific functionality and must be updated in the future? Yeah, you definitely want something better established. Pick something with a strong community and good documentation. Check who is using it and who is supporting it, that can tell you a lot about the tool’s future. Also, favour convention over configuration. Unless time is not an issue, you will want something that can get you up and running easily. The frameworks which rely on convention have the basics set up for you. They have already made their opinions clear, you only have to develop “their way”. Examples of such frameworks are Laravel and Ember. Having a powerful tool is great, unless you have to configure the hell out of it in advance and create a few openings for errors in the process. Having a chainsaw is handy, unless it comes disassembled and you have to put it all together yourself.
On the other hand, you’ve got something small lined up? Now here you have the opportunity to experiment a bit and use something more lightweight. As a matter of fact, you SHOULD pick something that is a bit lighter for such a task. When you go on a vacation you pack your stuff and put them in the trunk of your car. You don’t hire a moving truck to get your suitcases to the sea side just because it can “carry more”. You don’t need all the unnecessary bloat that comes with a big framework. Laravel is a great example for that. It ships with a lot of built in packages and tools that can definitely be useful, but if you need just a small API going you may want to take a look at Lumen — it’s micro-sized lightweight sibling.
With all that said, with today’s temps of tech development whatever you chose will be obsolete in a year or two, so make your decisions wisely and don’t jump on any bandwagons because of something you read in a blog post.
Know your tools well
Probably the main factor that makes a project successful is it’s timely delivery. The speed with which you execute a given task is crucial. Even though there are a lot of plugins and libraries that ease the development process, it still depends a ton on experience. Your experience as a developer, your experience with similar projects and most important — your experience with the technology you’ve chosen. One won’t be able to complete a successful project on time unless he knows his tools well.
We all know the feeling of excitement you get when you’re dabbling with a new framework or learning the specifics of another language. I had a short period in which I was trying out new stuff every week. One week I was learning Rails, next week I found myself reading Django tutorials. This is all great. It’s good to know how other things work, their advantages and what they excel at. It definitely widens your knowledge. But sadly, this alone doesn’t give you the ability to build something — experience does. No matter what you’ve read and watched, your first real project with a certain tool is always a learning experience. So, either pick something you already know, or take your time to learn beforehand. Build something small and read about style guides and conventions, it will save you from an unhealthy experience.
One piece of advice I can give here is to always keep an eye open. Don’t jump from tool to tool, but be on the lookout for things that could make your life as a developer easier and don’t get encapsulated in a single technology just because you know it really well. I was already deep into React and Redux when I found Vue. I took some time to get to know the library and it’s now my go-to tool when it comes to front-end work.
Talking vs Speaking
Proper communication between the teams is as important as settling on a programming language. Synchronisation between the different members is essential for the timely delivery. When you’re writing the specs, make sure everyone on the team and the client have access to them and can relate to them at any given time. That way your developers know what they have coming up ahead and your client knows exactly what he agreed on. I have worked with unclear requirements and most of the time it leads to multiple rewrites until we get things clear.
In order to ensure the proper communication you may want to settle on some workflow methodology like scrum. That really depends on the scale of your team though. For smaller teams you definitely need that daily meeting and proper task management, but you can skip on most of the administrative work. For larger teams and projects, on the other hand, yeah you want that extra separation of responsibilities and proper documentation.
Don’t forget that workflow methodologies are also tools. And like any other tools, they need experience and take time to learn. My personal opinion here is to read more about the topic and pluck only the methodologies and activities that fit your current team and assignment.