4

Currently I'm on a project where my objective is to obtain the best code quality.

We have unit, integration & e2e testing. The e2e tests are written by the Business team in cucumber and these tests are the final condition to achieve the end of a user story. Also, all features must have the metrics that we want to change. I added mutation tests also, and we have near 100% of the mutants killed (so, we also have 100% of coverage).

We established the most restrictive rules in Sonar, and all our code has A grade. We also have stress tests and we are confortable with the results.

I'm really proud of this project, and yes, having this level of quality really helps to have security of our product, and now we develop faster than ever.

Currently we are a 4 dev team plus me as a dev/team leader. We do code reviews with 1 approve from a team member and another approve from a developer of other team to get a new perspective & check if our business code is understandable.

For hotfixes we don't expect approves because... it is a hotfix and sometimes the delivery time is critical. We didn't have this kind of issue in the last 2 months, when we established this policy of quality first, not only in code but also in the feature definition step.

We came from a feature-first environment and after these changes the business/product team can see the increment of costumer approvals because we reduced the bugs to almost-zero.

So... what is the next step to achieve uber-quality?

Improve this question
7
  • 7
    Well, let's see. Unit tests? Check. Integration tests? Check. e2e tests written in cucumber? Check. 100% code coverage? Check. The only thing left to do is crack open a beer. Then maintain this application for the next 10 years and the annoying parts to maintain are the things you can improve. Commented Jul 4, 2021 at 0:34
  • 4
    What is next uber-quality step? For hotfixes we don't expect approves because. Been there, seen that. I hope y'all get a pile of pain due to no code review just so you learn the lesson. You could do pair programming for hot fixes, personally I'd be Ok with formally calling that the 1st code review. Commented Jul 4, 2021 at 20:55
  • I always get the most senior developer to review or to pair program with to do hot fixes with. Commented Jul 4, 2021 at 21:23
  • 1
    You might find this article on how the Space Shuttle software was written interesting - fastcompany.com/28121/they-write-right-stuff Commented Jul 6, 2021 at 1:59
  • 1
    For hotfixes we don't expect approves because... it is a hotfix and sometimes the delivery time is critical. If it's important enough to do a hotfix, it's important enough to make sure you get it right. The worst thing you can do when time is critical is abandon your development process - pushing code changes through with management pressuring to get things done quickly makes it extremely likely bad code gets pushed through and you make things worse. When things are crazy - SLOW DOWN. Get it right - and verify you got it right. As @radarbob said - been there, done that. Commented Jul 6, 2021 at 10:01

3 Answers 3

Reset to default
12

What I didn't hear you mention was peer reviews.

You did say 'we' a lot. So I assume this is a team. The best use of a team is to check that you're not simply deluding yourself about how awesome you are.

Peer review production code. Peer review test code. The best way to see if you have written readable code is to have someone else read it. Let's do better then just keeping the CPU happy.

Also, you seem almost too enthusiastic about code quality. While code quality is certainly a good thing, it's easy to do bad things in it's name. Guard against this by sanity checking. Watch out for tests that take time to create but don't really help you find defects any faster. Watch out for tests that impose a structure on your code (perhaps by digging behind abstractions) and make refactoring harder.

Don't depend too highly on analysis tools either. I'll take the subjective but considered opinion of a human reviewer over what some tool says about readability any day. Use the tools to remind you of things to consider. Do not worship them as gods. They are good tools but poor masters.

And above all. Don't forget that the point is to get a job done.

————

Regarding your hot fix edit, when time is critical you can avoid time eating formal peer reviews by peer checking and pair programming. Two people sitting at one keyboard can accomplish a lot. (It's tough with covid still running around. Please get vaccinated). When you can't truly pair program then grab someone as soon as you have working code to show off and get their eyes on it. Let them sit in your chair and get their input. That's a peer check.

Even if the place is on fire there's still time to move safely.

Improve this answer
4
  • 1
    Thank you for your comment! I edited the message adding some more info, but yes, we do code reviews not only internally but also with external members from another teams to avoid a eco chamber. Also, the feedback was 'I want this in my team'. I'm too enthusiastic because I feel that this is the first time that I am really confident with our work. I loved your phrase 'Do not worship them as gods. They are good tools but poor masters'. I'm gonna share your answer with the team to be aware about this, specially the 'Watch out for tests that...' part. Thank you again for your time! 😊 Commented Jul 4, 2021 at 3:40
  • 1
    @Imaky glad something landed. Also, peer testing. Coders communicate best with code. So when a coder see's something wrong let them write their own unit test against your code to show you what they mean. I've seen confusion between team members resolved this way. Commented Jul 4, 2021 at 12:47
  • 2
    Very related to this answer: WTF Per Minute - An Actual Measurement for Code Quality. Commented Jul 4, 2021 at 14:09
  • 1
    @GregBurghardt That is not what WTF stands for. But yes. That remains the best code quality measurement in our field. Which is kinda sad. All those books and research papers and a cartoonist gave us better advice. Commented Jul 4, 2021 at 23:10
5

You describe many technical solutions so I think you have that bit covered. The next step would be to consider some broader questions like

  • What is quality?
  • To whom is this quality?
  • Is it important to them?
  • Why is it important to them?
  • Do they really want to pay for it? Less or more than they are now?
  • Would they rather pay for something else?
  • Do we collect statistical evidence of quality, as defined by the customer?
  • When we address problems, are we making local fixes or large system-wide changes like adjusting the organisational hierarchy to prevent entire classes of problems?
  • Do we believe the people we have hired are the key to quality?
  • Are the people working for us happy to do so? How do we know? How soon will we find out if someone is no longer happy and afraid to say so?
  • If the economy goes down the toilet, what expenses do we scale down to maintain the people we have hired?
  • Are we able to continually reduce costs and prices due to quality improvements?
  • Are we chasing ghosts sometimes? Or do we only take action on real problems?
  • What are threats to our current level of quality?
  • How do we Institute a culture that ensures quality 3 years from now? 5? 10?
  • is our level of quality constrained to the code, or do we have high quality relations with the customer too? How do we know? What is the biggest point of improvement in customer relations?
  • Is our documentation high quality? Installation instructions, user guides?
  • Do we have high quality in our relationships with our suppliers? How do we know? What's the biggest point of improvement?
  • If we run into trouble with one of our suppliers, will our quality be affected? How can we avoid that?

There's a huge amount of literature on quality control. Much of it is from the 1960's or before, but it's just as important today. Deming's 14 points and deadly diseases are a good start, but I'd recommend continuing with his book Out of the Crisis, following whatever references you like (Shewhart, Juran, Taiichi Ohno, Reinertsen, Wheeler, a little depending on where you want to start.)

The general principles are:

  • Consider not just the code, but the entire system around it (rest of your organisation, your competitors, suppliers, customers, regulations and standards, and relations between the above.) Make fixes where they are the most effective, not where they are most convenient.
  • Use statistics to tease out signal from noise. Overinterpreting noise is a great quality killer.
  • Adopt an experimental mindset throughout the entire organisation. Establish hypotheses, try them out, adjust based on results. This goes especially for the highest management. (See above about statistics.)
Improve this answer
0

Performance tests.

Let's assume with all your tests the code is defect free.

Congrats, but tbh defect free code is expected! Not by developers sure, but generally speaking.

The thing to do for quality code is to make it run in as small a memory, cpu and time constraint as you can.

Given the comments I thought I would add this: I'm not knocking readable, but it's a very vague measure compared to "how fast does it run?"

enter image description here

Improve this answer
6
  • 1
    I'm more confortable with the idea that readability is superior to performance in a normal context (not a cpu-intensive or realtime processing). Currently with 1 developer hour we can pay a t4g.small instance for one fully month. Also, we do stress tests to check if aws instances grows as expected without degrading the costumer experience. But thanks for your comment! Commented Jul 6, 2021 at 1:36
  • It's nice when you can have both but given a choice between readable code and performant code I'll take readable every time. Why? Because making readable as performant as needed is easy. Making performant code as readable as needed is not. Commented Jul 6, 2021 at 3:37
  • At the end, we work in a business, and 1 hour of developing is more cheap than 1 hour of hardware. Crafting readable code is cheaper than adding more processing nodes. Is a economic decision.... Sorry if I'm talking weird, but english is not my native language. In spanish, this sounds better :P Commented Jul 6, 2021 at 4:39
  • the equation for hardware costs can change quickly as you scale and performance is a tricky thing. If you have finished code and a competitor that runs faster, smoother more cheaply. which is the best? Commented Jul 6, 2021 at 14:30
  • 1
    @imaky you sound fine to me and you're singing my song. Performance is a business decision. Commented Jul 6, 2021 at 19:55

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.