What are some ways to compare and contrast software architecture strategies?

Question

I am currently working on an Android project that I have concluded needs refactoring done for a core part of the app experience. Let's call this part of the experience "Search".

From looking at bug reports, static analysis tools, and the code itself, Search should be prioritized in the refactoring.

Since Search is a core component, I want to propose to my business that we refactor using TDD principles. This would require rewriting the Search part of the app to take advantage of TDD.

A few team members have asked for a comparison between the existing code architecture, and the one I'd like to propose. They essentially want me to prove that my new approach will benefit the project.

I haven't had to go into deep detail on a comparison like this before, and I'm not sure what the best way to go about it is.

Beyond static analysis and just UML modeling, are there other ways of showing the advantages or disadvantages of software architecture?

Answer 1

Proof is way too far. You aren't a researcher. You're a code monkey. What you need is their confidence.

You can gain it through politics. A strategy that works sometimes despite my personal hatred of it. You can gain it through a minimal demonstration of what this can achieve. You can gain it by sneaking in some weekend and writing heroic code that converts it all over before they know what's happening.

Of the three I recommend the minimal demonstration. This is the one that gets the team to buy in. Most of your effort here won't be about the code. It will be about changing a culture. Show that you're ready to defend these ideas against brutal skeptics who hate learning anything that may come between them and going home on time.

Much as I'd personally love to do option three I know it doesn't work in the long run. Even if you fired everyone and brought in a new crew who'd only ever seen the code base in TDD mode you'd still run into trouble with people just not bothering and not understanding.

TDD doesn't really work when it's done half hearted. You need to give people a reason to care and believe in it. Because it can fail horribly when they don't. Since this isn't a religion that means a good enthusiastic demo.

You need to honestly show them the problems TDD can cause. The pitfalls and wrong headed ways of pretending to follow it. Do that and they'll be less likely to think of you as a snake oil salesman.

One of the myths is that TDD frees you of needing to design. No. TDD forces architectural changes that can only improve a design but those changes shouldn't be the end of design. TDD gives you tests that let you paint yourself into corner and paint your way back out without sawing a hole in the wall. A flexible design attitude means the code base will reflect the best wisdom of today. Not yesterday.

The sad truth is not much is going to line up personally with you business goals. What you should show is how much easier it is to react to changing goals when you have good tests.

This isn't something you should let them see you struggling with. Practice the transformations and refactoring that you're going to perform. Treat this like a job interview. You really need to be on form for this.

Or you can do option four. Add tests whenever you can sneak them in and hope that someday someone will care about maintaining them besides you. I've seen this tried many times. It doesn't work out and the doubters just end up more convinced that they were right all along.