Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Common Sense Driven Development


Published on

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.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Common Sense Driven Development

  1. 1. Common sense driven development Bozhidar Bozhanov
  2. 2. Vanity slide @bozhobg Senior Software Engineer @ TomTom
  3. 3. It’s a maze TDD, BDD Domain-driven design, Design-driven development SOA, Microservices MQs, ESBs, rules engines, data processing engines
  4. 4. ...and software is still crap “because writing software is hard”, we soothe ourselves
  5. 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. 6. Common sense Common sense gives you less bugs maintainability extensibility scalability eternal life
  7. 7. Applying common sense No definition for common sense we’ll define it by counter-examples
  8. 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. 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. 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. 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. 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. 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. 14. Process
  15. 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. 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
  17. 17. 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
  18. 18. 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
  19. 19. Architecture (source:
  20. 20. Let’s use SOAP ...for no apparent reason ...where simple RESTful services will do ...and we don’t actually need web services
  21. 21. 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.
  22. 22. 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
  23. 23. Let’s use application-level state instance fields with data non-cache (non-dismissable) information well, maybe you don’t want to scale out
  24. 24. 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
  25. 25. (by Martin Fowler)
  26. 26. Let’s [..]. How about...
  27. 27. So... That’s what commons sense isn’t.
  28. 28. 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 :)
  29. 29. Obvious? Yes, but every project has many of the above. Common sense is not a set of rules or a set of slides.
  30. 30. Based on...
  31. 31. Questions?