Common Sense Driven Development

Common sense
driven development
Bozhidar Bozhanov

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

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

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

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)

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

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

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)

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

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

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?

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

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

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

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

Common Sense Driven Development

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

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

Architecture
(source: MSDN.com)

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

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.

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

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

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

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

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 :)

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

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

Common Sense Driven Development

More Related Content

What's hot (20)

Viewers also liked (9)

Similar to Common Sense Driven Development (20)

More from Bozhidar Bozhanov (20)

Recently uploaded (20)

Common Sense Driven Development

Editor's Notes