- Posted by mateid on August 8, 2010
I’ve been away on vacation for the past week and now I’m back to work. It’s amazing how refreshing a few days off can be, and I’m pretty pumped to be back on my project. Some time off also helps put things in perspective. I can think clearer and see some beginnings of anti-patterns that are making their way into our team’s daily activities. Some of them are mostly related to attitude rather than technical issue and they need to be stopped as soon as possible. I was lucky enough to be on a very difficult project recently where I’ve learned a lot, and I want to talk about how we used to deal with similar challenges. One sentence sums it up: don’t be dogmatic, be pragmatic.
We’re looking at a fairly small project, with lots of front end development using MVC2 and jQuery. Lately we started having some discussions (some of them very heated) about our test coverage, pairing, technical debt and so on. We are starting to fall into the dogmatic trap and I don’t think our project will benefit much from it. Some members of our team expect 100% test coverage, pairing all of the time and zero technical debt. Heh, one can dream! But remember there is a price to pay for these things, they don’t come free.
Take the test coverage for example – the team is somewhat split on this issue: some think that 80% is good enough, others insist that we must be close to 100%. Personally I find myself in the 80% camp. I think to expect 100% test coverage is unrealistic. Test coverage is just another tool to tell me if my tests are covering the code base adequately. If we’re hovering around 80% and I can refractor easily and the test suite is highlighting issues consistently and effectively I am happy. I’d rather spend my time delivering business value than refining my test suite. If on the other hand we’re having issues that go undetected until late in the QA cycle or worse, than yes I wholeheartedly agree we need to work on our test suite and perhaps improve the coverage in troublesome areas. But asking for 100% test coverage is dogmatic and not very helpful to the client. Ask yourself if setting unrealistic expectations for coverage is helping you deliver business value more effectively. When will the client benefit from the activities you’re engaged in and how much value are they going to get in the end? I think this is pretty much the ultimate measuring stick when working on an agile project.
Another good example is technical debt. Say we have about 10% of our code that is somewhat sketchy. It doesn’t really hurt us on a day to day basis but it definitely is high up on the refactoring list. What do you do? Spend the next three days refactoring it or pick up a story and deliver a couple more points? I know it can be a tough choice - the code going into disarray or delivering a few ore points. Here the team is again split. Some think the code is fine, others cry bloody murder, this abomination needs fixing now! Remember this particular piece of code is not hurting us right now. To me the smart and agile thing to do is take note the offending area and deliver business value. I’m not saying sweep it under the carpet! Just deal with the issue pragmatically. If you’re having a hard time justifying refactoring it now than make a low priority tech task and deal with it later. There will be ups and downs in the iterations and an opportunity to fix it will definitely open up.
Don’t be dogmatic, be pragmatic. There will probably always be those that ask for 100% test coverage, zero technical debt etc. Just remember that every project is different and pragmatism will serve you much better than a dogmatic attitude.
- Posted by mateid on March 31, 2009
Why is it that many development shops still do not practice agile? What makes adoption so slow even today after so many successful projects? There are countless evangelists out there preaching and demonstrating the practices yet it seems that the old ways of waterfall like development are anything but numbered. Even worse, there are plenty of shops out there that claim to practice agile, and ignore some of the most basic principles – first one that comes to mind is continuous improvement. Ever dodging that post mortem, perpetually avoiding those tough questions – are we delivering value to our customers? Is our software maintainable, flexible, can it respond to the clients rapidly changing needs, particularly in this difficult economic climate?
A small startup will wither and die if they’d be providing these subpar services to their customers. Some large corporations, unfortunately, seem to benefit from inertia and continue to do business as usual. Are their customers not demanding enough? Do they continue supporting them in hope that one day they will get what they pay for? It can’t be the customers, after all our services haven’t been an astounding commercial success.
I’m not even sure where this was going. Suffice to say I’m a string believer in sustainable development.
- Posted by mateid on March 30, 2009
This is a re-take of one of my posts to the ALT.Net Google group. Probably a little of topic so I just want to capture it here, for future reference.
I'd like to throw in my two cents. I'm a TDD noob, so it might be relevant in this context. The point of the lengthy story that follows is that you can only lead a horse to water, as one of my colleagues likes to say when we discuss taking over the office with TDD. If one is not open to exploring new ways of doing things and discounts it right off the bat, no progress will be made. You can cite all the papers in the world, studies and research and successful projects, give examples, they will all be attributed to flukes, better funding, better building, better chairs, etc. People naturally resist change, and it will be rationalized in new and interesting ways all the time. I think the gap is not something the ALT.NET community can bridge. Each developer must try it first hand to experience the benefits. And try hard, because it’s not easy. For me the TDD showdown happened privately, I was both the TDD-er and the non-TDD-er.
That being said, big thanks go out to the folks on this board, and others, who’ve paved the way for me to become a better developer. I don’t think we’d be where we are now if it weren’t for huge contributions from guys like you. And for what it’s worth, I think the ALT.NET movement is doing a great job of moving forward the .Net world, and promoting continuous improvement. Read no further unless you have time for a rant.
I've been trying to promote TDD at work for the past few months. I've spent a lot of my personal time actually doing it to get hands on experience, scoping out different open source projects to get a feel for it (good vs bad unit tests, mocking, etc.) Here's one of the things that struck me in the learning process. I've been reading a lot - generally I agree with the literature on the benefits of TDD, but I was somewhat skeptical about the practical aspects - and accumulating a lot of theoretical knowledge. Still, when time came to write my first test I felt none the wiser. Complete writer's block – huh, where do I start kind of thing? So I've stumbled and tried and Googled and things started working together. I was pretty happy with the way things were going. Then I ran into things that needed testing that were doing a bunch of file manipulations. Uh oh, very unpleasant, no interface in sight in the System.IO namespace so no mocking. Gave up on TDD. Time passed, and I got uncomfortable with the lack of feedback. Yes, that is when I realized first hand that TDD was giving me something other than a bunch of asserts I could run and tell that everything was ok. Started TDD again, wrote wrappers for the System.IO part and wrote some integration tests on top of the unit tests to verify the files are handled correctly (I’m still not sure if this was the way to go, but it works pretty well in practice) and I was happy again.
A big moment for me was when I tried writing a validation framework. So I started with a little sketch of what I was trying to build. It had things like IRuleSet, IRule,IRuleResult and various implementations of those. Then I started coding, and wrote everything test first to see where it will lead. Well most of those things became superfluous. The problem I was trying to solve was much simpler – basically write a bunch of rules I could evaluate in a batch and tell a remote client everything that was wrong with their request in one remote call. Ultimately I just kept the IRuleSet<T> and expressed the rules as simple lambda’s that would return true or false. So I can do things like this:
1: IRuleSet<string> rules = new RuleSet<string>();
2: rules.Add(x => x.Length > 5, “Length must be greater than 5”)
3: .Add(x => x.Length < 10, “Length must be less than 10”)
4: .Add(x => x.Contains("TDD"), "Must contain TDD")
5: List<string> brokenRules = rules.RulesBrokenBy (“TDD Rocks!”);
I liked this better than the objects soup I initially cooked up, and it works very well with some caveats. I’m sure that this would have taken a lot longer to achieve without the TDD approach, as it made me realize what my real requirements were, and that I didn’t need all that complexity I was imagining in the beginning.
Lots more tests have been written since and lots more code. The overall quality has improved and getting better every day. It is however a process of continuous improvement and it takes work. It would be hard now to turn back and do thing the old fashion way. The one thing I could have used is a good mentor to provide some guidance. Failing that, I turned to ALT.NET and the huge contributions made by the members, and it’s helped in more ways than I can describe. Thanks again to everyone that uses their free time to contribute and guide other devs! Kudos! Sorry for the rant, and slightly off topic post.
- Posted by mateid on March 29, 2009
I was looking for a cool blog theme and I found a couple I liked. They make code look pretty crappy though, particularly longer lines in .config files and the like.I’ve decided that I’ll go back to Cogitation. Looks decent, and is very practical for showing code.
- Posted by mateid on December 10, 2008
I promised myself I’ll stop posting trivialities, but I feel compelled to discuss double versus decimal again. I see a lot of people use double or float for money amounts. Don’t! Double, or float for that matter, doesn’t have enough precision to handle financial calculations without a lot of rounding errors. The decimal data type provides significantly more precision than the other two. So if you are wondering where those pennies went, well it’s time to switch to decimal.
You should know that there are some performance penalties associated with this, as it is a 128 bit value. Also, ran into an interesting detail in the docs: the decimal struct is not guaranteed to be thread safe on all platforms! What gives? Apparently the value is too large to be assigned in one atomic operation. Does anyone know more about the mechanics of this? Please share!