Planning for change

Building software is fun, but building something that is easy to maintain and reason about can be a real challenge. Coming soon I will be taking a journey through an entire application, from inception and feature discovery through to deployment, with all the fun and frustration that comes with that. I wanted to title it “Change is the only constant” but it turns out there’s a really good book on calculus with that title. So for now the title is “planning for change.” Here is a preview of the ‘chapters’ I see coming out of this adventure:

  1. Inception, and figuring out what MVP is
  2. Platform choice, there’s value in using what you already know
  3. Don’t try to build a skyscraper on day one
  4. First feature
  5. Writing automated tests
  6. Deploying what we have
  7. Why early user feedback is important
  8. First refactor for maintainability
  9. Authentication doesn’t need to be so freaking painful
  10. Discovering new requirements
  11. What is this Domain Driven Development thing all about?
  12. Complexity is increasing, time to refactor again
  13. Why Dependency Injection is so powerful
  14. Bounded contexts and SOA
  15. CQRS for fun and profit
  16. Refactoring our tests to make it easier to add more
  17. Going mobile
  18. Side trip down response formatting lane
  19. SignalR makes life more interesting
  20. I don’t know how to pronounce it, but man I love Redis
  21. Distributed systems can be fun
  22. Eventual Consistency where it makes sense
  23. Moving to microservices
  24. Different databases for different problems
  25. Deployment update
  26. Cashing in on response caching
  27. Getting the most out of my favorite database

Leave a Reply

Your email address will not be published. Required fields are marked *