- Code Review During Retrospective Most of the retrospectives I've kept or participated in were about agile approaches (for example communication with the Product Owner) and organisation-related changes, but not everybody is into these. Most software engineers and craftsmen aren't that interested in how to deliver faster, or how to communicate better, they are interested in how to be better at their profession: programming.
more...
- How to Narrow Down What to Test An old friend told me that they did not do automatic testing at her company, or any kind of testing for that matter, because in terms of money they are better off if they do ad hoc testing and bug fixing one week prior to the delivery date. Then I got into an interesting discussion where the topic was that the customer does not pay for tests, she pays for a working software.
more...
- Pair Programming in Retrospect I've been doing pair programming for two years now. During this period I gained a lot of experience, so it is time to do a little retrospective and organize these experiences. I hope that you find something useful here, or even better, you may start to do pair programming.
more...
- Basics of Code Review I'm going to keep a workshop about code review for my colleagues so I've collected every idea, practice, suggestion, recommendation into this post. Any comments and suggestions are welcome.### AbstractIn this article, I would like to talk about some code review techniques which I consider useful when changes or bug fixes have to be reviewed in legacy code.
more...