Recent searches
Search options
Re this important thread from @grimalkina:
https://mastodon.social/@grimalkina/111972810596703896
I just gave a little soapbox to my Software Design and Development students that I give every time I teach the class, and I’ll give it here on Mastodon.
Software development is an intensely social discipline.
1/
Software is made by humans for humans.
Most software is made by teams. All software involves interacting with other people. When you use a tool, a programming language, you’re interacting with the people who made it; when people use your software, they’re interacting with you. When software works or doesn’t work, that’s the decisions of others, the work of others that you’re experiencing. It’s people all the way down.
2/
Most software is made by teams, and software development is an •intensely• social activity. Software projects stand and fall on the relationships between the humans who create it: whether they understand each other, whether they collaborate well, how they make each other feel.
Computers don’t fill in the gaps and misunderstandings for us with common sense; when we don’t understand each other, we •codify• that misunderstanding in our code, fix it in place and turn it loose.
3/
The best software tester I’ve ever known once said to me, “Whenever I start at a new place, I find out which teams hate each other. Where their systems interface with each other is the first place I look for bugs — because they’re not talking to each other.”
Software projects stand and fall on the relationships between the humans who create them. (A corollary to Conway’s Law.)
4/
@inthehands
Yeah ... and that is why Traditional Configuration Management has Interface Control Working Groups so that someone can make sure they talk and crack some heads together if they don't play nicely.
The worst SNAFU I saw was when our customer (a very big mining firm) wrote their own description of the interface to our software and consulted neither the software documentation or ourselves and gave it to another contractor to build a big downstream system. A year or so later our system did something that is completely acceptable but wasn't in their specification and they tried to raise a defect notice against us. It took a couple of years of to-ing and fro-ing before they called a formal fault resolution meeting and the existence of the unsupported interface specification came to light.
> "It took a couple of years of to-ing and fro-ing before they called a formal fault resolution meeting and the existence of the unsupported interface specification came to light."
_Years?_ ... UuuuughhhaaaaAAAAARRRRGG!!!....<screaming continues silently>
@raven667 @inthehands
The downstream contractor was raising the faults. The policy of Big Mining Company was that subcontractors should never be allowed to talk to each other and preferably never even know of each others existence.
The behaviour in question was our system responding to an error condition and that did not happen frequently. We repeatedly told them it was expected behaviour but the other subcontractor wanted a lot of money to re-write sections of their system. We tried to put mitigation in place but without knowing why it was a problem we were a bit hamstrung.
@Steveg58 @raven667 Rigid specifications, blocked communication, and CYA-first thinking all go hand in hand. It’s a tough hole for an org to crawl out of.
At best, a spec is a tool of communication, a light to shine misunderstandings and hidden assumptions into sharp relief. At worst, it’s a legal prop.