Home » Software Development » Development “Methodologies”

About Bozhidar Bozhanov

Bozhidar Bozhanov
Senior Java developer, one of the top stackoverflow users, fluent with Java and Java technology stacks - Spring, JPA, JavaEE, as well as Android, Scala and any framework you throw at him. creator of Computoser - an algorithmic music composer. Worked on telecom projects, e-government and large-scale online recruitment and navigation platforms.

Development “Methodologies”

Below are several development “methodologies” that are popular and even industry-standard:

Hype-Driven Development – you are either a startup, or you are given the freedom to choose whatever technology you like for your new cool-cutting-edge-distrupting-innovative-did-I-say-cool project. What technologies to use? The recently overhyped ones, of course. Let’s do it in Node.js, and you have to make it reactive, and do DevOps, even though your Linux experience is limited to running Ubuntu on your desktop, and store the data in MongoDB (it’s web-scale!). Speaking of web-scale, you will obviously need to go to the cloud. Then all of a sudden you have an unintelligible codebase, broken servers, pages take a second to load, you lose data every now and then, and you are unable to actually scale. But hey, you used cutting-edge, web-scale reactive technologies that you didn’t understand when you started, and were not applicable to your domain. But now your write a blogpost describing how to solve a problem with them, that has been solved for decades with other technologies. And you post it to hacker news, contributing to the hype.

Demo-Driven Development – you work in a team, part of a big organization that has adopted Agile/SCRUM. Or you are a “lean startup” and define the projects on the fly. In both cases the project does not have a clearly defined goal, but somehow money are being poured into it, so it has to keep going. The end result doesn’t seem to matter, but process has to be followed and you need to be be able to demo stuff to the stakeholders. So you write your code disregarding the fact that it should be used in production, and write it only to make it demoable. In small doses this is good, because being able to show something is indeed helpful to the project, although not part intrinsically valuable to the product. But you can easily go overboard and end-up with working for a year and demoing stuff that is completely unusable.

Copy-Paste Driven Development – applicable in multiple scenarios. If the team consists of many junior programmers and only one senior, “kindergarden expert”, or if engineers in the projects are constantly coming and going, without having time to really understand it, or if the company has many, very similar projects, but doesn’t have the resources to build a common, reusable toolkit, the usual development practice is to copy code from existing projects or features and paste it in the new one, changing the names of variables and methods. Another flavor is copy-pasting snippets from stackoverflow or mailing lists. That might go well for a while, and it’s generally good to have uniformity in the code. But often you’ll end up with code that’s there for no obvious reason, and nobody knows how and more importantly – why it works. Or doesn’t work. (This methodology is specifically applicable to test code)

Denial Driven Development – when the head(s) of engineering or architects, appointed such solely because of their age and inability or unwillingness to find another job, shun all frameworks and libraries, and insist that everything should be written internally. (This is the opposite of “Hype Driven Development”). You get to work with a lot of low-level and complex stuff. The sense of achievement is really high, and you go on reddit and flame everyone that uses puny frameworks. The only downside is, everything breaks, it takes twice the time to develop features (if you actually reach the feature development phase) and each new team member has to first go through a 3-month introductory course. But hey, in the end you at least have a solid framework that nobody uses, doesn’t handle real-world cases, and you probably can’t opensource, because it’s proprietary.

If you are using these methodologies, you are probably in trouble, but if you haven’t realized that yet, this post probably won’t be useful anyway. And I’m not even telling you how to fix them. Well, I can tell you how to fix them – be sensible. But that’s too hard.

Reference: Development “Methodologies” from our JCG partner Bozhidar Bozhanov at the Bozho’s tech blog blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!


1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design


and many more ....



One comment

Leave a Reply

Your email address will not be published. Required fields are marked *


Want to take your Java skills to the next level?

Grab our programming books for FREE!

Here are some of the eBooks you will get:

  • Advanced Java Guide
  • Java Design Patterns
  • JMeter Tutorial
  • Java 8 Features Tutorial
  • JUnit Tutorial
  • JSF Programming Cookbook
  • Java Concurrency Essentials