This is part of a four part series of notes I took at Indy Code Camp on May 16, 2009. This year’s Code Camp consisted of five tracks each with five sessions. Track topics were SharePoint, SilverLight and WPF, Data Access, MIX highlights, and best practices. These notes are from the sessions I attended.
These notes are in no way intended to replace attending one of these talks if you have the chance.
Care About Your Craft: Adventures in the Art of Software Development
Presented by: Tim Wingfield – Quick Solutions
Tim’s talk focused on how to get better results out of each phase of the SDLC. Included here are key points from each section.
- TDD should not be thought of only as Test Driven Development but also as Test Driven Design
- Design with the SOLID Principles in mind
- Single Responsibility Principle
- Open/Closed Principle
- Liskov Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle
- Design by Contract – TDD can actually force us to do this
- Avoid programming by coincidence – Understand how and why something works
- Don’t be a plumber – Chances are good that someone else has had to save the same technical problem so there might already be a framework that can be used and let you focus on the actual business problem at hand
- Justify technology use – Don’t use a technology just because it’s new, use it because it better solves the problem
- You Ain’t Gonna Need It (YAGNI)
- Don’t waste time building features that might be used
- Quality is not an accident – build it into everything starting with requirements
- Don’t Repeat Yourself (DRY)
- Reuse code and avoid copy/paste programming
- Automate where ever possible
- Avoid finger pointing by taking collective ownership – We’re all in it together
- OUR build broke
- OUR defect
- Don’t live with broken windows
- Bad code begets bad code
- Fix problems when they’re found (time permitting) rather than letting them propagate
- Know when enough is enough
- Perfect is nice but software has to ship sometime
- Someone (QA or a customer) will find a defect
- When a defect is found, don’t panic
- Think about the solution before rushing to action
- Avoid placing the blame and work toward the best solution
- Always keep learning
- Suggested Reading: The Pragmatic Programmer
- Incorporate Agile practices
- Keep a full toolbox
- Maintain a positive attitude
- Be a mentor
- Create a culture geared toward continuous improvement
- Schedule lunch ‘n’ learns
- Have book reviews
Great recap, Dave. I especially like Tim’s take on collective ownership (OUR problem) and knowing when the development is ‘good enough’. There are plenty of blogs on that topic, and one of my favorites is from Yourdon: http://www.yourdonreport.com/index.php/2006/06/02/good-enough-reconsidered/Thanks for your contribution!
Thanks, Dave. I think both of the topics you mentioned were my biggest take-aways from the session.Thanks for the link. I’ll have to take a look.
Comments are closed.