Comments on: Refactoring Isn’t A Design Methodology

By: ActiveEngine Sensei

ActiveEngine Sensei — Sun, 17 Feb 2008 12:03:16 +0000

You’ve got me thinking about a Y2K remediation gig we did for a national bank. The project lead, whose mantra was “do what is necessary and sufficient”, focused the entire team with a project context diagram and Ganes Sarson process model he did for the 19 systems that passed transactions around. These 2 documents, where we could trace all transactions, became the starting points for all of our tests and validation and test data creation apps we developed. “Read the spec” was the answer when we had questions, as he detailed everything there.

We in turn were responsible for crafting our test plans and specs from that point, and although he had the framework in place we still had analysis to complete. Our four member team built test environments and tested the 19 apps in 6 months. By the end of engagement we had completed over 400 pages of documentation and each of us could pick up each other’s systems. Although we had to specialize, there were no separation of concerns as we had to communicate effectively with each other and the client.

I compare that team to the others I have been involved and I see a vast difference in quality of communication. Sad and scary at the same time.

By: Bill Miller

Bill Miller — Sun, 17 Feb 2008 04:35:56 +0000

I agree “separation of concerns” hasn’t been good for development. It’s been particularly problematic with the project manager role. As I was working my way up through the ranks, a project leader wrote and managed the schedule, wrote the functional spec, lead the engineers, helped develop the designs, reviewed the designs and code, reviewed the test designs, helped debug, and managed the test effort. It was demanding but the amount of control over the schedule and insight it gave you to the pulse of the project was unparalleled. Though on really big projects, you will need to separate the concerns some. Now the resource managers leave managing the schedule to another individual, the project manager, but it’s not as effective because to manage a team well that is on a schedule, you also need to manage the schedule. It can be done, but resource managers also need to see managing to the schedule as their responsibility too, and too often they do not, or not to the degree that they should, in this arrangement.

By: ActiveEngine Sensei

ActiveEngine Sensei — Sat, 16 Feb 2008 14:57:40 +0000

“Separation of concerns” and dividing the duties and assigning the roles of BA / Designer / Tester to different people has not been good for development. I have worked with some extremely talented coders in the past who were very one dimensional, and could not write a spec to save their lives. This begs the question: if you can’t express it, how do you know it’s right? Same thing with testing – the developer should be able to create a series of tests BEFORE they cut a majority of their code, as you should be able to express what the code conforms to as expressed by the spec.

A lot of developers these days will refuse to be BA’s as it takes “too much time away from the work”. Not good.

By: Bill Miller

Bill Miller — Sat, 16 Feb 2008 03:43:34 +0000

In the environments that I’ve developed in, we never had time to do it twice, so it was always in our interest to spend the time to do it right the first time for the sake of the schedule, quality, and money, so if these are the goals for your projects, then you specify all the details that prevent you from doing it twice.

But what’s wrong with having the developer also do the design? This way he is figuring it out for himself. When I first started in this business, the developers wrote the functional specifications, did the design, wrote the unit and acceptance test plans, executed the tests and fixed the bugs. We lost something when we moved to having job titles for each role on the development team.

By: Steve Campbell

Steve Campbell — Fri, 15 Feb 2008 14:15:37 +0000

Let me give a concrete example. I recently designed a reporting system, and I said that there should be the following roles, and I specified how they should interact using a sequence diagram: Report Provider, Data Adapter, Options Provider, Renderer. Now in the final code, there were classes representing each of these, but there was also inheritance, rendering strategies and other classes I had not thought to specify.

If we can agree that the code is never the same as the design, then we can also agree that we can over-design something, i.e. spend too much time specifying intricate details that may be unrealistic.

So why not let the developers figure out those details themselves? They will have immediate feedback when they get it wrong, and if they have the tools of TDD and refactoring, then they can fix their mistakes “on the run”.

By: Bill Miller

Bill Miller — Fri, 15 Feb 2008 04:49:49 +0000

Steve, welcome and thanks for sharing your thoughts. I have difficulty comprehending how doing something new makes it different. For me I find new requires even more rigorous up front design and analysis not less. I can easily write code with little up front design and analysis for something that I understand very well; I struggle to find solutions for things I don’t know very well.

The best way for me to solve problems I don’t understand very well is to understand them better by deep analysis and design. Pen and paper work best for me, but that may have something to do with the technology that I grew up with.

By: Steve Campbell

Steve Campbell — Thu, 14 Feb 2008 17:53:39 +0000

An up-front-design and architecture is a good thing for well-understood problems. But when we are doing something new, a detailed up-front design can be wrong – and therefore dangerous! In many cases, we can more easily discover the best solution via TDD and refactoring.

Regarding safety, Agile proponents know very well that refactoring without extensive supportive testing is a bad idea. They have never suggested or encouraged it.

By: ActiveEngine Sensei

ActiveEngine Sensei — Wed, 30 Jan 2008 00:51:09 +0000

Additionally, TDD stuff should only commence once you have the domain settled, and at that stage your tests are verifying what you established up front. The series of unit tests can serve documentation and a training tool.

There may be the odd occasion where you need to prototype ideas quickly, and TDD can be a very good tool towards the goal of a fast model, but in that case it is a throw away solution.

By: Bill Miller

Bill Miller — Wed, 30 Jan 2008 00:25:39 +0000

You raise a good point. If you have experienced software engineers on the project, they will arrive at a good up front design without much effort, but if you have inexperienced software engineers on the project, you will need some trial and error to arrive at a good solution, thus a greater need for refactoring over many iterations.

By: ActiveEngine Sensei

ActiveEngine Sensei — Tue, 29 Jan 2008 23:24:46 +0000

What strikes me odd about the Agilistas is that if they possess a great deal of expertise, why would they have to make some many passes at a solution, especially since there are a number of existing patterns and techniques to choose from and apply to problems. There are only so many ways to read data from a database. If you the ActiveRecord pattern then you have made some design decisions that have charted a course for you. If the data model is sound and completed, why all the finagling?

For me the questions boils down to the problem domain: How different are your set of problems you need to solve from other domains and what solutions already exist for those domains. Most business apps interact with a database, so there is no reason for a constant refactoring if you let your problem domain solution be driven by databased driven architecture, e.g. ActiveRecord, Business Layer Logic, MVC, etc. You still have to perform CRUD, and therefore you will only have so many permutations of screen development. This makes me believe that you should, for the most part, have an upfront design. Have to do a workflow? Guess you have to have a process model completed first. Again, up front design.