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. |
And…