3 ms·

The most famous article on this topic is called "No Silver Bullet". It basically answers this question: split up the work you need to do into "essential complex

by edanm 9y ago

The most famous article on this topic is called "No Silver Bullet". It basically answers this question: split up the work you need to do into "essential complexity", which is specifying in minute detail exactly what you want your app to do, and "accidental complexity", which is all the programming work around that to get it done. The "essential complexity" is still most of the work. Thought experiment: If I gave you a programming environment in which you just said, out loud, exactly what you wanted to have happen, and there was no programming, it just happened, how fast could you build a CRUD app? Significantly faster, true, but there'd still be tons you need to specify, just because you want something that does something specific. If you want an example of something that that is fully automated, think of a Facebook page. You can build it in seconds, but you're sacrificing tons of customizability. In terms of our thought experiment, this is like saying "make my app exactly like that". It's very efficient, but lacks most customizability.

eru 9y ago
"Out of the tarpit" (http://lambda-the-ultimate.org/node/1446 http://lambda-the-ultimate.org/node/1446) is an interesting contrast / comparison to "No Silver Bullet".
luisobo 9y ago
There are many things that we do or could do to make the ssential complexity more manageable. Something that we do already is abstract away parts of the essential complexity (CRUD, entities, validations, etc) where you have DSLs to specify that essential complexity. But there are many other things we could as well, like some sort of ontological autocomplete that would help you specify your business model (a User may have these fields, a “Sale” is better represented as a “Transaction” in order to handle returns) Moreover, re the Facebook App example, the ease of creation vs control is a false dichotomy. A page builder of sorts could spit a predefined design (to have something working ASAP) but there is no reason you couldn’t customize completely to your liking, as if no page builder was used. In other words, having a working app ASAP by using defaults, in order to aid requirement discovery, should be a feature or programming environments/tools/libraries framewors and not an either-or.
alexasmyths 9y ago
I'm not sure I agree. The essential complexity usually isn't that hard. From a high level view - most apps are basic. Even a second order articulation of function i.e. 'screen here, buttons here, images here, button does this' etc. is not that hard. Below that, it's kind of a mess. The byzantine tools we have (I'm talking to you HTML/CSS/JS), to complete the task engender a massive amount of 'arbitrary complexity' and make doing anything really quite hard. Which is why, by the way - once you have a Dev that becomes 'really familiar' with a 'specific stack' - they can move really quite quickly. But most of the tools we have are a mess, and they keep changing, hence, all the complexity in our systems - which grows exponentially across more and more developers until you have any number of very smart people all trying to paint a Picasso at the same time. FYI - I believe that making an app shouldn't be that-that much more complicated than making an FB page. There isn't really a lot of 'essential complexity' in most apps, I think.
- jstimpfle 9y ago
  I agree to some extent, but I wonder if you actually tackled a web project of more-than-trivial complexity? I did, and tried to find a number of good abstractions (for example, generating UI / ORM according to data structures), but in the end didn't come up with something satisfying. It's too easy to paint yourself into a corner. In my opinion one of the big sources of essential complexity is the layering. You have representations of your data in the DOM, in Javascript objects, in HTTP bodies / URLs, in server-side plain text representations, in the server-side language's objects, in the database... And strictly speaking you have to make sure (de)serialization works and data integrity holds at each of these boundaries. Also, many functional parts need to be present in more than one of these domains.
  - alexasmyths 9y ago
    I've worked on big and small. Even for the 'big ones' the (there were network management apps) - the 'business logic' (networking logic in this case) - was not rocket science in the end. As you indicated, not only is the 'layering' a pain, but often there's a whole set of technologies and toolchains at each layer! Even just starting with 'identity' for a web app, i.e. Facebook and Twitter integration along with basic credentials - can be a big pain.

by edanm 9y ago

eru 9y ago

"Out of the tarpit" (http://lambda-the-ultimate.org/node/1446 http://lambda-the-ultimate.org/node/1446) is an interesting contrast / comparison to "No Silver Bullet".

luisobo 9y ago

There are many things that we do or could do to make the ssential complexity more manageable. Something that we do already is abstract away parts of the essential complexity (CRUD, entities, validations, etc) where you have DSLs to specify that essential complexity. But there are many other things we could as well, like some sort of ontological autocomplete that would help you specify your business model (a User may have these fields, a “Sale” is better represented as a “Transaction” in order to handle returns) Moreover, re the Facebook App example, the ease of creation vs control is a false dichotomy. A page builder of sorts could spit a predefined design (to have something working ASAP) but there is no reason you couldn’t customize completely to your liking, as if no page builder was used. In other words, having a working app ASAP by using defaults, in order to aid requirement discovery, should be a feature or programming environments/tools/libraries framewors and not an either-or.

alexasmyths 9y ago

I'm not sure I agree. The essential complexity usually isn't that hard. From a high level view - most apps are basic. Even a second order articulation of function i.e. 'screen here, buttons here, images here, button does this' etc. is not that hard. Below that, it's kind of a mess. The byzantine tools we have (I'm talking to you HTML/CSS/JS), to complete the task engender a massive amount of 'arbitrary complexity' and make doing anything really quite hard. Which is why, by the way - once you have a Dev that becomes 'really familiar' with a 'specific stack' - they can move really quite quickly. But most of the tools we have are a mess, and they keep changing, hence, all the complexity in our systems - which grows exponentially across more and more developers until you have any number of very smart people all trying to paint a Picasso at the same time. FYI - I believe that making an app shouldn't be that-that much more complicated than making an FB page. There isn't really a lot of 'essential complexity' in most apps, I think.

jstimpfle 9y ago
I agree to some extent, but I wonder if you actually tackled a web project of more-than-trivial complexity? I did, and tried to find a number of good abstractions (for example, generating UI / ORM according to data structures), but in the end didn't come up with something satisfying. It's too easy to paint yourself into a corner. In my opinion one of the big sources of essential complexity is the layering. You have representations of your data in the DOM, in Javascript objects, in HTTP bodies / URLs, in server-side plain text representations, in the server-side language's objects, in the database... And strictly speaking you have to make sure (de)serialization works and data integrity holds at each of these boundaries. Also, many functional parts need to be present in more than one of these domains.
- alexasmyths 9y ago
  I've worked on big and small. Even for the 'big ones' the (there were network management apps) - the 'business logic' (networking logic in this case) - was not rocket science in the end. As you indicated, not only is the 'layering' a pain, but often there's a whole set of technologies and toolchains at each layer! Even just starting with 'identity' for a web app, i.e. Facebook and Twitter integration along with basic credentials - can be a big pain.