Growing Android fragmentation — or device diversity if you prefer — has been visualized in a new report by crowdsourced cell phone signal startup OpenSignal, which has surveyed 682,000 devices to build its annual peek at Google’s mobile OS ecosystem.
I don’t know how Android apologists will spin this but if you don’t call this fragmentation, I don’t know what is.
Last week, The Verge had a controversial article about Slack:
Are people using Slack to replace workplace email wholesale?
Yes, for a lot of three-person teams, a lot of 10-persons teams, and a lot of 100-person teams. It’s all or nothing. If half of your team was not on it, then the whole team would stop using it pretty soon.
We’ve been using Slack since February this year (yes, really). Initially, I thought it was just another app in the crowded messaging space. Nonetheless, I was impressed by its UI so I gave it a shot. I asked my team to sign up and try it out. Our usage eventually dwindled because we are using Skype as our primary communication tool. Slack as a communication platform just cannot compete with Skype.
This goes on for a while until I discovered Slack’s true power: third-party integrations. Because of our recently-implemented code review process, I wanted to be notified whenever a developer commits a code. Incidentally, this is right up Slack’s alley. Slack has an impressive roster of third-party integration, including Bitbucket. For every repo that I want to be notified, I simply create a hook and pair it with a Slack channel. Viola! Instant commit reminder. Here’s another cool usage scenario that we recently adapted: we wanted to be notified whenever a file is dropped in a certain OneDrive folder. This is part of our internal backup process. Using a third-party app called Zapier, we were able to bridge Slack with OneDrive, which is pretty sweet.
Overall, Slack didn’t kill email in our office. At least not yet. In spite of that, we’re a happy camper. We are now obsessing on how we can integrate it further with our internal processes.
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.
If they’re laughing so hard, it’s probably not good either.
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.
This is a little late but more than a week ago, there was ruckus regarding this post from Secret. CodingHorror retweeted it. But this comment grabbed my attention. As someone who has a Windows in his Macbook (VM via Parallels Desktop), this is just downright clueless. If you’re a mobile developer doing enterprise apps, having .NET as a backend is very comment scenario.
Brent Simmons on being wrong in the internet:
But to do that means thinking a little bit differently than you may be used to. Instead of taking feedback as criticism or correction, take it to mean that the process is working. If you learn something or change your thinking, then that’s great. That’s the point.
I couldn’t agree more. The stigma of being wrong is such a huge impediment to self-improvement. Which reminds of this:
xkcd: Duty Calls