It seems most developers has listen too much to the principle of “don’t repeat yourself”, and so otherwise bright developers in some cases strive too much to avoid repeating themselves and makes a mess of their systems but avoids repetitions completely. If your developer and reads about the DRY, do also remember the important step one: Think. I’m basically all for DRY. Endless repetitions of the same lines of codes is a pretty bad idea and should be avoided.
Most developers and programmers know more than one programming language, but often do most of their development in just one language. Listening in on IRC channels on people using something other than their favourite language is often quite interesting. It’s often a common misconception, that their favoured programming language - be that perl, php or java - is the ultimate tool no matter what the challenge is. When they are forced to use something else, a large part of the development process seem dedicated to (a) bitching about how much easier this and that would be in their favoured language and (b) forcing the language they use into looking like their favoured language.
While project management often focuses on management of the processes, information management and other work issues, one of the most important areas often overlooked IMHO is the physical environment and how it may improve efficiency of the project workers.
Joel Spolsky just moved is company to a new office and spent some time to figure out how to improve “developer workspaces”.
It quite an interesting read.
I don’t know how many (Internet development) projects I’ve been on, but it’s quite a lot through the years. One thing happening over and over again is that all the ambitious goals of the project isn’t quite reached before the launch – and something is either cut short or not quite as polished as it should have been. Lately I’ve been wondering weather this is the right approach. Many of the things you leave out when the deadline starts getting closer is “the finishing touch” – this is especially true for back-ends and other invisible details everywhere.
I’m sure the concept of pointless meetings is familiar - too many people gathered to discuss some issue but after spending hours together no decision has been reached - only the next meeting with a few more people. Here’s one tool which might help a little.
I should begin by noticing that the idea is not my own - it has been as far as I know been used before. I came across it at the Copenhagen Business School where one of the teachers in Organization told about it (and credited it to Søren T.