This post started out to be a reply to another blog post about some detail of the red/green/refactor cycle in TDD. It ended up as a fairly extensive description of my own personal practice of doing TDD in C#, featuring quite some VS add-ins and discussing some (real-world) aspects of test-driven development along the way...
Yesterday, I occasionally stumbled upon miniSCRUM, yet another free online Scrum tool. It's different from its siblings in that it only provides the bare minimum of Scrum features, and it's therefore dead simple and totally intuitive in its usage. This makes it perfect for individual developers and as a starting point for trying Scrum and iterative project planning/estimating...
Most people - even the overwhelming majority of programmers - would say that the main activity of a software developer is "writing source code". But this is a fatal misconception - about 75% of all time and money (sometimes even more) is spent on some sort of maintenance activity. Far too little effort goes in the future maintainability of a software product during actual development, which in turn leads to software systems that cause substantial technical and financial problems..
A developer might occasionally write down some informal piece of text during development. This post shows a method how such ad-hoc produced content can easily be integrated and referenced in a test report...
A situation, that most developers might know from personal experience: The project is nearing the deadline, and there is far too much work left to be done. Usually the consequence is, that the remaining features of the software will be implemented in a quick-and-dirty way, leaving aside quality related issues like e.g. proper design or adherence to coding standards for the moment. - Much of today's spaghetti code is born this way. The common excuse for that is: "We'll do that later. Now our first...