Common Sense Driven Development

Common sense driven developmentBozhidar Bozhanov

Vanity slidehttp://techblog.bozho.net@bozhobgSenior Software Engineer @ TomTom

It’s a mazeTDD, BDDDomain-driven design, Design-driven

developmentSOA, MicroservicesMQs, ESBs, rules engines, data processing

engines

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

Some real methodologiesHype driven development (Big Data in the

Cloud, yeah)Demo driven developmentCopy/paste driven developmentDenial driven development (Not Invented

Here syndrome)

Common senseCommon sense gives you

less bugsmaintainabilityextensibilityscalabilityeternal life

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

Let’s make an API...that we never write againstTransformerFactory 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 JDBCeasy 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.timeor 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 versionsJava 8 is “too new” #notLatest JavaEE/Spring is probably still buggyWe don’t have time to learn the new thingsWe have a “standard infrastructure”… and other bullshitcritical security issues, fixed bugsregularly upgrade

Let’s not support safe-and-refresh...because waiting for 3 minutes to see

changes is coolyou can check facebook

JRebel is not the only optionHotSwap in debug mode

Process

Let’s skip code reviewswe don’t have timewe are really good, we promisesomeone may get offended

...because I suggested to rename a variable

Let’s not write testswe don’t have time

but we do have time to fix recurring bugswe are really good, we promisethe code is simple and doesn’t need testing

yeah, right

Let’s make it work just for the demo...and never actually deliver working featuresit’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 usewhat frameworks to usehow to structure the deploymentthat 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 controlit won’t break, I promise.

Let’s use an MQ“message-driven” - decoupling, throughput,

fault-tolerance, distributed processingright… do you really need these?what’s the overhead of managing an MQ?

async processing without MQ, in your JVMthere are legitimate use-cases. But fewer than

you think.hardware is cheap, unreadable code isn’t

Let’s use application-level stateinstance fields with datanon-cache (non-dismissable) informationwell, maybe you don’t want to scale out

Let’s split the system...and make separately deployable

submodules communicate with web-serviceswith us as the only user...of our relatively small application

monolithic applications work finesplitting, microservices - prove if necessary

(by Martin Fowler)

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

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

Questions?