
Software design is also about relationships - KentBeck
https://medium.com/@kentbeck_7670/software-design-is-human-relationships-part-3-of-3-changers-changers-20eeac7846e0
======
hermitdev
One thing I think that is largely ommited is that it's also a relationship
with people you have not and may never meet.

Join a new company and pick legacy code from a developer that has departed,
personally I cannot help but form opinions of them. "This guy was brilliant",
"this guy is a moron", "this guy way over engineered this, and it should be
like 2/3 the size. Also why 1000 character line statements?", "why do we have
3 separate caches in the server for the same data along with why does that
server have to broadcast a multicast update over the network to update the
other caches?". I could go on, but this a sample.

~~~
munchbunny
When I look at code that makes me think "why would anyone do it this way?" I
remind myself: the programmer who touched this before me very likely had
plenty of thoughts about fixing this code, but they probably had good reasons
for not getting around to it.

That's certainly true of some less than stellar code I've left behind. It's
not for lack of desire to improve it. It's from (1) having written code
against a different set of requirements than what they eventually became, and
(2) it ain't broke and I have plenty of stuff that _is_ broken.

~~~
trm42
One of the things I’ve personally learned and been touting it ever since, is
that it’s ok not to make perfect code in a hurry or when the real target is
somewhere else, if the crude method solves the problem for long enough and is
capsulated well enough and the intent of the crude solution is documented and
it has tests. Documenting the intent is useful for the next programmer to
understand, why the solution has been enough for the needs then and to quiet
the DailyWtFs for the next guy poking the code.

By crude solution I mean half-hardcoded or not well generalized methods as the
other cases are coming in a year or so. This is also a way to limit the scope
and to achieve deadlines. What this means though, is that when new needs arise
we need to go ba k and make them better later. Kind of managed techincal debt.

~~~
kijin
As with all debt, it's not necessarily bad to incur technical debt. You just
need to know how to leverage the borrowed funds to turn an even greater profit
so that you can pay your debt back later and still come out ahead.

~~~
pbourke
Beginners let their mess metastasize throughout the system. Experts keep it
contained to a subsystem. There may be a lot of mess, but each subsystem is
messy in its own way, and can be dealt with individually.

------
ereyes01
Parts 1 and 2 are also great reads, as they go into the relationship between
the changer and the waiters.

It's especially challenging to communicate effectively when the waiter is not
a developer. The language of structure vs. behavior is an excellent way to
describe the challenges of building a system to a waiter, especially when
frustration with a slow perceived pace of behavior change is coupled with a
lack of understanding of needed structure. This vocabulary is universal and
clearly conveys what is happening- thanks Kent!

~~~
davidjnelson
Thanks for mentioning this. Read those and indeed fantastic reads.
Interleaving structural and behavior changes is brilliant. I already do that,
but these write ups give great advice on how to communicate the practice more
clearly.

Part 2: [https://medium.com/@kentbeck_7670/software-design-is-
human-r...](https://medium.com/@kentbeck_7670/software-design-is-human-
relationships-part-2-of-3-waiters-changers-and-sufficiency-4c0bb9a08d23) Part
3: [https://medium.com/@kentbeck_7670/software-design-is-
human-r...](https://medium.com/@kentbeck_7670/software-design-is-human-
relationships-part-3-of-3-changers-changers-20eeac7846e0)

------
agumonkey
That's why I'm studying graph theory and prolog

