Unveiling the Truth Behind Software Development Methodologies
Exploring the nuances of software development methodologies framed around the essence of common sense. Dive into a realm of sensible practices versus hype-driven trends, emphasizing the importance of simplicity and practicality in crafting robust software solutions.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Common sense driven development Bozhidar Bozhanov
Vanity slide http://techblog.bozho.net @bozhobg Senior Software Engineer @ TomTom
Its 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 o less bugs o maintainability o extensibility o scalability o eternal life
Applying common sense No definition for common sense ...so we ll define it by counter-examples
Lets 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)
Lets 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
Lets use java.util.Date ...instead of joda-time, java.time or let it creep from other libraries o 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
Lets homegrow a framework NIH (Not Invented Here) syndrome o 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. o ...what could go wrong?
Lets 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
Lets not support safe-and-refresh ...because waiting for 3 minutes to see changes is cool o you can check facebook JRebel is not the only option HotSwap in debug mode
Lets skip code reviews we don t have time we are really good, we promise someone may get offended o ...because I suggested to rename a variable
Lets not write tests we don t have time o but we do have time to fix recurring bugs we are really good, we promise the code is simple and doesn t need testing o yeah, right
Lets make it work just for the demo ...and never actually deliver working features it s fine to show incomplete features o it s not fine to write crap in the codebase just for a demo to work
Lets allow management decisions to influence software design because non-technical managers know better: o which database to use o what frameworks to use o how to structure the deployment o that 89% coverage is not enough
Architecture (source: MSDN.com)
Lets use SOAP ...for no apparent reason ...where simple RESTful services will do ...and we don t actually need web services
Lets 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.
Lets use an MQ message-driven - decoupling, throughput, fault-tolerance, distributed processing o right do you really need these? o 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
Lets use application-level state instance fields with data non-cache (non-dismissable) information well, maybe you don t want to scale out
Lets split the system ...and make separately deployable submodules communicate with web-services o with us as the only user o ...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
