posted on
My idea workplace will faithfully document institutional knowledge in order to empower developers. When one person holds up a team because they’re busy holding up the team (see what I did there), that team needs to level themselves up. They should not be satisfied to let the one teammate carry the team. Do the hard work of the debrief and learn, then document. Document because knowledge is power, and you want a strong team.
posted on
This chapter will focus on project management from an agile perspective (framework-free).
Requirements gathering is more like requirements digging—nobody knows exactly what the want. Programmers help people understand what they want. The requirement (once expressed) should be seen an invitation to explore.
For example, the statement “Shipping should be free on all orders over $50.” should beget a bevy of questions about including tax, which shipping methods are included, internationalization, frequency of changing that $50 number, etc. The client (who has great domain knowledge, hopefully) has probably thought of some of these cases, but discussing them helps flesh out the actual requirements. A developer’s role is to interpret what the client says and feed back to them the implications.
Requirements are a process. They are learned in a feedback loop. Help your client understand the consequences of their stated requirements. Sometimes you won’t know the domain of knowledge well enough to provide salient feedback, so use “is this what you meant?” through mockups and feedback.
Walk in your client’s shoes. Work with a user to think like a user.
There’s a difference between requirements and policy. Policy should be metadata. Policy can be something like “Only an employee’s supervisor and the personnel department may view that employee’s record.” Taken literally as a requirement, it might be hard-coded. Taken as policy, you’d build / use an access control system that allowed authorized users to view a record—defining what is an authorized user would then be metadata (or configuration).
There’s also a difference between doing what the requirement asks, but not how the customer wants. Early prototypes and tracer code are key to nailing both.
Requirements are best recorded as user stories—describing a small portion of what the application does from the perspective of the user. Keep the stories small enough to fit on an index card (real or virtual), which encourages develpoers to ask clarifying questions (record the answers, for documentation).
Developers should maintain a project glossary that contains all domain-specific vocabulary for that project. It’s hard to succeed on a project if users and developers cal the same thing by different names.
The key to solving puzzles is both to recognize the constraints placed on you and to recognize the degrees of freedom you do have, for in those you’ll find your solution. Challenge any preconceived notions and evaluate whether or not they are real, hard-and-fast constraints. Categorize and prioritize your constraints.
You can help yourself solve puzzles by getting out of your own way. If you get stuck, do something else so that you let your subconscious (an amazing associative neural net) can process it. If you can’t do that, try to explain the problem to someone. And, like Hitchiker’s Guide to the Galaxy says, “DON’T PANIC”.
I’m a lover of pair programming, so this section really resonated. I love the resultant product that comes from the tensions of two people (or more) working out a solution together. I think two is almost always better than one.
From the manifesto:
Any framework or method that pushes the right side over the left side should be abandoned. Agility is:
posted on
Coding is an intensely creative act that happens through instincts / nonconscious thoughts and the active thoughtful application of principles.
The first trick is to notice that it’s happening; then work out why. You may not be able to, but try to crystallize it into something solid that you can address. Let your instincts contribute to your performance.
