Comments on: A field guide to simplicity

By: Simplest Thing

Simplest Thing — Wed, 26 Dec 2007 20:39:35 +0000

[...] Further Reading: Simple Ain’t Easy A Field Guide To Simplicity complex vs complicated, + xaos No ! Your software is complicated, not complex. [...]

By: Nik

Nik — Tue, 18 Jul 2006 20:48:26 +0000

Hmm, yes, all well said. I was blurring the distinction between complexity and complicatedness. I'd say the definition I was assuming was the definition of complex from Wordnet: S: (adj) complex (complicated in structure; consisting of interconnected parts) "a complex set of variations based on a simple folk melody"; "a complex mass of diverse laws and customs" It would certainly have been clearer if I'd have used the word "complications" instead.

By: bryan

bryan — Tue, 18 Jul 2006 17:34:11 +0000

ahh, agreed. i used the word complexity to mean something entirely different from complicated cos complex does not neccessarily mean complicated and vice-versa.
so i have a subtle definition between the two words, so don’t know if that would clarify what i was intending…?
but given the subtle but important diff between the two words, i would definitely agree that removing “complications” is a definite goal.

if i may… and for my benefit here, would the goal to remove complexity [but as per the definition i have used for my own understanding] still be applicable or is it more a case of removing complications?
if it’s still pertains to complexity [and not complications]… i’m struggling to see how you can remove complexity as such.

“complex” -a set or arrangement of things so related or connected as to form a unity or organic whole [but it's easy to understand]

“complicated” -anything that is difficult to understand

i will say though that you’re spot on with external pressures and complexity of the domain contributing to complification of the solution [would this concurrence put us on the same page then?]

By: Nik

Nik — Tue, 18 Jul 2006 08:34:00 +0000

Thanks for the comment, bryan. I agree with all your examples about how complexity arises. They are real-world examples, born of real life pressures. I also agree that complexity of the software is proportional to complexity of the problem domain.

But I’m sure we’ve all seen systems which “could have been done better”, and that’s what this is about. Similarly, I know of systems which were written by a fairly inexperienced person (or one person without consultation) which were overcomplicated, and recognise that if a more experienced person had written it (or if they’d bounced ideas off other people), even subject to the same pressures and working to the same requirements, they would have produced something clearer and more maintainable.

I’m simply saying that external pressures and the complexity of the domain are not the only factors which contribute to the complexity of the solution.

By: bryan

bryan — Tue, 18 Jul 2006 06:56:50 +0000

> Hide complexity. Remove complexity.
i think neither of these should be goals, ie the differences are largely distracting. complexity will always be a product of any software system over time. that’s a given and you can’t escape that destiny. dynamic factors which guarantee complexity include, inter-alia, team size, market pressures, skills and processes. these work together in an emergent way to actively produce complexity which can spiral into chaos, without active management. hello, simplicity.

both in requirements design and in technical implementation so you can never aspire to remove complexity nor hide complexity intentionally, thus is it can never be a goal [that you cna realise]. and if you aspire to simplicity more intentionally, you will be more willing and able to embrace complexity. it’s because we cannot deal with complexity, cos it’s well, complex that we say “hide it” or “remove it”. but with simplicity as a tool and ally, complexity is what makes systems wonderful [dare i say, even beautiful ] to work with.