The Product Manager has written the specifications, everything is clear and you only have to give the kick start to you team of developers.
At this point is where you can start to fail. If you let everyone involved to do whatever they wants, your project will be pure anarchy.
This is a short list of things to consider before starting to write code. They will give you some chance to create a good product without losing your mental health.
1. Select a VCS and Lay Down the Rules for Commits and Branches
I suggest you to use Git. I have already explained the reasons in this post but, to make it short, Git is fast, cheap (not just because it's free, but also in terms of disk usage) and extremely powerful.
Then, set clear rules for commits and branches, to avoid that your repository becomes a landfill. You can take inspiration from this great post. The rules should also cover commit comments, because it's important that every change is well documented.
2. Define Coding Styles
Using the same code style is crucial when many developers are working on the same project. Everyone should be able to understand and modify every piece of code without spending time to feel comfortable with indentation and names.
This is the trickiest part of the project setup. Usually programmers are very reluctant to change, but, hopefully, they will understand if you show them the benefits and the reasons. I like the Linux Kernel coding style because it provides a rationale for almost every rule.
My goal is to read a piece of code and not be able to tell which developer wrote it. In any case, if you are wondering how you can detect the author of each line of code, Git has a command for that: blame.
3. Define the Style for the Technical Documentation
It's a good practice to write a short description before each function. Doxygen is a wonderful tool to collect all those comments and generate a document or a website for a quick reference.
Obviously not everything can be specified in a comment into source files. To write documents that can be easily managed by a VCS, you can use Markdown and Multi-Markdown. The idea behind MD is to have an easy-to-write language to create HTML snippets that is also easy-to-read. MMD adds some features (such as tables) maintaining the same philosophy.
If you prefer a WYSIWYG editor, you can save your documents in odt format and use odt2txt to let Git show the differences between revisions. This is how to proceed; unfortunately this works only for diffing, merge is not allowed.
4. Chose a Decent Bug Tracker
Maybe now you are asking why is important to choose a BT before having written a single line of code. There are three main reasons:
- You can use it also to assign development tasks,
- Soon or later there will be the need to change the original architecture; use the bug tracker to host the discussions, and
- Don't let the Quality Assurance team choose for you.
Speaking about bug tracking tools, in my company we use Mantis and I can say that it's not so bad for medium-size projects. I've also used Jira that, of course, is much more than a simple bug tracker.
More about bug tracking systems in this post: You Need A Bug Tracker
Bonus Tip: Draw a Plan and Track the Progresses
No matter if your development strategy is waterfall or agile: you need to have a general idea of the effort and a rough timeline. Then you can revise it as the project goes on and changes are required. But absolutely you have to start with a plan.
It's important for you and for the team to have an idea on the order of the features, what needs to be included in a MVP or at what point the customer needs to be engaged. Keeping this plan up to date is also a good way to communicate the rest of the company the status of the project.
There are lots of tools that can be used to help you: there is MS Project (or its open source alternative Planner), Jira has recently added the Roadmaps, other online apps have this functionality. But also a simple spreadsheet with the right template can do the job.
Remember You Are Not Alone
All the above points are useless if they are not agreed by the development team. Rules should not be imposed from the top, but discussed with all programmers involved in the project, to make sure they understand the logic.
It's important to keep an open mind in this phase. Developers can suggest some improvements based on their experience, to better adapt those rules to the specific project and the team.
OK, now you are ready for the kick start. Good luck!
Image by courtesy of Riccardo Esposito (Blog, Twitter)
Post last updated on 2020/09/01