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?

  • How about detailed code examples, before and after? – Robert Harvey May 31 '17 at 1:53
  • I'm not sure UML provides much in the way of value by itself, especially when developers get hung up on class names (this happens more often than I care to admit). If this were my team, I'd like you to explain the complexity of the domain and the bugs encountered, and show how classes of those problems (not single instances) would go away. I've been in a lot of meetings where developers present solutions that I'm not keen on until they explain entire classes of problems that have plagued us go away forever. Then I'm sold. – mgw854 May 31 '17 at 2:17
  • 3
    TDD is not an architecture, it is a development methodology. If you are trying to sell a new approach, I suggest you make a list of existing "pain points" and show how the new approach will address them. – John Wu May 31 '17 at 2:40
  • Sure you mean "TDD" and not "automatic tests"? – Doc Brown May 31 '17 at 4:35
  • All great comments, thanks. I do mean TDD as it will inform the architecture approach we take moving forward. – Ryan Simon May 31 '17 at 5:58

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.

  • I'm trying to position this TDD approach as advantageous for the business because the app is part of a long term customer acquisition strategy. The business needs to be able to move quickly and TDD will provide the confidence we need to do so. – Ryan Simon May 31 '17 at 16:14
  • TDD can do that but there is no guarantee. It's not something people can just suddenly do well. They need time and a safe place to practice before doing the real thing. Or you'll end up with a pile of brittle tests that lock you down to a single implementation even worse than before. – candied_orange May 31 '17 at 16:23
  • Really great point. I'm the lead developer on the project, so I guess it'll be on me to make sure that doesn't happen. – Ryan Simon May 31 '17 at 16:26
  • At first it will but take lead developer as something to grow out of. You want every member of the team to care about and watch for this. I've told teams to ignore my status as lead developer precisely because I want them questioning me and challenging me just as much as any other developer. – candied_orange May 31 '17 at 16:34
  • I definitely agree with what you're saying. Every team member needs to own a part of the project. The real challenge like you mentioned is doing TDD right and getting everyone on board for it. – Ryan Simon May 31 '17 at 16:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.