Humorous design decision of the day: Color coding titles

We are replacing a couple of spreadsheets with a web application. One set of spreadsheets had data separated/categorized into "orange section" and "green section". These were the background colors of the data in those sections. This data really belonged in a wiki, but that is another story. Anyway, everyone started referring to the data by color: like "Is that the orange data or the green data?" The users did not want to lose the distinction of the colors because now every one refers to the orange data and the green data instead of their proper names (which are pretty ambiguous). To keep the orange and green I made the background colors of the page names orange and green to match the spreadsheet. When we showed these pages to the customers they were very excited that we managed to incorporate their color scheme into the application. Sometimes it is the small things that matter the most to the customer.

Skinny User Stories, Fat Unit Tests

One of my colleagues is continuously trying to improve the processes on his project. It is a large enterprisey project with requirements people, testers and a few developers. My friend places high value on knowing exactly what needs to be done and therefor has strived in the past to have very detailed user stories that includes expected behavior and constraints as well as test criteria. He and I had a conversation that restarted his consideration of the user stories. He likes that they are defining the "truth" in only two places, the user story and the code.

While you are defining the truth in two places, I would say that only one of those places has any long term value. The code. As soon as the sprint is completed, your requirements, especially if they live in a tool like Rally, only exist for the sprint where the code is written. After that sprint, it is doubtful that documentation will ever be read again. This is why specs should be light weight. They are only used for a moment in time. Any time that you begin talking about the specs again, you will have to repeat yourself because invariably one person in the conversation will not have a full understanding of the requirements and you won't have the time to send them the requirements to read. Now is a developer going to go through Rally, or any other tool for that matter, to read the requirements for code? No.

The best place to store requirements is in the Unit Tests. Theoretically, you hope to only have one truth, and that one truth has to be the Unit Tests. Every other type of spec is disposable or maybe a better word is perishable. The specs will go away. The contract will go away. The shall statements will go away. The tasks in Rally or JIRA will go away, but the tests will always remain. "Why does this code do
this?" Should always be answered by "look at the test." This doesn't mean leave comments in the test, it means make the test methods the spec.

I've never really been able to put a finger on why I am so against requirements. It seems irrational and crazy. But I think I understand it better now. I have known subconsciously that the requirements are perishable. That they change. They change as soon as you put it in front of someone and show them how it works. The requirements are never absolutely correct. And if they are right, have you put to much time into managing them?

Lessons Learned:
* Requirements are perishable, their shelf life is the length of a sprint.
* Tests are the ultimate "truth" of the requirements of a system.

Improved Office Arrangement

I propose that office arrangements should be re-arranged. Currently the bosses sit in offices and the workers sit in cubicles. Managers are always talking to each other, so if they sat in cubicles it would facilitate communication amongst managers. Also, putting the developers in offices would allow them to stay in the zone because they would have fewer distractions.

Managers say they need offices because the meetings they have require privacy, but I imagine that if those meetings were held in the open more collaboration would happen. They say developers should sit in the open because they need to communicate, but all of the times that I have ever "communicated" I was with a manager.

Who knows, projects might show up on time for a change.