Live data from Hacker News

Software Development as an Emergent System

blinkingcaret.com

21–27 of 27 posts

Re: Software Development as an Emergent System

#21

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.…

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.

Re: Software Development as an Emergent System

#22

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.…

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 o…

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.

Re: Software Development as an Emergent System

#23

Earlier quoted context omitted.

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 o…

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 t…

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.

Re: Software Development as an Emergent System

#24

Earlier quoted context omitted.

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 t…

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…

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...

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

Re: Software Development as an Emergent System

#26

Earlier quoted context omitted.

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 definit…

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.…

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...

Re: Software Development as an Emergent System

#27

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 c…

The one company that I worked for that did everything “right” - unit tests, paying down technical debt, code reviews, etc. was led by a manager who was originally the founder of the product that got acquired by what was then a Fortune 10 company. After two years working on the new well tested, well written product, no one wanted the new .Net product, they stopped working on it and put everyone on the old PHP based pr…

Most care about velocity, and doing work to support that is usually defensible.

You can keep velocity high on a badly run project for a couple years, but if your roadmap or business plan is long term, you will find that 5ings calcify before you’re ready for them. I always try to remind people that this is about the long term.

It’s also easier to grow and shrink a team when the code is Clean. But some of your coworkers won’t like the idea that they can be gotten rid of so easily. At the heart of its that’s the struggle. One or two experts on the system is enough to keep those people and their bosses fat and happy for quite a while.

Post reply on HN