Agile non-negotiables are those software engineering practices that you'd be crazy to go without.
Unit Testing: Knowing your code works
Refactoring: Paying down your Technical Debt
Test-Driven Development: Knowing what your Goal is before Coding
Pair Programming: Tightly binding review and development together
Continuous Integration: Making it Production Ready
I'm a little crazy. I don't always use all of the above practices. I try to but my desire to be a hero and get things done quickly overcomes my sensible side. I think most people do this too. There are always outside influences that can seduce a developer into over promising.
The argument for ignoring those outside influences and always practicing the above agile non-negotibles is that you will have:
- better quality code,
- more consistent deliveries, and
- less bugs.
Stop worrying about taking three days to develop something that might have took two days had you left out unit testing or refactoring. That is only a short term savings. Consider how long it will take to fix a missed bug or add a new feature next year.
Using the above practices is an investment in the future of your software.
Jerry Yoakum's thoughts on software engineering and architecture from experience working with code, computer science, python, java, APIs, NASA, data mining, math, etc.
Wednesday, September 14, 2011
Sunday, September 11, 2011
Pair Programming
I'm a big fan of pair programming. I have used it many times and almost everytime the result was better code that was developed faster. Pair programming is like having continuous code review.
Sadly, there is a lot of controversy with this particular agile/XP practice. Seeing two valuable resources sitting down at one computer makes most managers nervous. They think their team's productivity has just been halved. The worst thing about this mentality is that it makes it clear that the manager thinks programming is just typing.
Mere typing, programming is not. A good idea or a bug caught early on in the process can save a team a lot of work and rework later. By pairing you share valuable knowledge and practices throughout the team, catching more bugs early, and increasing code quality.
Sadly, there is a lot of controversy with this particular agile/XP practice. Seeing two valuable resources sitting down at one computer makes most managers nervous. They think their team's productivity has just been halved. The worst thing about this mentality is that it makes it clear that the manager thinks programming is just typing.
Mere typing, programming is not. A good idea or a bug caught early on in the process can save a team a lot of work and rework later. By pairing you share valuable knowledge and practices throughout the team, catching more bugs early, and increasing code quality.
Subscribe to:
Posts (Atom)