NYCPHP Meetup

[David Krings]

Leam Hall wrote:
> Well, let's hope you don't have any heart attacks soon! however, I do 
> wonder how you *real* developers get specs and requirements? Are they 
> that loose until you build and the client says "that's not what I wanted"?

Although I work in a software company I´d guess the same mechanisms apply. 
Here our executive team has to sign off on a statement of scope, then a 
Business Analyst (could be a developer) writes a Functional Requirements 
document that details the expectations, how the UI is supposed to look like, 
and what happens when this or that button or so is clicked, when things are to 
be enabled or disabled, and so on. From that both test plans and tech spec s 
are created. The functional requirements, the tech spec, and the test plan are 
reviewed and signed off on. Next step is coding and showing the outcome in a 
peer review, but for more complex things it is recommended to add a "proof of 
concept" demo. The app doesn´t do much, but the requester gets an idea as to 
how things will look like and work. That point is the last point to make any 
changes. Often enough the requesters are not that technical and need something 
to look at and play around with to get an idea as to what they want. After 
such a proof of concept demo the project plan gets reviewed as well to include 
any time needed.
The developers need to be very sure about the requester being knowledgeable 
and educated enough to clearly state what they want. That includes asking more 
questions and IMHO also saying "No" to things.


> 
> Is there room or time for better requirements gathering up front so you 
> save time down the road? That seems to be part of the TDD process; your 
> requirements specify the tests. Or do I not get it?
> 
Yes, yes, yes...anything you do not do in the beginning you will do later, 
just that it takes three times as much time and is three times as annoying. We 
had a few requests that sounded good at the beginning, but after several 
meetings we were neither on the same page nor did we have a good solution that 
everyone liked. We didn´t do that project and sent it back to the requestor. 
He came back with a much better request and with a lot of KISS we crafted an 
awesome feature. The users love it and it is even more than they needed and 
hoped for. The original approach would have taken twice as long overall and 
created a feature so intimidating and complicated nobody would have used it.
Spend a lot of time in the beginning to really hammer things out and to 
document everything, especially what the new foobar is not supposed to do. 
That way no one can come by and request that it does do that.
Process is hard and sticking to it even harder. And the first thing to go in a 
time crunch is communication, the second thing close behind is quality. So, 
yea, dear requester, you can have the new gadget in two months, but it will be 
crappy.

David