It is sometimes tough to turn down help
About a week ago I was offered help to translate logview4net to Russian. The offer came from a gentleman owning an open sourced project for translating .NET applications.
Of course I was thrilled by the offer. I had really thought about localizing it, but since English and Swedish is all I know I haven’t put it on top of my to do list. Most, if not all, Swedish users of logview4net are probably happy using it in English.
Anyway; after looking at the technical solution I decided I didn’t want to use it in my application. I feel a bit bad for letting him do all the work before I looked at his solution. I assumed to much. A bad habit I really need to get rid of. I have localized one large application as an after thought and one as part of the design so my decision is at least based on some experience.
I hope my turn down letter will be regarded as constructive criticism and not a flipped finger.
To any one else wanting to write tools for localizing applications; there a lots of stuff that works in the .NET framework. Try to create tools for all the things that are missing instead of starting from scratch.
On Baking requirements
Jeffrey Palermo states in his post ‘Baking requirements – Developing with raw ingredients is waste‘ that requirements has to be thought through before they are presented to the developers.
I think that is a statement that holds true for all levels of requirements. Software development is intangible and it is perceived that changes are easy to do. This leads to bad requirements from everyone. Customers doesn’t think through their needs and expectations before starting software projects. Business designers doesn’t think through either requirements or business rules enough before presenting them.
Very often it is possible to start working on a requirement even though the related business rules aren’t clear. But most times I find the business peoples lack of understanding of the constraints we developers are under to be very frustrating. A rule that is easily implemented or discarded in a manual process might need architectural changes in an automated process. It is frustrating for both parties. The current buzz is that developers should reduce the gap to business, but I think the responsibility to close that gap falls equally much on the business people.
We could argue that learning to program is hard, but failing to learn programming would also be a lesson learned.
Continuous builds instead of meetings.
Lots of times I have been involved in lengthy discussions about how to solve a problem and trying to guess what the user really wanted based on his initial request. It is not uncommon that implementing all of the possible solutions and lettings the user choose the one that satisfies his needs would have been done in a shorter amount of time than discussing it.
I’m probably rambling but if we have a continuous build, that is releasable, we could in many of these cases give the customer builds with all of the solutions and let the customer decide.
I have heard of development teams that has taken deliverable builds to such an extreme that they build Virtual PC images with their system preinstalled every night. So even if there is server software involved it is possible to create agile deliveries.
Releasable daily builds
Share and store documents… Free.
When you do daily builds, a practice I think is essential for high quality software development, it is important to make sure the build is so complete and easy to find that the test team and sales force can choose what version, and when, to install by them selfs.
It is an accepted truth that the longer you wait to fix an error the more expensive it gets. If the test team can verify a fix the day after it is checked in to the source repository instead of waiting for the next sanctioned release both the feed back loop and cost gets smaller.
For this to work all of the organization has to work in union to keep the daily build complete. It will not work if someone is working by him self and checking in bad code because he ‘knows’ there is a long time until the next release. If the development is done for a customer that expects to see continuous progress it is extra bad if someone is checking in bad code. It is a problem that is not solved with unit testing since the result of those is easily manipulated by the rouge developer.
Everyone has to work together to make each and every daily build ready for release.
Stale software teams
It is quite interesting to see how developers are affected by a projects perceived market value and internal company status.
When a new project is started people are usually open for new ideas and most of the involved does things to move the project forward. A direction that is not allways the same for an individual as the group, but at least it’s moving.
When the project has been going for a while and it hasn’t delivered as planned, decisions might be made to rewrite parts of the system, partly to show the market that it is able to adapt and partly to get the staff moving again. At this point those developers that usually are in the lead of getting things done starts looking for other jobs.
The only ones left are those who don’t get things going by them selfs and a few high spirited still believing in the project. So now all those that should bring some forward momentum to the project, managers, architects and so on, are the kind of people that prefer status quo, and the few still inspired has to fight to get anything done and to try to inspire all the rest.
If all of those high spirited people has found other jobs management might bring in external resources to develop the new functionality. This will make the crisis even worse since the employees now will think that all inspiring activities are done by overpaid consultants, which makes them even more resigned and uninspired.
If the perception that the organization will continue to finance the project gets hold the project will also get the staff from other departments that would like to do their eight hours a day without involvement.
This is a mess that it is hard to get out of. It is not easy to hire an inspired commited developer to a stale team like this without tricking him in some way, and that will only make him quit asap. I think management has to create more or less fictive goals so that the staff can see results. Management will also have to convert some of the staff to evangelists within the team so that they can motivate all others.
