The best use of the this “essential” software development glossary is to have fun with colleagues and friends over a beer or two. Enjoy responsibly!
Refactoring
When deleting all code and starting from scratch is easier than trying to understand what code is doing. Also known as Doing It Right This Time.
TDD
Initially meant Test Driven Development. Many programmers however correctly pointed out that if there is a Test in the name that is something the QAs should be doing. Because of that it was later renamed to Too Damn Difficult.
Pair programming
It is rumored this technique leads to better code design and less bugs. In reality it is just a clever trick to ensure your programmers work instead of browsing the internet. An effective way to learn to use different computer keyboards.
GIT
GIT is abbreviation. Could mean Global Information Tracker, Goddamn Idiotic Truck, something else or all the above. If you find this hard to believe check out the README file included in Linus Torvalds first commit for GIT.
Iron Triangle
A picture is worth a thousand words, so we’ll be short here. On time, on budget, all functionality delivered, quality – you cannot get any.
Balmer’s Peak
My personal experience points to a beer and half.
We Will Fix it Later
Small UI glitch? Dutch translation does not work? Something added extra rows to your DB? Repeat after me: “This is not our current priority”. All users should be grateful your app is working. You have more important things to do, so they should stop complaining about stuff that does not matter.
Hope Driven Development
Sometimes confused with the practice Test it until it starts to work. Idea behind it that you do not test any code you have written and hope it works fine. A magical bug eating unicorn from the future will appear and fix any problem with your code if needed.
Copy-Paste Development
Used in legacy codebases and by less experienced developers. Neglected for many years, but recently gained a lot of popularity due to sites like StackOverflow.
Bug Driven Development
This method is about helping you decide what you need to do next. If you have a lot of bugs you do not need planning. Just start with the bug most people are complaining about and continue from there. Plays well with “We Will Fix It Later” and “Hope Driven Development”.
Skype Driven Development
Make sure you have Skype or other IM chats setup for your team. Do not forget one chat with all people in your organization. Now start using these for everything. Task assignment, test cases, documentation, discussion on design. Bonus points if your IM has a good history. You are going to need it when somebody new starts asking questions.
I wonder how many more can be added 🙂
Thank you for reading.