Non-Technical Founder’s Guide to Reviewing Healthcare Developer Code

Every non-technical founder must ideally do a code review for their healthcare app.

Even if you’re a technical founder, we recommend getting the code reviewed by an expert. With the age of AI, code review has become much more easier. A non-technical founder can leverage OpenAI code interpreter to review codes of healthcare applications. The idea is that you might have a healthcare application that works great and passes all kinds of acceptance tests, but is built in such a way that future maintenance and enhancements will be difficult or costly. Also, ‘To err is human’. So!

A code review has several benefits that can’t be overlooked:

• Improved code quality
• Fewer defects in code
• Improved communication about code content
• Shorter development/test cycles
• Reduced impact on technical support
• More user satisfaction
• More maintainable code

Tips on how a non-technical founder can review healthcare app code

#1 Know what is a code review in healthcare apps?

Modern healthcare app code review is defined as a form of code inspection which has the qualities of being informal, tool-based, and frequent. The most well-known engineering organizations today – Microsoft, Google, and Facebook, typically participate in a modern code review and also advocate this practice.

The goal is to make the project better, faster, and more secure through bulletproof code. By doing a code review you can ensure your current healthcare app architecture is built to last and will be low on maintenance. Here are a few steps:

Step 1: You need not go through the lines of code, but test the functionality of the code written.

Step 2: If the healthcare app code is giving you the desired results, have some of the tweaks listed, like option A and B for the same functionality, and get the answers from your healthcare app developers.

Step 3: Ask for the iteration time and effort if the functionality needs to be tweaked in the future.

And just to clarify, healthcare app code review is not the same thing as app testing. Here’s what you need to know about mobile app testing if you are building a medical app.

#2 Review early

IBM’s 500,000 line Orbit project used 11 levels of inspections. It was delivered early and had only about 1% of the errors that would normally be expected.

The earlier you solve a problem the lesser it will cost you. If you build on top of a bad foundation then you might get away with it for a while but ultimately you’ll have to rework and start again. Have clear communication with your healthcare app developers about what you are aiming to achieve.

This doesn’t mean the developer is not doing his job properly, but there are chances of miscommunication leading to a fragile healthcare app development process.

At Arkenea, we encourage the culture of healthy communication between the healthcare app developers and the founders.

The sooner you can discover potential problems, the better it is. As your project begins, set off the most warning flags during its initial phase.

#3 Define a method

Usually, the healthcare app developers follow lightweight code review techniques, as distinct from formal inspections. These inspections can be divided into the following types:

• Pair programming
• Over-the-shoulder inspections
• Email pass-around inspections
• Tool-assigned code review

But you don’t need to be a part of these techniques. In fact, you should define your method for getting involved in a code review. Here are a few suggestions which we follow at Arkenea:

• Daily stand-ups with healthcare app developers on Skype and tele.
• Weekly status report published and sent via email/project management tool.
• Monthly steering meeting with high-level stakeholders.

#4 Set a checklist

Come in with your checklist which satisfies the business quotients.

Having a checklist as a starting point will help you avoid inconsistent code review quality.

The list can include things like checking if the healthcare app code is documented appropriately, that it’s following your company’s code guidelines (or language’s general style guide), that features are covered with tests, that there is no code duplication, etc. It’s best to have that document available and used by the entire development team.

#5 Be an observer

Fun fact: Whenever a non-technical boss shows up, the tech team spend more time explaining things to him than reviewing the code.

Don’t be that boss.

If you are participating in the code review then make sure you strictly know your role, i.e. of an observer.

When the developers are discussing or explaining the healthcare app code, you need to be passive. Take notes of your observations and ask relevant questions which can be helpful in improving the outcome of the app’s code.

#6 Design review is not the code review

Make the discussion about the healthcare application code.

There are two separate teams – developers and the designers. A code review is strictly about reviewing the functionality of the healthcare app and not the design. If you need to learn anything on the design side, this is the right place.

Don’t make the code review a design review, so don’t criticize the design (unless it’s flawed and will absolutely not work.)

#7 Time your healthcare app code review

Never review healthcare app code for more than 90 minutes at a stretch. The effectiveness of your review decreases after around an hour.

The Cisco study showed that for optimal effectiveness, developers should review fewer than 200-400 lines of code (LOC) at a time. Beyond that, the ability to find defects diminishes. At this rate, with the review spread over no more than 60–90 minutes, you should get a 70–90% yield. In other words, if 10 defects existed, you’d find 7 to 9 of them.

If you need more time, break it into multiple reviews.

#8 Set a few tangible goals

It’s best to be specific with your review meetings, for instance, “reduce app loading time by 30%” or “reduce the sign-up options” instead of saying, “improve app retention rates.”

Establish quantifiable goals for code review, and capture metrics so you can improve the outcome.

As with any project, decide in advance on the goals of the code review process and how you will measure its effectiveness. When you’ve defined specific goals, you will be able to judge whether code review is truly achieving the results that you require.

#9 It’s OK to say “It’s all good”

Don’t get picky, you don’t have to find an issue in every review. There will be times when your tech team will be working flawless, as per your expectations. The idea is to achieve results, fast. So, you can wrap up some reviews in few minutes so that the tech team can get back to work.

Also, metrics should never be used to single out healthcare app developers, this practice can seriously damage morale.

Remember, it is about reviewing the code, not the authors of the code.

#10 Make sure the review is fruitful

Seems like a no-brainer. But still!

If you’re going to get into all the trouble of reviewing the code to find bugs, it certainly makes sense to fix them all!

A good way to ensure that all the defects are fixed before the code proceeds to the testing stage is you having an “All Clear” sign for your checklist.

Want maintainable code that ships quickly? Get in touch with us.