We take a deep dive into the various forms of duplication and jump aboard the complain train as Allen complains about Confluent’s documentation, Michael complains about Docker’s documentation, and Joe complains about curl.
How are you reading these show notes? If you answered something similar to your podcast player, you can find this episode’s full show notes and join in the conversation at https://www.codingblocks.net/episode106
- O’Reilly Software Architecture Conference – Microservices, domain-driven design, and more. The O’Reilly Software Architecture Conference covers the skills and tools every software architect needs. Use the code BLOCKS during registration to get 20% off of most passes.
- Clubhouse – The first project management platform for software development that brings everyone on every team together to build better products. Sign up for two free months of Clubhouse by visiting clubhouse.io/codingblocks.
- Datadog.com/codingblocks – Sign up today for a free 14 day trial and get a free Datadog t-shirt after creating your first dashboard.
Survey Says …
Anonymous VoteSign in with Wordpress
Why don't you go to conferences?
- Too expensive. Gotta think about that ROI.
- Too far. I could finish an entire Coding Blocks podcast just getting there.
- What about both of the above? Oh, that's this option.
- But I do go to conferences. Why can't I participate in the survey?
- To everyone that left us a review, thank you:
- iTunes: MinimallyViablePacemaker, dude_scott
- Stitcher: brianp
- Feel like kicking us in the shins? Here’s your chance:
- Joe will be speaking May 16th at the Orlando .NET User Group, giving his talk Introduction to JAMstack. (onetug.org)
- Allen will be speaking June 24th at the Atlanta Intelligent Devices meetup, giving his talk Moving from Batches to Real Time with Apache Kafka. (Meetup)
The Evils of Duplication
- Change is constant.
- We spend a large part of our time in maintenance mode.
- Maintenance is a part of the entire process – it happens daily, even while we’re writing the initial code and get new requirements.
- It’s easy to duplicate knowledge: in the specifications, the code, etc.
- DRY Principle (Don’t Repeat Yourself).
- Every piece of knowledge should have a single, unambiguous representation within a system.
- Repeating knowledge in your code means … it’s not a question of if you’ll forget about the multiple places to maintain, it’s when.
- The authors make the point that DRY is one of the most important tools/principals in the book.
How does duplication happen?
- Imposed – Programmers feel like they don’t have a choice.
- Inadvertent – Programmers didn’t realize they were doing it.
- Impatient – Laziness.
- Interdeveloper – Multiple people doing it and don’t realize it.
- Using a code generator to build code from some common set of metadata can help protect you from this form of duplication.
- Some examples:
- Documentation in code.
- Bad code requires a lot of documentation.
- A lot of documentation often becomes stale as the code changes, leading to lies!
- Possibly generate code from your documentation.
- Problems with the language itself
- C, C++, Pascal require separate header files with declarations and then the implementation files with the code for those declarations. No way around this really.
- Just make sure you’re not putting the same comments in each file. Doing so would be a waste and likely a place where something will be forgotten over time.
- Some examples:
- Accidental denormalization of data – same attribute in multiple layers that are related.
- This can also happen with mutually dependent items.
- The authors point out that sometimes this is necessary due to expensive calculations that you want to cache for performance reasons.
- If you need to do this, encapsulate that information. Don’t expose the property directly, but instead use accessor methods. That way your storage and retrieval of the data is transparent to the consumer of the data and you can implement it however you like.
- “… short cuts make for long delays.”
- Some examples:
- Using the same literal in multiple spots.
- Copying and pasting source code from a standard implementation and tweaking just a bit.
- It takes discipline to avoid this type of duplications but doing so will save a lot of time in the long run.
- It’s very common for this to happen when multiple developers are working on multiple applications.
- How to solve?
- Clear overall vision.
- Strong project leader.
- Division of responsibilities.
- That still doesn’t solve all of it. When there’s functionality that doesn’t “live” in one of those core responsibilities, it often has a good chance of being duplicated.
- Methods that help:
- Open and frequent communication between developers.
- Appoint a project librarian (or group?).
- Have a central place in the source tree where utility scripts live.
- Take care that this doesn’t become a dumping ground.
- Continually explore other’s source code and be a part of PR’s and code reviews.
- Make it easy to reuse.
- If you don’t make it easy, people won’t reuse it.
Resources We Like
- The Pragmatic Programmer by Andrew Hunt, David Thomas (Amazon)
- The Pragmatic Bookshelf (pragprog.com)
- Public Variable vs Public Property – Clean Code the Right Way (YouTube)
- Spotify engineering culture (part 1) (Spotify Labs)
- Email Address Regular Expression That 99.99% Works. (emailregex.com)
- Customize your Visual Studio’s start page:
Tip of the Week
- Use multiple mediums to learn, such as, podcasts, YouTube, online courses (Udacity, Udemy, Pluralsight, etc.), books, writing (blogs, wikis, etc.), and side-projects.
- Google Docs have version history! You can find the history options from within the document’s File menu (File -> Version history) or by right clicking on the file and selecting View details.
- Use flowchart.js to create a SVG flow chart diagram from a textual representation. (flowchart.js)
- Use SHIFT+Right Click on a file in File Explorer to select “Copy as path” as well as other options. Who knew Microsoft took a page out of Apple’s playbook and started hiding options in the UI.