Methods, Not Methodology (3): Knowing Everything at the Beginning?

原创 2013年02月04日 17:14:38

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 automated 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 could 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 book Working Effectively with Legacy Code. Basic idea is if we know we will change a specific code snippet like a method, we could 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 many intelligent IDEs like Intellij and ReSharper, the impact scope could be shown by pressing a short key.

Impact Analysis through OFM (Object Feature Mapping) Diagram.

This is the new method I want to introduce. I've seen domain object diagrams to help to understand the design of software in many 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 diagram to show the relations/mappings between domain objects and features, which would 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 could be coupled with hundreds of features.

Well, a legacy system may lack design so there's no "domain object" at all. But every system would 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

Employee Skills

Employee Locations

Employee Schedules

Project Demand

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 could 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:

Beginning Python From Novice to Professional (3) - 列表操作

列表操作 list函数: >>> list('hello') ['h', 'e', 'l', 'l', 'o']改变列表: >>> x=[1,1,1] >>> x[1]=2 >>> x [1, ...
  • wu20093346
  • wu20093346
  • 2014年11月12日 14:00
  • 833

Methods, Not Methodology (4): Effective Meetings

The ProblemsTwo problems:Even there're already tons of articles and books talking about the meeting ...
  • chelsea
  • chelsea
  • 2013年02月06日 16:47
  • 3796

Programming Methodology(三)

首先是每篇的BUFF时刻,贴上偶像李开复喜欢的一首诗,虽然他最近被黑的蛮惨的,但是在我迷茫的时候看他的经历还是获益匪浅的~ 未选择的路    ----By  Robert Frost 黄色的树...
  • Nirvanao0
  • Nirvanao0
  • 2012年04月09日 22:22
  • 271

Beginning iPhone Development with Swift Exploring the iOS SDK 源代码

  • MIRAGE086
  • MIRAGE086
  • 2014年11月24日 15:56
  • 1251

GTK+ -- from knowing nothing to knowing something (3)

 About layout We usually have more than just one widget on out interface, so using gtk_container_add...
  • ok12345
  • ok12345
  • 2007年07月06日 12:27
  • 372

Codeforces Round #168 (Div. 2)---A. Lights Out

Lights Out time limit per test 2 seconds memory limit per test 256 megabytes inpu...
  • u013446688
  • u013446688
  • 2014年11月03日 13:25
  • 1123

Codeforces-275a D Lights Out

Lights Out time limit per test 2 seconds memory limit per test 256 megabytes Lenny is playing a ...
  • u012325552
  • u012325552
  • 2014年03月18日 12:59
  • 1098

Methods, Not Methodology (I): Validated Code Review

See Also: AntiPattern: Batch Code ReviewCode review, specially daily code review, is considered a go...
  • chelsea
  • chelsea
  • 2013年01月27日 20:58
  • 3901

A. Lights Out

time limit per test 2 seconds memory limit per test 256 megabytes input standard input ...
  • jj12345jj198999
  • jj12345jj198999
  • 2013年03月22日 21:21
  • 1097


按照SOAPpy安装文档说明,事先安装了fpconst-0.7.2和PyXML-0.8.4,但执行"python install"时报了以下错误:Traceback (most re...
  • kungbx
  • kungbx
  • 2010年06月18日 11:18
  • 2180
您举报文章:Methods, Not Methodology (3): Knowing Everything at the Beginning?