A Little Bit of Crypto - I have been trying to figure out to "collision resistant" some of these standard hash functions are. It is a tough concept to get my head around. I figure...
Now I can design all kind of goodness. I can create slick user interfaces. I can do database magic. And I know how to put together algorithms that work. But if I don't know what the customer wants, then I can't do much. I told the requirements analyst that she needed to figure out and understand what the customer was asking for. Only then could we move forward.
The next morning I get a message that I must attend a meeting with the customer. They were going to discuss the latest change. So the requirements analyst started asking the customer about some ideas she had. She imagined the customer wanted some sort of complex system based on the feedback they had already provided. This meeting was going nowhere. Then I was asked if the discussion answered my concerns. LOL!
I started at the beginning. First I went over how the current system worked. Then I started defining some of the new words the customer was using. Turns out they were just synonyms for other well known understood parts of the system. Then I took a concrete example, and walked the user through how they thought the system would need to work. Then I went through the main scenario a few more times, picking up more details, and getting confirmation and consensus from all the customers at the meeting.
Requirements analysis is hard. You cannot just act as a clerk and write down some ideas, hoping you have captured any requirements. You need to dig in. You need to get the customer themselves to think about what it is they want. Then you should walk through some concrete scenarios. Only then can you truly understand what it is you are talking about. I love designing and inmplementing software. But I definitely don't want to spend my life working on features that the customer does not want or even need.