Things I believe in

• It's easier to re-build a system from its tests than to re-build the tests from their system.


• You can measure code complexity, adherence to standards and test coverage; you can't measure quality of design.


• Formal and flexible are not mutually exclusive.


• The tests should pass, first time, every time (unless you're changing them or the code).


• Flexing your Right BICEP is a sure-fire way to quality tests.


• Test code is production code and it deserves the same level of care.


• Prototypes should always be thrown away.


• Documentation is good, self documenting code is better, code that doesn't need documentation is best.


• If you're getting bogged down in the process then the process is wrong.


• Agility without structure is just hacking.


• Pairing allows good practices to spread.


• Pairing allows bad practices to spread.


• Cycling the pairs every day is hard work.


• Team leaders should be inside the team, not outside it.


• Project Managers are there to facilitate the practice of developing software, not to control it.


• Your customers are not idiots; they always know their business far better than you ever will.


• A long list of referrals for a piece of software does not increase the chances of it being right for you, and shouldn't be considered when evaluating it.


• You can't solve a problem until you know what the problem is. You can't answer a question until the question's been asked.


• Software development is not complex by accident, it's complex by essence.


• Always is never right, and never is always wrong.


• Interesting is not the same as useful.


• Clever is not the same as right.


• The simplest thing that will work is not always the same as the easiest thing that will work.


• It's easier to make readable code correct than it is to make clever code readable.


• If you can't read your tests, then you can't read your documentation.


• There's no better specification document than the customer's voice.


• You can't make your brain bigger, so make your code simpler.


• Sometimes multiple exit points are OK. The same is not true of multiple entry points.


• Collective responsibility means that everyone involved is individually responsible for everything.


• Sometimes it's complex because it needs to be; but you should never be afraid to check.


• If every time you step forward you get shot down you're fighting for the wrong army.


• If you're always learning you're never bored.


• There are no such things as "Best Practices". Every practice can be improved upon.


• Nothing is exempt from testing. Not even database upgrades.


• It's not enough to collect data, you need to analyse, understand and act upon that data once you have it.


• A long code freeze means a broken process.


• A test hasn't passed until it has failed.


• If you give someone a job, you can't guarantee they'll do it well; If you give someone two jobs you can guarantee they'll do both badly


• Every meeting should start with a statement on its purpose and context, even if everyone in the meeting already knows.

A reading list for our developers

An idea I'm thinking of trying to get implemented at our place is a required reading list for all our developers. A collection of books that will improve the way that developers think about their code, and they ways in which they solve problems. The company would buy the books as gifts to the employees, maybe one or two every three months.

Some questions though:

• Is it fair for a company to expect its employees to read educational material out of hours?

Conversely:

• Is it fair for an employee to expect to be moved forward in their career without a little bit of personal development outside the office?

If anyone has any books out there that they'd recommend - please let me know. Otherwise, here's my initial ideas - the first three would be in your welcome pack:

Update:Gary Myers came up with a good point, being that any book should really be readable on public transport. That probably rules out Code Complete (although I read it on the tube, I can see that it's a little tricky), but Design Patterns and Refactoring to Patterns are small enough I reckon.

Unfortunately, Code Complete is a really good book that gives a lot of great, simple, valuable advice. Does anyone out there have any other suggestions for similar books?

Update 2:Andy Beacock reminded me of Fowler's Refactoring, which really should also make the list.

Update 3:The development team have bought into the idea and the boss has been asked. In fact, I'm pretty pleased with the enthusiasm shown by the team for the idea. I can't see the boss turning it down. Interestingly though, someone suggested that Code Complete go onto the list...

In this order:

• Extreme Programming Explained - Kent Beck


• The Pragmatic Programmer - Andy Hunt & Dave Thomas


• Pragmatic Unit Testing using JUnit - Andy Hunt & Dave Thomas



• User Stories Applied - Mike Cohn


• Software Configuration Management Patterns - Steve Berczuk


• Refactoring: Improving the Design of Existing Code - Martin Fowler


• Refactoring to Patterns - Joshua Kerievsky


• Design patterns : Elements of Reusable Object-Oriented Software - Gamma, Helm, Johnson, and Vlissides


• The Mythical Man Month and Other Essays on Software Engineering - Frederick P. Brooks

Ruled out because of their size:

• Code Complete - Steve McConnell


• Head First Design Patterns - Freemen(s), Bates and Sierra

Database Build Script "Greatest Hits"

I know its been a quiet time on this blog for a while now, but I've noticed that I'm still getting visitors looking up old blog posts. It's especially true of the posts that relate to "The Patch Runner". Many of them come through a link from Wilfred van der Deijl, mainly his great post of "Version control of Database Objects". The patch runner is my grand idea for a version controlled database build script that you can use to give your developers sandbox databases to play with as well as ensuring that your live database upgrades work first time, every time. It's all still working perfectly here, and people still seem to be interested, so with that in mind I've decided to collate them a little bit. basically provide an index of all the posts I've made over the years that directly relate to database build scripts, sandboxes and version control. So, Rob's database build script 'Greatest Hits':

• On the basic idea of building a database in an agile manner
• On how you might start putting together a version controlled database build script
• On how you can organise patches to reduce the pain of a rolling back changes
• On the arguments between table-centric and patch-centric database build scripts
• On what automated build scripts give you
• On having the build script be able to tell when something goes wrong, and stop
• On how you can use your automated builds to give you a sandbox
• On why your DBAs shouldn't burst into tears when you tell them you need a database for each developer
• On how you database build script can work with you version control tool
• As well as: a presentation given to the UK OUG

All of the posts describe processes and patch runners that are very similar to those that I use in my work every day. I started playing with these theories over 3 years ago now and there is no way I'd go back to implement database upgrades the way I did before. However, I'd LOVE to hear ideas on how things can be improved. I'd be amazed if my three year old thinking was still up to date! Technorati Tags: oracle,, rdbms,, software,, development,, upgrades,, Robert+Baillie

Wow

And you think software patents are bad...

China Regulates Buddhist Reincarnation

Problems with CVS removes?

Accidently removed a file in CVS that you want to keep?

Sounds like a stupid question, because when you know the answer to this problem it just seems blindingly obvious,
but what if you've issued a 'remove' against a file in CVS and before you commit the remove you decided that you
made a mistake and still want to keep it?

I.E you issued (for example)

 > cvs remove -f sheep.php

But not issued

 > cvs commit -m removed sheep.php

I've heard work arounds such as:

• Edit the "entries" file in the relevant CVS directory in your workspace, removing the reference to the file.
  This makes the file appear unknown to CVS.
• Perform an update in that directory. This gets the repository version of the file and updates the "entries"
  file correctly

All you actually need to do is re-add the file:

 > cvs add sheep.php

 U sheep.php
 cvs server: sheep.php, version 1.6, resurrected

When used in this way, the add command will issue an update against the file and retrieve the repository version of the file.

A word of warning though, if you had uncommitted changes in that file before you issued a remove, CVS isn't going to recover that for you...

How about if you've removed a file, but your version of the file is out of date and so you can't commit it?

So you've issued the following:

 > cvs remove -f sheep.txt 

 cvs server: scheduling 'sheep.txt' for removal
 cvs server: use 'cvs sheep' to remove this file permanently

 > cvs commit -m removed sheep.txt 

 cvs server: Up-to-date check failed for 'sheep.txt'
 cvs server: correct above errors first!

You can't issue an update because you get the following:

 > cvs update sheep.txt

  cvs server: conflict: removed sheep.txt was modified by second party
  C rob_tmp.txt

Again, add the file.

 > cvs add sheep.php

 U sheep.php
 cvs server: sheep.php, version 1.6, resurrected

This gets you the most up to date version from the repository, that you can then check for changes (you wouldn't want to just remove it now that someone's added new content would you?)

Once you've convinced yourself that it's still a good idea to delete it, just issue the remove and commit.

Simple when you know how!