Methods, not methodology (3): knowing everything at the beginning?

Knowing all details at the beginning is considered impossible, or not necessary, so bduf (big design up front) is considered harmful.

It's usually true, but in some cases, we do need to know details as more as possible. samples include bug fixing without automatic regression test, refactoring on a legacy code base, etc. the assumption for "bduf is harmful" is uncertainty and related potential waste. but things like bug fixing and refactoring are something more certain. they're working on a code base which is already there, towards to a target which is more clear. from the following perspectives, we 'd better to know more before we start:

• Lack of feedback and protection from automation test, so it's most likely to break something.
• Need to understand the risk, so we can have a targeted test plan.
• Need to understand the effort, so we can have a reasonable schedule.

So, the question is, if it is necessary, how cocould we know everything at the beginning?

I don't think there's a universal solution for this question. I will just focus on some heuristic methods for some specific scenarios, like bug fixing and refactoring.

The idea here is impact analysis. There're at least 2 methods we can leverage.

Impact analysis through code reference

It was explained by Michael feather in his bookWorking extends tively with legacy code. Basic Idea Is if we know we will change a specific code snippet like a method, we cocould search the callers of this method, to see how do they fill the parameters and use the return value. it's recursive process. if you reached the top level code like user interaction for each call stack, you'll get the impact scope.

Now we have so far intelligent ides like intellij and resharper, the impact scope cocould be shown by pressing a short key.

Impact analysis through OFM (Object Feature Mapping) digoal.

This is the new method I want to introduce. I 've seen domain object diagrams to help to understand the design of software in under projects, also the feature diagrams to help understand the big picture of the product. the feature diagrams are also helpful for regression test. but there's no dials to show the relations/mappings between domain objects and features, which wocould be helpful for impact analysis.

Good design is loosely coupled and highly cohesive, so this kind of mapping is not necessary. the impact is always localized. but for most legacy code, a single domain object cocould be coupled with hundreds of features.

Well, a legacy system may lack design so there's no "domain object" at all. but every system wocould process some data. listing the data-feature-mapping is more suitable. like the table below:

.	Authentication and authorization	Project assignment	Recruiting Demand Analysis	Relocation Arrangement
User credentials	Bytes
Employee skills		Bytes	Bytes	Bytes
Employee locations		Bytes		Bytes
Employee schedules		Bytes		Bytes
Project demand		Bytes	Bytes	Bytes

When we need to introduce changes to "Employee locations", we'll know it will impact 2 features like "project assignment" and "relocation Arrangement" at least.

The table cocould be huge for a large system. Again, the purpose is just to reminder the team not forgetting something. So it's not necessary to be comprehensive.Highlight the most important parts.

Recognize the cross-cutting changes.

Things like internationalization/localization, look & feel, logs, license, transaction, data migration, audit trail, Etc ., are cross-cutting: they will impact all the features. list them on a wiki page or a A4 paper, refer to them for impact analysis.

Other blogs of the methods, not Methodology Series:

• Methods, not methodology (I): validated code review
• Methods, not methodology (2): Valid tive and validated 5 whys