Here are my notes from Jean-Paul Schmetz's talk in RuPy 2013 about dealing with complexity.
You can often date companies, like an archeologist, by the tech they use (1997 Perl, 2007 Ruby, ...)
Many K of engineers, millions of lines of code.
A "chief scientist" needed for dealing with complexity.
People get stuck. Even if you're the greatest your code from 1995 can come back to bite you.
Complexity is whatever prevents you - or someone else - from doing the right thing now or in the future.
Simplicity is the opposite - it's whatever helps you.
Complexity is easy, simplicity is difficult.
The litmus test for your level of complexity is the ability to change.
Simplicity is a prereq for agility, reliability, scalability, pretty much anything that ends with a y and that's good.
Easy is familiar, fast, framework, etc. But that's complexity.
There's difficulty involved in understanding what you use.
Complecting - Intertwining, interweaving.
Complexity comes from: Simple beginnings, code base grows, standups, meetings, gorilla is growing in the room - legacy code, database, things you've done in the past. People come in and can't figure it out. Other people burn out and leave. Gurus come in an advise for new practices. Team gets divided into smaller ones. Refactoring takes too long. Systems become nuclear waste. So many tests you can't deploy. Then Google eats your lunch because they're bigger and simpler.
Most people associate complexity with code - people want to "modernize that". But that's rarely the source. What does the code intertwine with? Mostlly data. Code is easily replaced and should be replaced.
Code that's proven correct is always better than well documented buggy code.
Code that works never has to be changed. If you need to change what it does, write a new thing.
Data is the biggest source of complexity. Most people don't think about data structure. Stupidity, tools, frameworks causes data to be untestable. Can't be replayed, cloned. (E.g. data for a social network invitation no longer exists after accepted - losing data).
Synchronously intertwined data and code is the first thing to fix.
Add people to that and it gets worse. 20 people is more difficult than 20 computers. Requires leadership, training, reviewing, brutal deadlines (or it's complexity for others) -> un-agile.
Software has to deploy its own infrastructure or it'll fail in a few years.
Processes bring risk: They don't optimize for the right thing but the process thing.
Protocols/interfaces are everything when it comes to communication: You're building a distributed system when you're building a company. If you know about distributed systems, look at the Internet. See how things lik the IP stack makes more complex things simple.
Hacking stuff is fine - just don't complect the hacked-up stuff with other stuff, so you can replace the hacked-up thing with another thing later (SOA style).
Notification systems combined with queues to decomplect things!
Know Your AngularJS Inside Out
Build Your Own AngularJS helps you understand everything there is to understand about AngularJS (1.x). By creating your very own implementation of AngularJS piece by piece, you gain deep insight into what makes this framework tick. Say goodbye to fixing problems by trial and error and hello to reasoning your way through them
- RuPy 2013: HTML Hypermedia APIs And Adaptive Web Design
- RuPy 2013: Substance D: Build Civilized Web Applications