Then I found moment.js. You’re welcome.
One of the things I pushed for after I got back to project management and development is code review. Poor coding has bit me countless times so I’ve decided to proactively fight it. Projects where code smell often leads to firefighting. Firefighting is costly and personally, I just hate it. Desperately trying to save a project where you could’ve done something from the beginning is the worst feeling.
Code review can help you mitigate this problem. Code review is controversial because some developers don’t believe in its benefits. It takes too much effort but with very little (visible) effect on the project. Additionally, it can be really daunting. Review results typically spell huge code change and endless regression testing. However, I think with proper implementation, it can provide compelling benefits to a team. In just a few months of implementation, I’ve witnessed dramatic improvement in our development cycle. We are more confident with our code. Bugs are solved in a straightforward manner. Modifications are treated and implemented same way initial features were implemented, no hacks, no magic. Here’s how we do it:
- Build guidelines and conventions for your team — code reviews are pointless if you do not establish ground rules. For every technology stack, come up with a set of rules. For example, web applications involve several technologies. Create one for each stack and make sure every team member agrees with it. Put them in your intranet CMS or wiki for easy access. This makes the whole process objective: they stick to whatever was agreed on.
- Do it quick, do it often — often, code reviews are exercised just a few times in a project cycle. Worst, it is performed at the end of the cycle. This is very problematic because by that time any code modification will most likely break a lot of things. The best thing is to do it as often as possible, as short as possible. This divides the whole endeavour into tiny little chunks and makes the effort tolerable. For example, it’s a lot easier to review code on a per task basis than per module or per application basis. By doing this, code review should not take more than 15 minutes.
- Pick a review point — depending on how often you want to do it, picking the perfect timing for code review is critical. In our team, we encourage to commit codes as often as possible. Reviewers are notified whenever a developer commits (we use Slack!) so they can react instantly. They can choose to review it later but they should not let it go to the next day.
- Involve everyone –— conventions and guidelines practically make everyone a candidate to be a reviewer. When everyone is involved, it creates team discussion. It opens up engagement. This is one of the best thing you can do to a team as you put them in a certain cadence. This increases productivity.
- Pick a tool — so what happens next once you get the team fully on board with the code review process? How do you monitor their progress? How do you give reviewers power over the process? How do you convert them into metrics? Pick a tool. Fortunately, most repo-hosting sites come with it and should be suffice for any code review processes. In our case, the ability to view and comment down to the code level is the most important feature. Developer notification comes close second. Importance of features may vary from organisations to organisations so I would suggest to check them out first. If you record KPIs for your team, the tool should give quantified result of the code review.
A lot has been written about the benefits of code review so I will not touch them here. In case you (or your boss) need convincing, here’s a good rundown of its benefits.
Rappler has a good piece about the whole Jollibee #ChickenSad fiasco. I know a little about what happened but let me say it upfront that I am no in way involved in the project. Some of my friends jokingly asked me if we were the reason why the stores are out of chicken. I would be mortified if we were.
I cannot tell what I know (I’m under NDA) but I agree to most of the points that the author made (I distinctly remember suggesting some of these to them). You would think that these are Project Management 101 but you’d be surprise how often and rampant project managers, business process owners and system integrators etc. overlook these things.
I would add one more:
5. Focus on understanding the business and not too much in the technology. Technology alone will never solve a problem at this scale. The more you understand the business, the better you know what the problems are, who are the people you need to solve the problems and what are the ways in can be solved. Technology should not be viewed as universal panacea:
Knowing what the problems are — by knowing the business, problem identifications come naturally. When you know the problem, mapping software features to solve them would be less difficult. Our strategy typically involves immersing our BAs (business analysts) with their existing manual process. It’s a gruelling task but a very important one. Once we are confident enough that we understand their existing process, that’s the only time we move on to the next phase.
Knowing the people you need — domain knowledge engineers are very critical in the success or failure of the project. These are the people who know the business to the guts. They know the pain points. They have ideas on how to solve them (always take them with a grain of salt) and they are the ones who will actually use the solution so involve them as much as possible, as often as possible.
Knowing ways to solve the problems — pure automation is often too complex. Most people just want to do their job and be done with it. Often, this can be achieved by applying what works from an existing process to the new one, even manual process. Case in point, we were asked to add a feature to a certain project where the system would allow them to compose email and send the reports generated by the application. I told them, “Why not just copy the link of the report and send them as a regular email”? After a few convincing, they realised what I suggested makes sense.
We use the format [module-name].[view-name].js. It’s clear and straightforward. Enterprise apps are typically comprised of modules so this way they are grouped together. Avoid using folders to group files as this impedes locating files.