
Software Development as an Emergent System - rdfi
https://www.blinkingcaret.com/2018/08/22/software-development-emergent-system-ndepend/
======
rossdavidh
Cool and all, but having a way to measure the gnarliest parts of the code is
not, in my experience, the problem. Having a management objective that is
willing to devote any non-zero amount of time to paying down technical debt is
more often the problem. Technical debt costs over time, and new features pay
off much quicker. The management may not even intend to be around in the long
term (if they're developing for a client or intend to sell to a larger
company, for example).

Of course, having a measurement might help shine a spotlight on how things are
getting worse, but I've never actually seen this happen. Perhaps others have a
different experience?

~~~
maxxxxx
I think it's a matter of attitude. Either you accept that there is value in
keeping a code base reasonable or not. Maybe some metrics can help to make a
point but any metric will be abused over time if used too religiously.

You are making a good point about people not being around long term. In my
company there are departments with high turnover and they tend to go for quick
victories that are often costly in the long term. At the time this becomes
clear the manager who made the previous has already been promoted somewhere
else and the next guy will make another quick decision to fix the previous
problem. Then this guy gets promoted too and the cycle continues.

Technical debt is really only a problem if you think long term.

~~~
stcredzero
A good analogy for older management, which is disappearing as an extant object
in the office, is that of the file room. Sometimes, you'll see a seeming "whiz
kid" file clerk who seems to be far faster than normal, but it turns out that
he's "faster" because he doesn't actually re-file and reorganize.

Refactoring is quite literally the same thing as re-filing and reorganizing
physical files. Under the academic definition of refactoring, the "contents"
(the functionality) is not changing. Only the organization is changing.

~~~
Jtsummers
A colleague and I developed a good routine for a while. He's a much faster
programmer than me. But his code quality is usually much lower (not _wrong_ ,
but often poorly structured and hard to maintain). He'd code fast, I'd code
slow. Then I'd clean up his stuff while we waited for feedback on the system
and he did other things. Refactoring work and the like, no meaningful (to an
end user) changes.

This was effective. Except that management saw him as fast and so he kept
getting more work, and completing it. But the quality wasn't there because no
one went in behind him to keep it clean and tidy. Management never really saw
the issue, they just thought the rest of us were bad programmers because we
were so slow. We were slow because: 1) some of us (like me) work slowly; 2)
the fast guy introduced a lot of technical debt (or we introduced it because
we weren't given the cleanup time I used to have).

He's still a good programmer (in general), but without the support structure
his products are far less useful than they same at first glance (due to the
introduced technical debt).

~~~
hinkley
Having to work in and around very bad code slows everybody else down, we have
a very prolific guy who creates his own jargon (inconsistently) and enjoys
convolution like it’s an art form. Everybody else has to spend twice as long
doing the most rudimentary features.

But management loves their heroes, so the people with high tolerance for
complexity get promoted, and all the people I trust keep leaving...

------
simplesleeper
I don't think the author understands what "emergence" is. The concept of
emergence is that a complex system might have properties that CANNOT be
explained by studying the parts.

------
Jtsummers
The talk about boids made me think this would go in a different direction.

Programmers and our employers exhibit flocking behavior. See how Ruby on Rails
brought so many people to the Ruby language. How Python had a similar surge
earlier in the 00s, and later with the explosion of use (numpy and similar) in
data science applications. Additionally, things like Ruby on Rails helped make
the web application commonplace. See JavaScript and AJAX for that as well.

Perl established an effective code repository (CPAN) that enabled their
userbase to grow via a similar flocking mechanism. Go has no central
repository but has an easy to use mechanism for adding dependencies based on
git repositories. That ease of access to published modules allows people to
adopt the technology once a peer (someone working in a similar domain)
publishes something. And it encourages people to contribute back in some
fashion (publish new modules or update the existing ones). In Perl's case you
saw a lot of people from outside IT making use of it (the same is now true for
Python with data science) because the heavy lifting was done and they could
focus on gluing things together.

Exploiting this flocking behavior, then, becomes important to anyone wanting
to push a new technology out. Even if it's the best thing and would produce
the best software ever, it won't always succeed on its own merits.

(random thoughts, no real thesis here)

~~~
jacques_chester
The simple model for this kind of thing is Polya's Urn.

Take an urn with green and red balls (or blue and orange, if you're colour-
blind).

Pick out a ball. If it is red, put it back and replace a green ball with
another red ball. If green, put it back and replace a red ball with a green.

Even starting with a perfect 50:50, and choosing _completely randomly_ , a
Polya process will eventually show that your probability of picking one colour
becomes more or less certain. The urn "locks" into a particular path. While in
theory it _could_ return to 50:50 or swing back to the other colour, the odds
of doing so rapidly become astronomical.

John Sterman's _Business Dynamics: Systems Thinking and Modeling for a Complex
World_ has a really excellent discussion. Worth looking for.

~~~
Jtsummers
That book actually just made it onto my Amazon wishlist (for other reasons). I
know I'm unlikely to succeed in my current company, but I'm trying to increase
my understanding/fluency in systems thinking in order to improve the company's
understanding. Realistically, this means I'm building a skillset for my next
job.

That particular model is interesting for what I described. Essentially, if
someone wants to program they'll be drawn to one of the projects/people
already out there which are already using some language. They'll then use the
same language and become a person or produce a project that the next person
may be drawn to. The original thing that drew them to the language is still
there, and they're another point to draw someone else to the same language.

Thanks.

~~~
jacques_chester
Exactly, this is path dependency in a case where value comes from network
effects. I have occasion to apply this material in thinking about my work and
I'm hoping to get to apply more of it as time goes.

Sterman's is the best all-round book on systems thinking I've read. Not too
hand-wavy, not swimming in calculus, plenty of interesting case studies and
practical advice that show deep experience. It's in a sweet spot for me.

Edit: as a note, it always seems to be substantially cheaper on Book
Depository than on Amazon. I suspect that bots are, hilariously, in a feedback
loop bidding up a book about feedback loops.

~~~
Jtsummers
This [0] is something I came across while looking up information on systems
dynamics/thinking in general. That's how the book ended up on my list. I
haven't gone through it yet but I probably will over the next few weeks now
that my life/schedule has settled down a bit.

I've also been reading Weinberg's _General Systems Thinking_ (bundle with it
and some other books at Leanpub[1]). I can't say I've seen anything _new_ in
it yet, but it (like many books) is connecting dots for me that I hadn't
connected before. Reading through it, I wish I'd seen some of its content when
I was younger, it could've made some things easier over the years.

[0] [https://ocw.mit.edu/courses/sloan-school-of-
management/15-87...](https://ocw.mit.edu/courses/sloan-school-of-
management/15-871-introduction-to-system-dynamics-fall-2013/)

[1]
[https://leanpub.com/b/generalsystemsthinkerbundle](https://leanpub.com/b/generalsystemsthinkerbundle)

------
z3t4
I write down every issue - everything from user interface issues to bugs, and
then delete them as they get fixed. I can then use that file to measure code
debt. The file is saved in version control, so no fancy stuff, but I can run
statistics and compare code growth and growth of issues. In my experience you
want to keep this file small. On a current project I've estimated that it will
take five years to clear this file < _grin_ >. This file seem to grow
exponentially with new features. And I think at some point there's a point of
no return - where you can't possible fix all issues ...

