Saving passwords
I am by no means a security guru, but can all you developers please end your stupid habit of saving passwords in clear text to the database.
It makes my cry when I click ‘forgot password’ on a web site and get a mail with my old password in it.
Make a hash out of the users password combined with a random value, called salt. Store the salt and the hash in the database. When the user later tries to log in you can hash the supplied password together with the salt and compare it to your stored hash.
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.
Cohesion and redundancy
We’re doing some static analysis with NDepend as part of our daily build and the cohesion measurement caught my interest.
When googling for cohesion I stumbled upon some articles discussing reading and writing normal text (normal in this case meaning not source code).
The concepts that I fell for are cohesion and redundancy.
Here is what Wikipedia has to say about these words regarding programming:
- Cohesion: a measure of how well the lines of source code within a module work together to provide a specific piece of functionality.
- Redundancy: The notion of unnecessary, dead or duplicate, code.
… and here are the same words regarding linguistics:
- Cohesion: the linguistic elements that make a discourse semantically coherent.
- Redundancy: In language, redundancy is the use of duplicative, unnecessary or useless wording.
Linguistics also has the notion of coherence; what makes a text semantically meaningful.
In this article Alice Horning discusses research about cohesion and redundancy in writing. It made me draw some parallels between writing good literature and writing good source code.
Alice states that novice writers lack the ability to distance themselves from the writing to see their text from a readers point of view. I see the same pattern on and on when reading, and trying to understand, source code. It is, mostly, not the programmers’ lack of technical competence that makes it hard to understand their intent. It is their style of naming and grouping things together that creates a total lack of linguistic cohesion, and coherence.
I guess Domain Driven Development would tend to some of this but all I know about that is what Jimmy Nilsson said on DotNetRocks. At least a common way of naming, abstracting and grouping things within an application would use the linguistic sense of redundancy to make code more understandable. Design
patterns will also use redundancy to help the reader understand code since he probably will have a good idea of what’s coming if the code corresponds to a known pattern.
Code reviews also help a lot, but that is done far less than one would like.
I think the cure for this is to take time to read more code. Just as you need to read lots of literature to be a good author you need to read other peoples source code to enhance your own skills. You need to read code that is more than just samples and proof of concepts, and I think it should be code that you are not emotionally attached to. So get your favorite open source application and read its code. While you’re at it you can contribute to it and make the world an even better place.
Other search terms:
- research: cohesion prefixes
Culture neutral satellite assemblies
I’m slapping localization on to an existing product and needed a way to have my culture neutral resources in a satellite assembly. I can’t use embedded resources because I am extracting data from the compiled assembly to use for the resources.
The solution was to use the assembly attribute: NeutralResourcesLanguageAttribute to indicate what culture should be used as the default culture and use the UltimateResourceFallbackLocation enum to indicate that it should fallback on a satellite assembly. This attribute is new from .NET 2.0 so in 1.1 and 1.0 you will have to embed your culture neutral resources into the main assembly.
