June 2007 - Posts
I turn 31 today, gee I am getting old.
Vadim has a post on open development postions at his work place, ulimate software. If you want to work in an Agile enviroment, using MbUnit every day and working along side a core member of the MbUnit team then check it out.
My hat off to Jeff Atwood for offering to help fund (matched by Microsoft no less) OSS. Each project has its own costs, often met by the folks on the project (including out of my own pocket) so every single cash donation is a great help of keeping those costs down. I would also like to make sure that folks get there money back so please do pass your vote on MbUnit.
A few folks have asked about Frans comment in this post, in particular this.
MS has such a strong focus on controlling the market ontop of its own platform, they're totally not interested in changing the mentallity of mort at all. There are numerous examples out there, nunit and ndoc being two of the most well known. Instead of supporting nunit and mbunit, MS rolls their own unittest runner, incompatible with the open source ones, and hires the mbunit main developer.
No I have no red pill, Frans is of course talking about Peli. Let's not also forgot that Microsoft also hired James Newkirk, who was one of the orginal NUnit developers. Neither Peli nor James are working on MSTest, although Peli is doing some amazing work at MSR in field of testing now there hires were not an attempt to rock the boat but a chance to get great talent. The projects of course continued to grow, with Charlie at NUnit's helm and me at MbUnits, should we no longer do this job (red pill for example) then someone would talk the helm, that is nature of a organic OSS project.
Scott has a amusing post on the new shiny ADD approach.
My CI server of choice has gone 1.3 final. Grant has a great post on his integration queue work.
We all know about the Joel test but what's the reverse, I give you the cowboy test.
-
You like beans and moonshine (often mixed)
-
No source control.
-
No code design (that meets any notation) of any kind
-
No automated tests of any kind
-
No automated release mangement of any kind
-
No spec/stories/requirements of any kind
Anything I missed?
Its rare that folks travel with out a map, even those in the outback have mental map of where they going (and its not like norman briggs from new york is doing the walk about, he would be croc food very quickly). So would you code before having any idea of what your doing? You must have at least have a vage idea, it needs to do XYZ but unless you know 100% what XYZ are then that means lots of room for movement on what XYZ is from your customer (could be your boss for example) and the time it took you to develop XYZ goes up and up each time XYZ changes
and up
and up
Thats a costly business but at the the other end of the scale it be costly too. In some organizations, change control is a serious busines (windows start button any one ;-)) with lots of levels of consideration of impact (big design up front approaches can glue this in). In other organizations there is non, it just happens (ad-hoc). In others the methodology can flex to the requirements.
What does this mean exactly? Well in the agile world there is a notation of iterations, the basic premise is that in a given iteration a given set of functionality is set with each user requirement (called user stories) marked on cards\paper\whiteboard\drinks mats etc. Should the customer (this could be your boss) wish to change something then that is marked on the cards for the next iteration. When the iteration is finished the next iteration begins and so on. This is different from ad-hoc in that each requirement is marked down so even though they are changing you still know what those requirements are. So how long is iteration? Often you will agree what wil be implemented in your card set so you achieve your milestone, very often you will get to the point of releasing your prodict by the end of iteration. Agile methologies do vary in gudience on setting this, very often with pair development the iteration can be very short (weeks) but lets not run before we can walk. If your boss is asking for changes every day then you set your iteration to daily and try to convince your boss to work daily. If your making releases daily or weekly then your customers customers (your boss's customers) can see the product moving and vitally you have records of what the system is suppose to be doing.
Vitally with each requirement you can create a base line of tests to meet that requirement, if the requirement changes you change the test in accordance and refactor your code to meet the test. That same test can be run by you, or another member of the team in automated and repeatable fashion.
In pattern terms there will be a few patterns for visual interface layering that you heard of, MVC, MVP, Humble Dialog etc. I was talking with Howard one night and he mentioned his interest in a MVP variant called Presenter First. This variant incrases the layering of MVP triads in the pattern and brings a more TDD approach to the pattern. The paper is a must read as is the interviews the authors had with Ron Jacobs, there is also further examples here and here.
On a related note visual interface patterns for me still seem to fail the issue of dealing with threads and managing an interfaces behaviour in a thread, I was talking this through with Jeff and he later blogged his thoughts here.
Here is a question, how much time did you spend in the debugger today?
Lets say for a 10 hour project you spend on average 1 minute of every hour in the debugger. Of course this is a guess, if your writing code from scatch then you won't spend as often in the debugger as you aready have a mental note of where you need to set watches and breakpoints. Come back to that code in 6 months or debug someone elses code and you will be spending a lot longer trying to set breakpoints, stepping over/through etc. Even with user requirements helping point you in the right direction it will take time to figure out whats going on (and with out user requirements it's even more puzzle solving time).
Those that unit test there code, agile or otherwise will likely be saying I have spent less than a minute to no time at all in the debugger today. They will have had the inital time hump of learning what the code is doing, but it's likely a good set of user requirements and concrete set of tests allowed them to zero in on an area of functionality a lot faster than a trip with the debugger would. Further more, with the tests telling the developer what the code is supposed to do in accordance with the user requirements of the system, a developer can change\refactor the code with out fear of introducing new bugs or breaking the code completly (and changing the code in a tool like VS with td.net is zero friction, refactor, right click on the test method, run, green move to the next change, red go fix and repeat - before you commit). Refactoring with out effective regression is like swimming with sharks with your arm hanging off).
But I get ahead of my self, 10 minutes in the debugger out of your 10 hour project. Lets say that for every hour writing code you spend that 10 minutes writing tests instead. You can still find and eliminate bugs as you go, but you're also spending the time making sure that the tests for your code are automated and repeatable. Lets now say that 6 months on someone else has 1 hour of refactoring to make on the project. According to our average thats 1 minute in the debugger, but given that this person has never seen the code before it will likely be longer. However with our automated regression suite, it's likely going to take only a few seconds to run the tests and see if anything is broken, on average the developer is saving time. If the developer adds bugs through regression failures or spends time figuring out the code then this time scale goes up.
More Posts
Next page »