I just pushed source code accompanying my Refactoring in C# book to Github. Clone it here.
Parameterized tests in JUnit can be very useful when writing tests based on tabular data. These type of tests can save you from writing a lot of duplicate or boilerplate code. While there is a fair amount of articles on the subject on the Internet, I wasn’t able to find a code sample that you […]
I was curious when our client asked us to put our web flow definition files into the database. We used these files to define a basic navigation flows in our web application. To put it simply, our homemade framework was conceptually very similar to a Spring Web Flow. Such flow definition is a first class […]
Imagine the loss that is generated when projects are frozen, canceled or unused in production! How much profit and growth would a company achieve if all software they produce would to generate transactions in the production! The whole process simply reeks of waste. By insisting on initial requirements, not only are they making the life more difficult for the client, they are shooting their own foot. If these requirements do not result in software used in production by final client (not just deployed so that project can be marked as finished), they are losing money they could earn from charging transactions. By prioritizing requirements based on how late they are, they are making it more probable that these will come to production too late. Talk about waterfall double whammy!
one can not but wonder how come that some agile circles were not able to avoid the certification trap, when even some of the organizations that inspired the whole movement, were smarter than that?
It’s NOT OK to cut corners, but it’s OK to cut features.
I guess that sums a great deal that agile development is all about!
After hearing that UML is touted as a “next big thing” in Visual Studio 2010, I must admit I was less than elated. Since I am hardly a “new kid on the block”, I freely admit that I remember that quirky diagramming tool called Visual Modeler that shipped with Visual Studio 6.0. (“Ten years after” already?)
Sometimes I hear YAGNI principle invoked in a way that it is clearly misinterpreted. For example “Maybe you do not need to refactor this code just yet” or “Maybe you do not need all those unit tests”. Thing is, to be able to do YAGNI, you need to have your code refactored and covered with tests. You need continuous integration and automated builds. Without these practices, once you need to implement a new feature in JIT fashion, things will inevitably start to break,