Stuart Halloway - Narcissistic Design

The software industry changes rapidly, but you can protect yourself from these changes by creating code that is complicated enough that only you can maintain it.

Of course you should not engage in obvious bad practices. The good news is that you don't have to. You can follow idiomatic industry practice and stay buzzword compliant with the latest trends, while quietly spreading complexity throughout systems. Better yet, the symptoms will show up not in your own code, but in other code that uses your code, directly or indirectly. You will be a hero as you lead larger and larger teams burning the midnight oil to keep systems alive.

Practice these principles, and your code will have an infectious complexity that guarantees you will always be needed to maintain it.
Use OO, and don't forget those setter methods!

Prefer APIs over data.
Start with DSLs.
Always connect (and never enqueue).
Create abstractions for information.
Use static typing across subsystem boundaries.
Put language semantics on the wire.
Write lots of unit tests.
Leverage context.
Update information in place.

Stuart Halloway is a founder and President of Relevance. He is a Clojure committer, and a developer of the Datomic database.

Stuart has spoken at a variety of industry events, including StrangeLoop, Clojure/conj, EuroClojure, ClojureWest, SpeakerConf, QCon, GOTO, OSCON, RailsConf, RubyConf, JavaOne, and NFJS.
Stuart has written a number of books and technical articles. Of these, he is most proud of Programming Clojure.

Seen at Reaktor Dev Day 2013

[vitorvitali]

Very good, wish I could see the slides.

[miro]

This is just brilliant. Well done, Stu!

[willmcpherson]

I get all of this except static typing. Why do Closure guys not like it? In my head it makes sense. Maybe I’m wrong.

[JaihindhReddy]

12:50 "You've gotta screw those guys.." cracked me up.

[kap]

Great presentation, but heard to see the slides. A link, perhaps?

[rolfen]

SQL databases abstract low-level operations made by the database. How would the query language be replaced by a data model? Would we just feed XML files to the SQL client and get XML back?

By the way. There might be another motivation behind adding unneeded complexity. Developers have the task of managing complexity, so by creating complexity to manage, it can be argued that they are creating challenges to practice, exercise, improve their skills.

And finally, I like the tone in this video.
Thank you.

Really good points, but too "negative" energy: not good for comedy.

[murraynatkie]

I'm about 7 minutes in, is this satire?