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

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • constructors with 10 parameters, using different order of pairs of parameters (source, target|target,source)
    speaking of bad APIs...
  • orms are hard to setup and make it easy for shooting yourself in the foot.
    raw jdbc is fine sometimes, and ORMs give you that
  • transition to the next slide: what hibernate?
  • extend or patch existing ones instead.
  • does that remind you of something? I copied this slide to the next one
  • but don’t aim for 100% coverage, of course.
  • emphasize on monolithic applications
  • 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?