Fear of Change is a Code Smell!

[swatts]

Hello Darlings,

Just seen the first lot of GDevCon videos and boy oh boy do they look professional. We (GDevCon Team) view professional videos as an important reward for presenting and pay quite a lot for Louis to do them for us.

Go check them out here, they will be available shortly.

Anyways something has been bothering me and it's another software engineering trope that I'd like to pick at....

You MUST provide a full set of requirements and changes later on are terrible, expensive and will cause over-runs!

I think this is an old-fashioned and unrealistic view, it also tells us something about the fragility of an architecture/framework or design.

In the real world you will not be provided with a full set of requirements, and any requirements you do get will very likely change. The best you can hope for is an overview and the most you can do is try and understand the problem your customer wants to solve.

If you accept my argument then you probably will agree that a good architecture addresses (even embraces) this reality. I'm not going to advocate a particular framework, architecture or design here, but I will give you a catchy phrase to help you evaluate them.

Fear of Change is a Code Smell!

Ideally change can be something you can configure, or something you can add. Also it will affect a small and limited area of your code. Small changes should only take a small amount of time and have a small amount of impact. The existing codebase should not unduly affect the work required to make the change. 

Here Endeth the sermon

If you like my articles you may want to spend a day in the company of Fabiola De la Cueva, Joerg Hampel and I, we will be reprising our DSH Workshop at NIDays Europe, check it out here http://dsh-workshops.com/. Where else can you hear from 3 different companies experiences (>60 years in the industry), 2 published authors, 3 LabVIEW CLAs and Champions. It's a bargain!

Lots of Love

[Taggart]

Excellent post Steve!

[Taggart]

You would have liked Sarah Zaluskys opening keynote at the CLA Summit.

She defined Legacy Code as code that people are afraid to change.

[swatts]

I'd like to see it, has it been filmed?

[cbutcher]

Jim Kring wrote on LinkedIn that the presentations were filmed and should be available on the wiki "eventually". No idea what timescale that means.

[Jacobson-ni]

---

@swatts wrote:

Ideally change can be something you can configure, or something you can add. Also it will affect a small and limited area of your code. Small changes should only take a small amount of time and have a small amount of impact. The existing codebase should not unduly affect the work required to make the change. 

---

I've been trying to read more on software design recently and your post reminded me of some things I've been reading. One interesting paper was "On the criteria to be used in decomposing systems into modules" which discusses how to break up a simple application two ways and concludes:

---

... it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions that are likely to change. Each module is then designed to hide such a decision from the others.

---

Also, if you need another catchphrase, one I remember from the pragmatic programmer is "Put Abstractions in Code, Details in Metadata".

[swatts]

You're reading good papers there Parnas is always worth some time.

[Intaris]

Regularly checking the Youtube link for videos of GDevCon #2....

[swatts]

We have them (as of yesterday), just checking through them now. From what I've seen they put Ted talks to shame!

[FabiolaDelaCueva]

Steve,

Excellent post as always.

This is why I focus on making code testable and unit tests. This is the way I can measure the impact changes have on the code. One of the large projects we work on, we had to make major changes to the database module. The LabVIEW developer in charge of that daunting task told me: "The only reason I am willing to take on that large refactoring project is that we have plenty of well defined and working unit tests". It was still a daunting task but two things were important:

1) He knew with a good degree of certainty that the new code  worked the same as the old code

2) He knew when he was done: All unit tests passed! 

Thanks for sharing your thoughts and wisdom with us.

Regards,

Fab