Pragmatic Programmer : Chapter 2 - A Pragmatic Approach

 The Pragmatic Approach talks about the steps for architecting and planning how to do your development. At times these chapters can seem like a hodgepodge of subjects, but when you consider all of these steps before you start developing, they can be some of the most basic and important steps in development. 

Setting the pace and expectations are key for getting the business and development team in line together, so by these simple steps, the teams can function optimally.

8. The Essence of Good Design - Good design is easier to change than bad design. It sounds so simple, so why don't I think about it more? This is a great way to present to people a way to handle the design of their code and libraries. I should be able to swap out different layers and UIs and not have to worry much about the behavior of unrelated pieces being impacted. 
   In the past, I always used the idea of Automated Unit Tests for keeping abstraction in place, but this is an even better ground rule of handling things that I want to use in the future.
9. DRY - The Evils of Duplication - Duplication is inevitable when you work on teams. Sometimes people have things out there that you're unaware of, sometimes someone copies and pastes code repeatedly into the codebase - these are things we need to work at preventing.
   The part I found very interesting is that the idea that documentation itself is a form of duplication. It makes sense and I never thought about it that way. It almost feels like if we can auto-generate as much of our documentation as possible, that we could greatly reduce the duplication. 
   This is a new idea to me that I'm going to spend a lot of time thinking about going forward in my development career, and come up with different ways of not having the same information in my documentation and my codebase.
10. Orthogonality - We're drifting into the idea of the Single Responsibility Principal of Solid Design. I love the analogy of the helicopter levers impacting each other.
    There's a lot of good strategies for handling orthogonality, and it even talks about the singleton pattern which can lend itself to its own challenges. 
    This comes down to small, focused pieces of code. Know what it is doing and have it do just that. If a client can have multiple accounts, those functions need to be separated. If an address can belong to a client and a customer, then they must be separated. If a mailing address can be international or internal, they must be separated. They're going to have different functionalities with different requirements, like postage or customs. Changing postage shouldn't impact internal mail. 
11. Reversibility - Reversibility and having a flexible architecture is more and more important as technology advances. Containerization is drastically showing that, and abstracting away as much as you can is going to be critical for your codebase. You may have some infrastructure code, data access code, business logic - be prepared for it all to change dramatically.  Make no mistake, this is all about abstraction. 
12. Tracer Bullets - I use tracer bullets without even thinking about it. Recently with the different variations of .Net Core, and the .Net Framework, its very easy to get confused with libraries and what can reference what. I work with older assemblies and I tie into new pieces that run on linux based machines. Making sure everything can communicate, getting those basic lines of communication in place are critical. 
    Building your project framework, showing the integration, and getting those basic pieces down early are absolutely critical to not having to go back in 6 months and change the foundation.
13. Prototypes and Post-it Notes - I'm very hesitant to do any sort of prototype in any technical tool. They always seem to end up being used in production or how they were not intended. The business does not care about architecture, just that something is working right now.
    That's why I love the idea of wireframes, post it notes, Power Point presentations and mock ups. They communicate quickly the idea of how something should behave, and they cannot be deployed.
14. Domain Languages - I don't have a ton of experience with Domain Languages in terms of planning. I've used Given When Then statements, and SQL, but often times, I feel in the planning stages, they can become overwhelming. I'd like to get some more experience with these and understand their benefits a bit more.
15. Estimating - If naming things is the hardest thing in development, estimating may be number two. Estimating different tasks and  when things will be completed requires so much and often you don't have enough to formulate a proper estimate. You can add in caveats and assumptions, but when those are wrong, and you miss your deadlines, it is my experience that you will pay. The time for estimates, and post-mortems would be better spent ironing out what needs to be done, and actually developing.
    Now that isn't to say all estimation is bad. After all, effort must be distributed appropriately to get the best bang for your buck! I do like the idea of tracking your estimates, and keeping track of how long you spend on different tasks. But again, time consuming.
    I also love the idea of regularly updating the schedule with the code. Being able to accurately project when something is done has value, but things change so fast and frequent, projecting more than a couple of months in advance doesn't seem greatly beneficial to me.