Software is bad. Even software we build is bad. And that has to do with the amount of common sense we put into it. It's surprisingly hard to apply common sense to all aspects of a software project. The talk is going to be about a list of things found in many software projects that defy common sense, and yet many of us do them.

1. Common sense
driven development
Bozhidar Bozhanov

2. Vanity slide
http://techblog.bozho.net
@bozhobg
Senior Software Engineer @ TomTom

3. It’s a maze
TDD, BDD
Domain-driven design, Design-driven
development
SOA, Microservices
MQs, ESBs, rules engines, data processing
engines

4. ...and software is still crap
“because writing software is hard”, we soothe
ourselves

5. Some real methodologies
Hype driven development (Big Data in the
Cloud, yeah)
Demo driven development
Copy/paste driven development
Denial driven development (Not Invented
Here syndrome)

6. Common sense
Common sense gives you
less bugs
maintainability
extensibility
scalability
eternal life

7. Applying common sense
No definition for common sense
...so we’ll define it by counter-examples

8. Let’s make an API
...that we never write against
TransformerFactory tf = TransformerFactory.newInstance();
Transformer transformer = tf.newTransformer();
transformer.setOutputProperty(...);
StringWriter writer = new StringWriter();
transformer.transform(new DOMSource(doc), new
StreamResult(writer));
String result = writer.toString();
default use-case(s)

9. Let’s use raw JDBC
easy to setup
...and you’ll eventually build a feature-poor,
buggy and time-consuming object mapper.
you are probably using ORMs wrong

10. Let’s use java.util.Date
...instead of joda-time, java.time
or let it creep from other libraries
java.util.Date is mutable, not timezone-aware, with a
bad, deprecated api. Bottom line: it’s bad
extra effort for: hibernate, json/xml
serialization

11. Let’s homegrow a
framework
NIH (Not Invented Here) syndrome
“NIH's emphasis is on ignoring, boycotting, or
otherwise refusing to acknowledge solutions by
others.”
Our web framework, our DI, our ORM, our
build tools.
...what could go wrong?

12. Let’s not use latest versions
Java 8 is “too new” #not
Latest JavaEE/Spring is probably still buggy
We don’t have time to learn the new things
We have a “standard infrastructure”
… and other bullshit
critical security issues, fixed bugs
regularly upgrade

13. Let’s not support safe-and-refresh
...because waiting for 3 minutes to see
changes is cool
you can check facebook
JRebel is not the only option
HotSwap in debug mode

14. Process

15. Let’s skip code reviews
we don’t have time
we are really good, we promise
someone may get offended
...because I suggested to rename a variable

16. Let’s not write tests
we don’t have time
but we do have time to fix recurring bugs
we are really good, we promise
the code is simple and doesn’t need testing
yeah, right

18. Let’s make it work just for the demo
...and never actually deliver working features
it’s fine to show incomplete features
it’s not fine to write crap in the codebase just for a
demo to work

19. Let’s allow management decisions to
influence software design
because non-technical managers know better:
which database to use
what frameworks to use
how to structure the deployment
that 89% coverage is not enough

20. Architecture
(source: MSDN.com)

21. Let’s use SOAP
...for no apparent reason
...where simple RESTful services will do
...and we don’t actually need web services

22. Let’s use an ESB
...because I heard it’s cool
...even though we have to integrate just 2
systems, both of which are under our control
it won’t break, I promise.

23. Let’s use an MQ
“message-driven” - decoupling, throughput,
fault-tolerance, distributed processing
right… do you really need these?
what’s the overhead of managing an MQ?
async processing without MQ, in your JVM
there are legitimate use-cases. But fewer than
you think.
hardware is cheap, unreadable code isn’t

24. Let’s use application-level state
instance fields with data
non-cache (non-dismissable) information
well, maybe you don’t want to scale out

25. Let’s split the system
...and make separately deployable
submodules communicate with web-services
with us as the only user
...of our relatively small application
monolithic applications work fine
splitting, microservices - prove if necessary

26. (by Martin Fowler)

27. Let’s [..]. How about...

28. So...
That’s what commons sense isn’t.

29. But there were contradictions...
like “reuse existing solutions” vs “you probably
don’t need X”
or “don’t overdesign in advance” vs “design
good APIs”
This is where you apply common sense to
choose what fits your case :)

30. Obvious?
Yes, but every project has many of the above.
Common sense is not a set of rules or a set of
slides.

31. Based on...
http://techblog.bozho.net/development-methodologies/
http://techblog.bozho.net/you-probably-dont-need-a-message-queue/
http://techblog.bozho.net/the-default-use-case/
http://techblog.bozho.net/orm-haters-dont-get-it/
http://techblog.bozho.net/do-it-either-way-well-refactor-it-later/
http://techblog.bozho.net/kiss-my-yagni/
http://techblog.bozho.net/two-types-of-deployment-of-subsystems/
http://techblog.bozho.net/keep-as-much-stuff-as-possible-in-the-application-itself/
http://techblog.bozho.net/state-does-not-belong-in-the-code/
http://techblog.bozho.net/save-and-refresh-with-java-web-projects/
http://martinfowler.com/bliki/MicroservicePremium.html

32. Questions?