Difficulty of proper Code-Review

Here’s another point in software development culture, that is hard to get settled into an organization.  To be fair, it’d be more accurate to say that instead of a culture being wrong, that it’s just different – between people and of course, organizations.

Culture is shared and similar thoughts and actions in a community.  A person may be part of a community and be knowledgeable about the goals and traits of that community – yet have immense difficulty to follow along.  Simply put, changing an individual’s habits can be achieved through personal agenda and strength of desire, but community culture is much more difficulty to affect changes unto.

Unsurprisingly, it’s hard to follow even a commonly known development culture.  And the one I bring up today is the culture of ‘peer review’ of code.

Arguably, code-review is one of the most important culture in a development environment, but it’s hard to find it done well in many organizations.  Many know and agree to its importance, but most try-and-stop and repeat many times.

Why the difficulty in doing reviews?

The most common response to that question is:  no time.  Understandable reality – teams have a tough time to even to implement features.  To many, it is statistically true that doing code-reviews appropriately saves total time to implement as well as cost, but it also sounds like a pipe-dream – realizable only in an alternate universe.

Some companies enforce code-reviews, but it can also be executed to fulfill a process, instead of serving the real purpose – resulting in bad memories.  A few bad runs, and the review process does not become culture but is either stopped or is kept as an ineffective action item.

In my opinion, the culture of code-review is not trivial enough to simply quit because it is tough.

There are many reasons for reviewing.  Discerning errors in code, as well as shared knowledge and mutual education are just the first ones that pop into my head.  Review has organization-level purpose of improving quality, but knowledge and info is shared through the process, as well as know-how and insights – leading to mutual growth of developers.  The knowledge community can be enhanced through reviews.  In fact, I would even argue that without code-reviews, the core capabilities of developers will be tough to improve.


automate…almost everything

DevOps, Data-collection, Data-Delivery, Analytics, BI, Compliance.

These are fine goals, which our company and every OpBrand in the group are trying to achieve.

We have IBM managing our IaaS, mostly. However, our business projects and their management is not. Going to work on changing that, for 2016 – H2.

Hopefully that helps in automating parts of project-management with our infra and compliance management, via integration. If there is an existing solution approach, I’m ears.

Suggesting a near-real-time data collection and delivery from multiple sources is currently under way – bubbling it up the group for buy-in and budget.

Analytics and BI is after that – R modeling and predictive analysis is the goal – not just for software development, but the rest of the business.