My notes of an amusing talk about Do’s and Don’ts in software development.
Here are the main points I took away:
1. Conference-Driven Delivery
Prepare your talk last minute.
Remember: Communicating is probably more important than coding. Do Test Driven Presentations: Practice talking by speaking in user groups or record your talk and review it. These are good ways to improve your presentation skills.
2. Mortage-Driven Development
Don’t share any knowledge about the system you’re developing to get indispensable.
Use proper version control (or go to social coding sites e. g. on GitHub). Share your knowledge (A colleague of mine once said: “Share it or it doesn’t exist”).
3. Distracted by Shiny
Always use the latest technology.
Innovation is undoubtedly important. But also strive for consistency. Don’t put anything new into your system just because you feel like it (or read it in the latest Java magazine). Exchange your experiences with different technologies in brown bag sessions. Don’t do anything because “it’s interesting”. We developers are here to deliver actual value to our customers. A specific technology will probably stay 15 – 25 years in the product. If it’s a bad choice for developing efficiently, it’s a huge cost for your company. If it is an essential part of your infrastructure, you’re screwed. Remember SOAP!
4. Design Driven Design
Just code in design patterns from the beginning on. Let’s use UML code generators, too.
Design only for what you need now (remember YAGNI: You Aren’t Gonna Need It). Design is a huge cost, so anything you can defer will save you some money. Go for less source code (my favorite one). Don’t use frameworks that require much boilerplate code. Get even rid of some existing source code.
5. Pokemon Design Patterns
Just use all the GoF design patterns!
The right design pattern at the right time is your friend. Don’t rebuild features in your preferred programming language when there is already a programming language out there that includes that feature by default. It’s often the case that there is first some repeated code that makes it into a framework that is then incorporated into a new programming language’s core feature. Carry whiteboard markers with you to be instantly able to sketch some designs and discuss them with your team. There was a saying at Sun Microsystems: “Make a decision, commit to it and move on!” (OK, I wouldn’t recommend that process…the main message is to quickly move on and not to get stuck).
6. Tuning by Folklore
Just profile your application in case of performance issues
Profilers will give you the answer to questions you don’t have asked. Measure, don’t guess! Code is not the bottleneck, systems are the problems. There were perceived performance issues of an application because the client’s mouse driver was slow (that nice 🙂 ). Empirical evidence trumps intuition, experience and guess work. You need to so look more broadly.
7. The Deity
God classes (we speak of appr. 45 kLOC long classes), because it’s easier to search if you have everything in one file.
Create components based on SOLID principles. If you understand the code that you wrote three weeks ago at 3 am in the morning – that’s good. Most programming is maintenance programming. A good approach is to get somebody outside of the team or product and just walk through the code with him. It shouldn’t take 20 minutes to identify the part of the source code that needs to be enhanced. Another good method is naming, naming, naming. E. g. use a noun scanner to scan all the class names. If there are names with implementation details like “List” or “Collections” you did something wrong.
8. Lean Startup Ninja
Compiles? Ship it! Let your users be your testers.
Continuous Delivery could be a huge business enabler, but it influences the entire organization. Start at least with Continuous Integration. General rules: It’s easier to apologize than to ask for permission.
9. CV++
Just add more and more technology to your CV through learning on the job (TIOBE index can help you here).
Just be good at software development principles. You can apply these to any programming language. Be a software developer instead of just a programmer: Understand the business problem and the environment. Unfortunately, there are still so many software developers out there that don’t care about the business’ problem. Technology is not the complicated part of software development. It’s important to develop systems that can take care of the various edge cases, trapdoors, shortcuts and fuzziness. Avoid developing brittle, inflexible models with later added exceptions and special cases – that leads to all the big messes we have now.
10. I Haz Cloud
Everything has to be in the cloud! Cloud, cloud, cloud, cloud!
Just evaluate it for your use cases.
11. Can Haz Mobile!
Quit your job and develop a mobile app!
Is there any use case that needs to go mobile at all? Think about the core problem instead of going to the next big thing.
12. BigData
NoSQL == BigData!
Think about your data: Do you really need a NoSQL-DB for your business? Or would it be better to rely on proven technologies? There is a reason why relational databases have been around for so long. And think about Ops. They have to support it, too!
Final words: Whatever you do: Take a deep breath – and think!