Log In
Or create an account -> 
Imperial Library
  • Home
  • About
  • News
  • Upload
  • Forum
  • Help
  • Login/SignUp

Index
Understanding Software
Table of Contents Understanding Software Credits About the Author www.PacktPub.com
eBooks, discount offers, and more
Why subscribe?
Customer Feedback Foreword One. Principles for Programmers
1. Before You Begin…
If You're Going To Do It Then Do it Well
2. The Engineer Attitude 3. The Singular Secret of the Rockstar Programmer 4. Software Design, in Two Sentences
Two. Software Complexity and its Causes
5. Clues to Complexity 6. Ways To Create Complexity: Break Your API 7. When Is Backwards-Compatibility Not Worth It? 8. Complexity is a Prison
Three. Simplicity and Software Design
9. Design from the Start
Starting the Right Way
10. The Accuracy of Future Predictions 11. Simplicity and Strictness 12. Two is Too Many
Refactoring
13. Sane Software Design
The Wrong Way
Analysis of The Wrong Way Bringing It To a Group
The Right Way We followed all the Laws Of Software Design
Four. Debugging
14. What is a Bug?
Hardware
15. The Source of Bugs
Compounding Complexity
16. Make It Never Come Back
Make it Never Come Back – An Example Down the Rabbit Hole
17. The Fundamental Philosophy of Debugging
Clarify the Bug Look at the System Find the Real Cause Four Steps
Five. Engineering in Teams
18. Effective Engineering Productivity
So What Should You Do?
The Solution
Credibility and Solving Problems The Blocker Moving Towards the Fundamental Problem
19. Measuring Developer Productivity
The Definition of "Productivity" Why Not "Lines of Code?" Determining a Valid Metric What About When Your Product Is Code? What about People Who Work on Developer Productivity? Conclusion
20. How to Handle Code Complexity in a Software Company
Step 1 – Problem Lists Step 2 – Meeting Step 3 – Bug Reports Step 4 – Prioritization Step 5 – Assignment Step 6 – Planning
21. Refactoring is about Features
Being Effective
Setting Refactoring Boundaries
Refactoring Doesn't Waste Time, It Saves It Refactoring To Clarity Summary
22. Kindness and Code
Software is about People
An Example of Kindness Be Kind, and Make Better Software
23. Open Source Community, Simplified
Retaining Contributors
1. Don't freeze the trunk for long periods 2. Turnover is inevitable 3. Respond to contributions immediately 4. Be extremely kind and visibly appreciative 5. Avoid personal negativity
Removing the Barriers
1. A list of easy starting projects 2. Create and document communication channels 3. Excellent, complete, and simple documentation, describing exactly how a contribution should be done 4. Make all this documentation easy to find
Getting People Interested
Be a super-popular product Be written in a popular programming language
Summary
Six. Understanding Software
24. What is a Computer? 25. The Components of Software: Structure, Action, and Results 26. Software Revisited: (I)SAR Clarified
Structure Action Results ISAR in a Single Line of Code Wrapping SAR Up
27. Software as Knowledge 28. The Purpose of Technology
Are there Counter-Examples to this Rule? Is the Advance of Technology "Good"?
29. Privacy, Simplified
Privacy of Space Privacy of Information A Summary of Privacy
30. Simplicity and Security 31. Test-Driven Development and the Cycle of Observation
Examples of ODA Development Processes and Productivity
The First ODA
32. The Philosophy of Testing
Test Value Test Assertions Test Boundaries Test Assumptions Test Design End to End Testing Integration Testing Unit Testing Reality Fakes Determinism Speed Coverage Conclusion – The Overall Goal of Testing
Seven. Suck Less
33. The Secret of Success: Suck Less
Why is it that this worked?
34. How We Figured Out What Sucked 35. The Power of No
Recognizing Bad Ideas Having No Better Idea Clarification: Acceptance and Politeness
36. Why Programmers Suck
What to Study
37. The Secret of Fast Programming: Stop Thinking
Understanding Drawing Starting Skipping a Step Physical Problems Distractions Self-Doubt False Ideas Caveat
38. Developer Hubris 39. "Consistency" Does Not Mean "Uniformity" 40. Users Have Problems, Developers Have Solutions
Trust and Information Problems Come from Users
41. Instant Gratification = Instant Failure
Solving for the long term How to Ruin Your Software Company
42. Success Comes from Execution, Not Innovation 43. Excellent Software
1. Does exactly what the user told it to do 2. Behaves exactly like the user expects it to behave 3. Does not block the user from communicating their intention Excellence is senior to (but is not in conflict with) code simplicity
Index
  • ← Prev
  • Back
  • Next →
  • ← Prev
  • Back
  • Next →

Chief Librarian: Las Zenow <zenow@riseup.net>
Fork the source code from gitlab
.

This is a mirror of the Tor onion service:
http://kx5thpx2olielkihfyo4jgjqfb7zx7wxr3sd4xzt26ochei4m6f7tayd.onion