Herding Cats

“Good” programmers are like cats. They are experts in a subject matter with a narrow vision. When cats are hunting (programming) they abstract so much of the task that they risk getting involved in dangerous situations. They climb too high or forget about natural environmental dangers. Maybe that’s why big cats almost always hunt in groups, with specific roles. At the end of the day (domestic) cats will hunt but with a high risk of get killed or seriously injured.

By Jennifer Barnard (originally posted to Flickr as Prey) [CC BY 2.0 (http://creativecommons.org/licenses/by/2.0)], via Wikimedia Commons

Most programmers act like cats, and their “prey” is to implement some functionality, usually with a very hard time constraint along with functional and performance expectations. That “prey” is marked (pointed to) by its manager. In that path they get into dangerous positions, and just like cats, they leave a messy code-base reducing the internal (structural) quality of the product.

Who’s responsible?

The Software Engineer

Some junior, or naïve, software developer can think that the only measure of quality is the functional one. Or they are young enough to never have to maintain a dirty (impossible to maintain) code base. But, as cats, they will only see the prey pointed by their manager or client. It can be a matter of the level of professionalism but if they are not required to write good, maintainable, code, then almost always they won’t.

On the other hand, we have the “crazy scientists” culture saying: “The best developers are mad scientist”. They are disorganized, un-ruled, bad team members, and fast builders.

The Client

Early in my career, I used to think that clients were guilty for not caring about the product (code) quality. They always want faster and cheaper development without thinking about the implications.

Let’s face it, clients will be clients. They only mind their own business. They want our software products to support their processes. And because an industrial mindset, they think that software maintenance is as simple as changing a defective machinery.

Bottom line: stop blaming your client for the lack of quality, look in another direction.

The Manager / CEO / CIO

You have to understand your business. If you are building software and you don’t think that the code (internal) quality is important for your business, better start selling vacuums. If you focus your company and teams only around functional quality and super-fast development you are digging your own grave. In the near future the maintenance cost will drain all your revenues, will demoralize your teams and make your clients angry. If you are lucky enough, your employees and clients will leave you, without any legal implications.

Your clients don’t know anything about software. They’re only interested on the functional quality, and very few of them in performance and security issues. It is your job to create software that meet both the client’s imperative (functional quality), and your business needs (structural quality). You have to mark the target so your cats will get the right prey.

A tool to train your cats: Better Code Hub (https://bettercodehub.com)

The Better Code Hub is a tool to check your code for structural quality issues. It helps you by checking a public GitHub project against a set of ten simple rules:

1. Write Short Units of Code
2. Write Simple Units of Code
3. Write Code Once
4. Keep Unit Interfaces Small
5. Separate Concerns in Modules
6. Couple Architecture Components Loosely
7. Keep Architecture Components Balanced
8. Keep Your Codebase Small
9. Automate Tests
10. Write Clean Code

For small projects it run the analysis in less than a minute. After that, you can check the results and improvement suggestions if you violate some of the principles.


The landing page shows you a grid with all your projects and last analysis summary. Each grid item has ten icons representing the principles above. If they are green you have no problem, if any is not green you can click and see more details about violations.

Better Code Hub landing page

To start you have to do only a few simple steps:
1. Select the project you want to check and click “Analyze”

BCH: Selecting project to analyze

2. Wait for the analysis to complete
3. When done, the page will redirect you to the details page

BCH: Details (summary)

First (prev. image), it will show a summary indicating if some principles have violations. If you click on one, you’ll see the details.

BCH: Details on principle violations

Seeing past results

For already analyzed projects when you want to see again the details of the last analysis just click the “View Results” icon.

Closing thoughts

Managers and developers should seek to improve the structural quality of the product. Clients, especially those outside the software industry, do not care about internal quality. Is our task to seek efficient formulas to run our business in such a way that we can deliver both functional and structural quality ensuring a good profit on the long term. With tools like the Better Code Hub we are a little closer to that goal.

Write BetterCode

The Definition of Done for Product Quality: Improve what Matters with https://bettercodehub.com

Lorenzo Solano Martinez

Written by

Write BetterCode

The Definition of Done for Product Quality: Improve what Matters with https://bettercodehub.com

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade