Ever heard the phrase "At least it's consistant"? Next time you do, it's time to refactor.
Tuesday, February 10, 2004
Due to supply and demand the value of a developer changes with time. For developers to command a fair salary they have to keep up to date on their current market value. From a business perspective, most companies subscribe to "Pay as little as possible that will stop them walking out the door". The alternative is profit sharing. Pay someone depending on how well the company is doing and how much they contributed to that success.
Semco solution: Make all financial company info open (including everyones salaries). Train everyone in how to understand it. Allow people to set their own salary. You can be fired by your piers. Allow people to gamble a percentage of their salary in profit sharing. The more they gamble the more they profit when the company does.
There is an optimal size for every company. When it strives to expand and become all things to all people it cannot focus on achieving any of these things well. Divide the company into smaller more agile going concerns. Allow the parent company to use the services of the new company, OR any other company that is competitive. This drives down costs. Allow the new company to sell its services to other companies too. This makes them more profitable.
*original idea perloined from Maverick*
At the moment we have a build script here that uses a bunch of free tools. NAnt, CruiseControl.Net, NUnit, NMock, NCover(GDN), NDoc.
NAnt allows you to specify build scripts by defining targets and dependencies.
NUnit is a unit testing framework allowing you to automate execution of your unit tests.
NDoc produces documentation from the comments in your code.
CruiseControl.Net is a continuous build server. It monitors source control and when there is a change kicks off a build and reports any errors.
NMock is a component that uses reflection to dynamically generate a class that implements an interface.
NCover monitors the code coverage that is caused by a run of some code.
So... tying all this together. You use NAnt to automate a script that gets latest from version control, compiles the code, runs the unit tests, run the unit tests thought NCover, generate documentation for the code.
Cruise control does this every time the code base changes.
What you get? You verify that the code in version control compiles and satisfies all the unit tests. It also keeps an eye on the amount of code covered by the unit tests, so you can see if tests are missing.
FXCop. Microsoft made this tool to help ensure the code base complies to a set of coding standards and coding styles.
I just read a white paper about an agile approach to a legacy system (prompted by StranglerApplication by Martin Fowler). The team developed an application that started by delivering a small bit of needed functionality to address a problem with a legacy system. They integrated at the database level. This small offshoot from the legacy application then grew and grew. The success stems from not trying to re-write the existing system, but to implement business value specified by real users. The legacy system was always left running, but people just stopped using it as a compelling alternative was available.
Semco have no policies. This means that every team are open to do their job however they want. As long as the goals are achieved, who cares how you got there. By allowing variation in the approach taken, people are open to try things and see if they work. This reminds me of how evolution works. Mutate the best known solutions and see if they perform any better than their parents.
Why can't architecture be like this? We have several teams at work all blocked waiting for the ultimate 'architecture' to be put in place to allow us to develop. What is the worst thing that could happen if each team developed their application differently? They may have incompatible architectures! So? as long as they integrate with each other, and present themselves to the customer with a very similar interface, who cares if they are different?
I believe that through inter-team communication you would find that teams would start to cross pollinate ideas and so end up with much better solutions that any would have come up with alone. It would definitely allow us to start development, and not sit around wondering if the current proposition is the best solution.
People get paid for the hours they work. Contract role or permanent, it's still the same. Turn up, and get paid. You get more of what you reward. The feedback in this system is to make contractors work longer hours and permanent staff to leave as soon as their hours are up.
What if you rewarded achievements instead. Then all your employees would be focusing on how to improve processes and become more productive so they can get more rewards.
If you rewarded people on their individual achievements then this reinforces individualism. It would be better to reward teams as a whole. This would cause the team to focus on working together to achieve the goal in the most efficient way.
Imagine if your team signed up for chunks of work. Each chunk of work was worth a certain value to the business and so had an associated reward attached. The more the team gets done, the more the team gets paid. How do individuals get rewarded? The team should split the funds depending on how they feel each individual contributed to their success. Usually they would
split the money evenly. Occasionally they would reward individuals for outstanding work.
The hours you work is one of the resources you use to achieving your work. In what other situation do you pay someone for the amount of resources they use, rather than paying them for the outcome? Imagine I was a fork lift driver and I was paid for the amount of fuel I burned each day. Would this make me work harder? Would it make me get my work done faster? Would it make me put my fork lift up on bricks with the engine running?
You have a customer. They want you to make some software. They have a cool idea/vision. So they ask you... 'how much will it cost?'. The maths is simple..
Total cost = costPerDeveloperPerWeek * NumberOfDevelopers *
With XP the customer is asked to define requirements as stories. Each story consists of a description, an estimate of business value, and an estimate of complexity.
The stories are sorted in order of decreasing business value.
How many points can a developer get done in a week? Say its 1.
Say 1 week of work for a developer costs $2000 then 1 point/wk = $2000.
How much is the customer willing to spend each week? $6000 = 3 developers.
This then sets the amount of work done each week. You can now chunk the stories up into 3 point groups(iterations).
Evaluating business value of each iteration should allow the customer to decide at what point in the development cycle the customer is not getting enough value for their money to continue development. Alternativly they can see how much functionality they will have before their money runs out.
Problems: How do you know the velocity of the team (and hence the rate per developer)?
Experience is the only solution. If you have worked with the team before, then you can use those figures to start with. If not then make something up, and re-evaluate the situation after 3 iterations when you have some measurable statistics.
A convention is an accepted best practice to achieve a goal. Standards dictates the only acceptable way to achieve a goal.
In my opinion, if you wish people to be productive and focused you have to give them ownership of something. You should specify the level of quality you wish from the output, but don't dictate how something should be achieved. As soon as you specify the only acceptable method for achieving a goal, there is no room for creativity and ingenuity. These are the two resources that a company has to make use of to succeed, and no amount of money will convince someone to bring then to work. If there are recognised best practices to achieve a goal, then these should be shared. They should always remain conventions not standards.
In a recent effort to unit test a body of code that we are developing further, I was quoted Steven McConnells book " Rapid Application Development, taming the wild software development schedule". The gist of the quote was that touching code, no matter how wonderful it makes future efforts, brings risk to a project lifecycle that did not schedule it.
Steven McConnell is right to say changing code is risky. It's like walking a long balance beam. To be sure to stay on the beam progress has to be slow, and meticulous. If you make a mistake you get feedback in the form of the floor making its presents felt. The longer the time between creating the error and getting the feedback, the more it hurts. The solution is to reduce the time between creating the error and gaining the feedback. Lower the beam so it is only an inch from the floor. Once you have done this, there is far less risk, and you no longer have to make slow progress. Suddenly you are free to run along the beam, knowing if you fall, you can always get back on again. You gain confidence and courage.
In development the feedback is in the form of testing. The shorter the time is between writing the bug and detecting it, the less it costs to fix.
Acceptance testing your applicaion, and having a good QA team are great. However the bar is still a meter or two from the floor. By putting in place a suite of fully automated unit tests, and running them after every code change, you are able to catch unwanted changes to functionality as soon as they are made. As a result you are able to develop at a much faster rate, and make large changes to the code-base with minimal risk.
I have been developing a lightweight project management tool. This is the first real WinForms application I have witten. One aspect of the functionality I wanted was for the customer to be able to specify acceptance test scripts and run them to see progress of the functionality. By way of a bootstrapping experiment I have been developing this application Acceptance-test-first. The problem I keep having is that once I have the acceptance test in place, I am getting very lax about writing the supporting unit tests. The effect on the application is that the codebase is turning into a pile of fettid dingo's kidneys. Without the unit tests there the design is not being driven.
I am finding the acceptance tests are really useful. Developing the framework to run them is however taking up a lot of my development time. I can see the benefits, and I am even able to test how the GUI pretty well.
I plan to make my Winforms Acceptance test running framework available soon. Espeically if there is some interest in it. Currently it is usable in several diffrent forms. There is a class you can call methods on like PressButton("Add"). There is also a script interpreter that understands a simple scripting language. eg. ":PressButton Add". Basically it allows you to instanciate a form, and perform commands on the form. The commands give you the ability to ask a dialog questions like "Is field 'title' enabled" or "Does field 'Description' have the value 'Ooow look a description'". You can also exercise the controls in the form with commands like "Press button with the text of 'Add'". This is very extencible, and only currently supports the types of controls I have been using. Namely text boxes, tree controls, buttons and menues.
If you wish to hear more about this, email me.
Update: I have halted development in favor of using NUnitForms.
I may integrate the two ideas later.
First thing, IE uses Name of Id is missing. Mozilla doesn't. Supply IDs for everything. IE Documentation saies tell the document to create an option element, ... that doesn't work on anything except IE, but this did.
for ( num = min; num <= max; ++num)
list.options[index++]= new Option(num,num);
I have just been reading about dynamically updating parts of the HTML page using XMLHttpRequest.
Basically you write some code that on_click sends an XMLHttpRequest back to the server. When the responce is recieved it looks for XML entries with ids that match ids on your page, then overrights the matching parts of your page with the content of the matching XML segment. This has the effect of allowing the server to update any part of a page dynamically without refreshing the whole page.
I wanted a way to calculate in Excel what the date is of a day 12 working days from now. There has to be an easy way of doing this. However until I find it, here is my work around.
Function AddWorkingDays(startDate As Date, days As Integer) As Date
If (Weekday(startDate) = vbSunday) Then
days = days - 1 ' treat sunday like saturday
AddWorkingDays = startDate + days + (NumberOfWeekends(startDate, days) * 2)
Function NumberOfWeekends(d, days)
numDaysPastMonday = Weekday(d, vbMonday) - 1
numDaysStartingFromACompleteWeek = days + numDaysPastMonday
NumberOfWeekends = Application.WorksheetFunction.RoundDown(numDaysStartingFromACompleteWeek / 5, 0)
I even did unit tests when developing this marco. I like how easy this is in Excel. I made a sheet with the columns for the parametes 'startDate' and 'numDays', followed by 'Actual', 'Expected' and 'Result'.
Actual was using the method under test, so in this case '=AddWorkingDays($A2,$B2)'. Result was just a simple comparison formula '=($C2=$D2)'. In Excel you can put conditional formatting on a cell, so I also made the Results column change green on 'TRUE' and red on 'FALSE'. At the
bottom I put a 'Tests failing :' cell with a formula of '=COUNTIF(E1:E48,FALSE)' to summise all my tests. This too was conditionally formatted to red if greater than 0.
The only thing I didn't find a nice way of doing was refreshing the tests when the macro has changed. What I ended up doing was cutting and pasting one of the input columns. I am sure I could have written a macro attached to a button, but that was too much hastle. If anyone knows a better way, let me know :)
It basically says if you can't grab a class out of your design and quickly test it in isolation, then your design is not good enough. I like the idea of evaluating my code in this light.
I have noticed recently that my designs are distilling out into usable classes and mediators that pull everything together. The mediators need mock objects to test them. I am going to see how much code I can push into usable objects and away from the mediators.
Whenever I think about good design I am constantly bought back to Ash's Collaborative AID. It is a great example of a piece of software that is open for extension but closed for change.
"Excessive automation - too complex and inflexible, requirements usually go into great depth, but miss what is important."
Now I am a strong advocate of automation, so the concept of overautomation struck me as odd. The point is valid. You get to see it in shops when you ask for some infomation only to hear "the system doesn't allow us to do that. Sorry."
The article is about continually refactoring how a business works to keep it efficient. Definitely a theme I agree with. In development, if we want to change a process we can build the tools we need to make the new process work. Some industries don't have that ability. Even worse, it's often software thats the culpret. Once they have a software package installed in their company, its with them for years. The automation that originally was installed to simplify things becomes the system everyone is having to work around to get their job done.