README

I had a long think on what common questions I have when walking into a new project.  The process was more difficult than I thought, but I came up with ten important questions.  I am assuming these questions are in fact, automatic these days.  II am not going to divide them up by any methodology, but I feel they are all valid,  regardless.  I not assuming all these questions will be answerable, CI (continuous integration) is a case in point – not as common as perceived.  But once I have responses to all these, then I can understand the state of the project, and know better where I can contribute, and also possible improvements.

1. Where is the project plan (the timeline)?
2. Where is digital board with current workloads and progress?
3. Where do the team keep issues (user stories, features, tasks, bugs, etc.)?
4. What is lifecycle of an issue (of any type), from creation to signoff?
5. How do I deploy latest code to test environment?
6. How do I check build failures on CI?
7. How can I add a program or configuration to the common virtual machine?
8. What is the definition of “Done”?
9. What are the non-functional requirements?
10. Where is user guide (the end user will want one, and many connected with project will need one also)?

Now this has a point beyond the actual questions, and onto documentation.  When a new person joins a team, the effort should be made to make integration as smooth as possible.  So why to so few create basic README guides?  Defining process to deploy latest code to QA environment, for example, would be a short and precise process.  Creating user guide early helps all on the project, and especially for new team resources added later on in a project.  And how can everyone agree when a user story is complete, if there is no common vision of “Definition of Done”.

No-one can convince me that there isn’t the time to document.  So when I arrive with those ten questions, I spend the time finding out these things, then document them in the README included with the test application project.  One of the unhealthy habits us humans can get into, is a pattern of repeating the same information, again and again, when a simple piece of documentation could save that.

I will briefly touch on another reason, asides from either laziness or mistaken view that documentation on this level is a waste of time. There are those more antiquated individuals who see this kind of information as a power base.  The old ways of constructing your role to be more, by acting as conduit. i.e. people have to request from them specifically.  These types barely register on my spectrum – they are simply taking up a seat, and sharing my airspace.  They never last long either.