loading...
Coherent Logic Limited

"How would you assess the condition of a given software project?"

thospfuller profile image Thomas P. Fuller Updated on ・3 min read

Reposted from LinkedIn -- feel free to add your thoughts below, or on LinkedIn. And feel free to send me an invitation to connect, if you'd like to network.

"How would you assess the condition of a given software project?"

I had a question like this come up from an acquaintance recently and my brief answer is below. Questions like this require establishing a view of the condition of the project at both high and low levels and will require, to start, a conversation with #management . Some questions that may come up include:
πŸ”Ž Does the #application work?
πŸ”Ž Is it experiencing any strange behavior?
πŸ”Ž Does the application perform well and consistently?
πŸ”Ž What's the attrition rate look like on the team?
πŸ”Ž Are bugs rampant?
πŸ”Ž How often do the #developer s deliver new releases?
πŸ”Ž How frequently do crises occur?
πŸ”Ž How long has the project been in #development?
πŸ”Ž If the app hosts sensitive #data: Have you ever run a #security audit? pentesting / penetrationtesting
πŸ”Ž Is your application properly covered by web analytics software such as Google Analytics?

Next steps will be to review the code at which point I may need to speak with the developers. During this effort questions will need to be answered and a brief list is included here:

πŸ”Ž Is the application architecture correct?
πŸ”Ž Are the dependencies relatively current or are they outdated?
πŸ”Ž Is the development based on any non-standard practices?
πŸ”Ž Does the source code make use of multithreading explicitly? If yes, is there a good reason for this?
πŸ”Ž Are problems being solved by inventing solutions where an established open-source alternative exists?
πŸ”Ž Does the application experience memory leaks?
πŸ”Ž Is there automated testing in place? Including unit, integration, performance, security, front-end testing (where appropriate)
πŸ”Ž How does one scale the application?
πŸ”Ž Is there CI/CD in place? How are released handled?
πŸ”Ž What is the development methodology for this project?
πŸ”Ž Are there scheduled restarts of the application to prevent problems from arising?

This list can get to be quite long and hence it will not be developed quickly but when we're finished with it we should have a pretty good idea what the current condition of a given software project is.

Do you agree with this approach? If not, how would you do this?

Questions and comments are welcome.

🎯 Note that I am currently #available for #consulting engagements.

Posted on Jun 4 by:

thospfuller profile

Thomas P. Fuller

@thospfuller

I am a hands-on technical consultant w. a focus on cloud application development (specifically AWS) & product development and my goal is to help technical leadership deliver better software.

Coherent Logic Limited

Coherent Logic is a software engineering and data analytics consultancy based in McLean, VA USA.

Discussion

markdown guide
 

Stealing completely from the book "Accelerate", the four key metrics they emphasise (based on their research) are:

  • MTTR (Mean Time To Recovery)
  • Deployment frequency
  • Change failure rate
  • Cycle time

Technically, these are leading measures for success of software delivery performance, but given software applications are the output from this process, I think they'd be a pretty reliable proxy for software application health.

 

As a developer I like to know a few things.

  1. How many manual steps are there in the life cycle of a feature to deploy not related to coding. Logging on to a machine to run 3-5 shell scripts is not fun.
  2. How long on average does a small change take to go through idea to production. If it takes 2 weeks that's probably not good. However, 2 minutes is also not good.
  3. How many people need to be involved in an update. 16 people from 8 teams is too much. But if I am expected to do it all myself without reviews that's also not good.
  4. Also checking code quality and practices but that is more specific.
  5. Last but not least, how well is the team working together. I do not care much about following agile or scrum or any other buzz words. I just want to know if they communicate and mesh well. No internal disputes, no issues with management, everyone is working that sort of stuff. Odds are, if anything is wrong with the team, it is reflected in the project.
 

These are all excellent and thanks for sharing.

 

Just from the top of my head, here are some of my notes. Hope they are in any way helpful

  1. "Is the application architecture correct?" - I think this question should be rewritten as "correct architecture" doesn't mean anything specific, as there is no one correct architecture. What about something like: Does the architecture fit our needs for scaling, maintainability, reliability and further extension of functionality?

  2. As a QA, I would ask:
    a) how often serious or blocking issues in production occur and how fast are they handled? Is fixing issues in production delaying new development?
    b) are there any manual steps needed to deploy/release the software or fix issues? Similar to this: how long is the tech dept backlog and how fast is it growing or decreasing compared to new development?
    c) how often a release date is moved because of delays? In agile: how often work items are dropped or added to an ongoing sprint?
    d) how many issues are caught on each stage of SDLC? There should be as little as possible caught after the implementation/code review stage and almost nothing in prod... but if no issues are found after implementation stage, something might not be right as that might mean issues are "hidden" or "swallowed" in the code, especially if users complain but we can't see or reproduce the issues. This is related to logging and monitoring
    e) how long does it take to run automation? Are there quality gates setup, example: pre-commit hooks running unit tests and/or code analysis?

 

Re 1.) I disagree as there are plenty of wrong architectures and unfortunately once a bad decision at that level has been made it can be very hard to fix. You do get to the meat of the matter though when you said:

"Does the architecture fit our needs for scaling, maintainability, reliability and further extension of functionality?"

which I do agree with. These are good high-level questions but we still need to see what the overall architecture looks like and make sure that it makes sense. In my experience if a project is borked it's going to have a slew of problems, both low-level and likely high-level, including possibly the architecture.

Here's a made-up example conversation to help drive the point home:

"What's this Custom Cache project?"

"Oh we need to scale so we wrote our own caching solution."

This is probably a red flag as caching is a difficult subject and there are plenty of solutions available that do exactly this. Also if management indicates that there's no chance this application will ever need to scale and this custom caching code has tied in all over the app(s) in a way which aren't going to be easy to disable or remove completely, then we likely have an architecture-level problem.