Analyze Mercilessly

A generalization of RefactorMercilessly, acknowledging that code is not the only representation medium in software development, and that (code) refactoring is essentially applied analysis.

There are two times one can analyze: before and after the analyte is present. So there are two techniques to chose from when "analyzing".

Describe those that happen before as RequirementsAnalysis. This implies all need discovery up to AcceptanceTest definitions.

DriveByAnalysis is when you use the opposite technique by mistake.

CodeAnalysis? is when you read the code and draw diagrams with it. What better time could there be to document the shape of an app than when you have a working product to examine?

I find documentation of working code quite useful. I can convey what dozens of objects are doing with just a couple of pages of diagrams and some text. Sure, I could tell everyone to sit down and study the code, but why? At least the people I usually deal with understand a lot faster and a lot more when I explain with pictures and English (see spot run :).

Do people really find it easier to get a basic understanding of what code is doing by reading through the function/message/method calls rather than having it explained to you with diagrams and good old-fashioned English? Note that when I say diagrams, I don't explicitly mean UML diagrams. I mean whatever I can draw up to explain the meaning to my audience easily. -- GeorgeGruschow

For me, once I understand the SystemMetaphor of a project, I have enough. I think SystemMetaphor is somehow related to MeaningfulNames. -- ShaeErisson

What would be nice would be another level of abstraction that people could read to get a grasp of the structure of the system. English and diagrams work a lot better at this than any other methodology I've seen so far, but I haven't seen so much. Also, implied here is that the new level is smaller than the previous level, unlike UML which in my experiences teeters towards TheAlmightyThud. And by smaller, much smaller would be appreciated. Just the essentials... A pointer in the right direction. -- SunirShah

Sunir, I think what you're describing is the much wished for and always elusive "architectural" view.

Actually, I started this page hoping it would become a discussion of analysis techniques not bound to code analysis and refactoring. It's taking more of a direction toward abstraction. To me, analysis and abstraction are almost opposite in meaning. I prefer the classical definitions. How 'bout you? -- WaldenMathews

I don't believe in analysis in the same way I don't believe in abstraction. AllAbstractionsLie after all; not to say I don't abstract like a rabid mathematician. I just do the job doing whatever I have to as simply as I can. Analysis is a methodology and all methodology is crap. In the sense that it comes as some sort of packaged idea of "this is how you solve the problem," when often the best way to solve the problem is to do what you obviously need to do next. Maybe programming like that is a greedy algorithm. Of course, my resume claims I'm into OOAD although I don't analyze nor design in the methodology senses of those words.

Anyway (requirements) analysis to me roughly maps onto "talk to the customer to find out what you're supposed to do." I don't think it really has to be much more complicated than asking a question to clarify a problem or by demonstrating a handful of solutions and asking the customer to pick one. Sometimes you can be clever by doing research on your own, but it's basically comes down to gaining direction. Once you know how to create value for the customer, the rest is an exercise for the reader. Er, programmer/analyst. -- SunirShah

Sunir, does "not believing in" analysis and abstraction mean you don't believe they exist, or you don't believe they add value to what you do?

How do you know when you are doing a job "as simply as you can"? What if 'analysis' is not a 'methodology'? What if, instead, it is just a fundamental unit of mental process that occurs every time you separate things in order to better understand them? Why do you assume 'analysis' means 'requirements analysis'? Your comment about asking a question to clarify a problem seems right on target to me. But doesn't the complicated-ness of that depend on how much of a mess of a problem was handed you? Thanks, -- WaldenMathews

Well, a lot of what I said was flippant and tongue in cheek, so bear with me. Point by point:

I don't "believe in" the methodologists who sell me that I need more abstraction/analysis. I don't see how I could use more of either as I get the job done well.
You can never really do a job "as simply as possible," or at least know that you have. You can only make things simpler whenever possible. I know when something is simple when I can understand it. If I can't understand it, it's too complicated. Simple, eh?
Analysis separated from methodology is definitely a necessary part of solving the problem because it's the part that identifies the question.
re: Requirements analysis. It's just that I don't like code analysis, so I didn't mention it. Code analysis doesn't get me anywhere or solve any problem that I have. I tend to do it for the "bragging rights" of saying, "Hey, I built this meatball spaghetti," or I pounded out 2000 lines of code today, or I've written 25% of the classes in the system in 6% of the code (true statistic; as I said, I abstract like a rabid mathematician). Metrics are answers without a question. Diagrams are useful, but mostly for communication between people during meetings or in broad overview documentation

By the way, the need for overview documentation indicates failure in design as the system obviously isn't simple enough to understand. Or so I feel. Some systems are just necessarily massively huge and as yet I haven't been involved with them in any significant role. -- SunirShah

CategoryAnalysis