1 / 87

Pragmatic Software Development Curing the Architecture Astronaut

Pragmatic Software Development Curing the Architecture Astronaut. Cory House bitnative.com/ kcdc | @ housecor. We have a problem. I learned something new…. I will use this EVERYWHERE. When you go too far up, abstraction-wise, you run out of oxygen. Joel Spolsky. Astronaut Assessment.

dezso
Download Presentation

Pragmatic Software Development Curing the Architecture Astronaut

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Pragmatic Software DevelopmentCuring the Architecture Astronaut Cory Housebitnative.com/kcdc | @housecor

  2. We have a problem.

  3. I learned something new… I will use this EVERYWHERE

  4. When you go too far up, abstraction-wise,you run out of oxygen.Joel Spolsky

  5. Astronaut Assessment We must use <shiny new technology> for this! Reinventthe wheel 100% test coverage NeverORM Alwayscode to an interface Use all the patterns

  6. X is good It Depends

  7. What’s An Expert? Anyone can design a bridge that stands. It takes an engineer to design a bridge that barely stands.

  8. Reasons to Select an Architecture To experiment To challenge myself To improve my resume´ Save Money Save Effort Save Time

  9. Two Simple Goals

  10. Assumptions Web based Enterprise line-of-business app RDBMS

  11. Pragmatic Architectural Thinking

  12. Which should we choose?

  13. It depends.

  14. What if I said… $250k over budget Customers hated it, or worse, ignored it Project funding dried up 1 month late = worthless

  15. Metaphors for Architecture Selection

  16. Time to set up?Training? Necessary tooling? Large enough to warrant “prep time”?

  17. More effective?  More efficient?  Least expensive?  Most flexible? Most scalable?

  18. Lighter? Quicker to set up? Cheaper? More risky? Faster?Requires training?

  19. Experimental? How permanent is this solution? How big is the project?

  20. Considering Complexity

  21. Consider Complexity

  22. Complexity Complexity ~= Lines of code 010101110101111101011101 011010111010111010110100 010111101011101101011101

  23. Complexity != Bad

  24. Complexity must be J U S T I F I E D

  25. We’re paid for solutions, not code.

  26. Pay a Little Now…

  27. The Argument for Simplicity

  28. Parkinson’s Law: Work expands to fill available time.

  29. Simplicity: The art of maximizing the amount of work not done.

  30. Consider Simplicity Do simplest thing that could possibly work / KISS Lean principles 80/20 Rule Minimum Viable Product (MVP)

  31. Do Simplest Thing That Could Possibly Work Get done sooner Easier to communicate Duplication is obvious, so needs for refactoring are clearer Tests are easier to write Code is easier to performance tune  You feel less stress, which enhances all of the above http://xp.c2.com/DoTheSimplestThingThatCouldPossiblyWork.html

  32. Consider all solutions to your task that could possibly work. Implement the simplest solution.Refactor from there if and when needed…you will always wind up with a system that is just right for what it does so far…nothing added that isn't needed.  Ron Jeffries

  33. 80/20 Rule Get 80% of the benefit from 20% of the features? Get 80% of the benefit of automated testing by testing the most important 20%?

  34. Lean Principles Not adding value to the customer? It’s likely waste. Choice unclear? Choose the simple option. Ideal architecture varies by team Automated testing Source: “Lean Software Development” by Mary and Tom Poppendieck Eliminate waste Amplify learning Decide as late as possible Deliver as fast as possible Empower the team Build integrity in See the whole

  35. Minimum Viable Product (MVP) Goal: Validated learning What was the response? What did they like? Hate? How much profit? Is this worth scaling? Bad assumptions? Do we need to pivot?

  36. Minimum Viable Product (MVP) • What we don’t care about • Scalability • Maintenance costs • And often • Beauty • Code cleanliness • Full feature set • Performance • Security • If it even actually works!

  37. Timelines

  38. Agile Architecture: Flex One Features Architecture Reuse Performance Security Testing Scalability Documentation Technical Debt (and other issues) Blown Budget Missed deadline

  39. Assuming deadline, manpower and scope are constant: Software quality == deadline sanity. Quality software requires realistic deadlines.

  40. Q: Is debt bad? A: Is the deadline hard?

  41. Hard vs Soft Deadlines Trade show Published advertising X-team dependencies 1st to market or dead Network effects Single loud customer Wild guess Salesman misspoke MS Project said so

  42. Part 1: Summary • Defined complexity. Neither good or bad. Must be justified. • Parkinson’s Law • Arguments for simplicity • Timelines may dictate potential complexity and quality • Hard vs soft deadlines

  43. Architectural Levels

  44. Web Forms, MVC, WPF, WinForms, Silverlight Web API, WCF, ServiceStack, POCOs C#, VB.Net, F#, IronRuby, IronPython Entity Framework, nHibernate, LLBLGen, Dapper, ADO.Net

  45. Layers vs Tiers Logical Physical or virtual

  46. Tiers Web Server DBBoxes

  47. Tiers Scalability Security Uptime Reusable Performance cost Increased complexity

More Related