I think an internal blogging system is essential. “Knowledge Capital”; I know it’s a tireless term but I’m amazed at the inefficiencies of most work places due to lack of information sharing. I learn a lot from subscribing to your blog and I get the information quickly and efficiently (please, no more email lists for me). Email is such an inefficient way to share and collect information. How To’s, tricks, tips, documentation, ideas, discussions, you know the drill. Everyone on a development team benefits by the collective knowledge of the group; few places leverage this well.
I think an internal blogging system is essential. “Knowledge Capital”;
Alan has hit on something important. One of the few things the last shop I worked in did well was to share information in an internal Wiki.
Source control is important. Furthermore, it is important to use it properly. I’ve seen more than one shop where institutional processes sabotaged the full benefit that could be obtained from using a source control system.
To quote my exproject manager “if you do it right the first time you don’t need tests” .
- Is your specification stored in RDF and versioned?
- Are your unit-tests linked directly to the specification(s) they test?
- Is your issue database versioned along with the code?
- Do your unit tests run live while writing your code?
- Are user and developer commentary automatically included and versioned alongside the code and issue database?
Or
1-5: Can you look at any point in the history of the project and find the exact state of the code, documentation, tests, test results, code reviews, specification, issues and comments?
Oh wait … that’s the 2012 list … damn.
“Do you follow agile methodologies
OK, but what does “agile methodologies” mean? Be specific.”
“Jeff:
I mean eXtreme Programing.
Suren”
Hmmmm, either you’re joking or you missed the point.
Do you have: “A defined process for end-to-end software release?”
… a software release meaning any iteration of your software in some working, tested state. I propose this since ‘modern software development’ seems to be about process driven development; refining of, and adhering to.
Quality Assurance doesn’t necesarily imply testing so to that one I would add
- Do you have a plan for testing?
That ropes in unit, integration, system … testing.
As far as the development goes a simple question is:
- Do you follow a defined process for development?
This ropes in all of the methodolgies out there as long as they are defined as a standard process for the development effort. If they are not then it is ad hoc and you really can do whatever you wish.
I think the first set can also be modified from just “spec” to “spec/requirement” and somehow is it clear. A badly written spec or requirement could have you developing something bipolar to what the customer wants. This is where the customer-developer communication would come in. If you had that, then you would know.
Also there is no one reviewing anything that anyone is doing. Potentially it is covered in a QA plan but there is no explicit peer review of the code or the documents. Sure it is implied but someone needs to be doing that otherwise you are developing in a vacuum.
- Do you test before or after delivering the solution?
For most projects we run out of time. But there are several advantages to this:
- The customer does the testing instead of us
- Management on both sides is happy because the quantifiable targets are met (delivery date + development costs - any development post-delivery becoming ‘debug’)
- The customer is much more inclined to sign the maintenance contract.
As for specifications, in my experience, customers usually don’t know what they really want until you’ve done what they asked you to do.