Analysis, heavy thinking, database, software architecture

Last week was a big conference for some of my clients. Naturally, there was a fluerry of activity leading up to the conference. My customers made specific requests about some features in our flagship application that needed attention. I was reminded of the following points.

1 - Trust your design. If you have a MVC design in place, trust that it will pay dividens when you are up against timeline constraints.

2 - Break the requests down into little pieces, as much as possible. Do not look at all the requests at once. It would have been easy to get a little overwhelmed at the requests given the time constraints, rather than being overwhelmed, beak it down and trust.

3 - Communicate in very clear terms. Spell out exactly what you are understanding to your customer. I asserted to my customer what i though was asked for and they asserted back ubtil we had that cleared up.

4 - Back to point 3, Requirements are at least 1/2 the battle. My customers dont give me black and white requirements, they explain what they want, but i need to help them clarify the specifics. This is where a front to back design methodology is very valuable. A picture is worth a lot. Show the client what they are asking for - it will help inform what they are trying to say.

5 - Go to a quite place to think through the problem. Noise is a great enemy of critical thinking. I was reminded of the inverse pyramid too. When push came to shove, i was the only one who could make most of the changes being requested. Thats good and bad, good for job security, bad for organization. Picture a pyramid, now flip it upside down. At the top there is lots of room, many hands involved - clarifying the requirements, building prototypes, documenting, testing, as you move down the pyramid toward implenentation, the bottom, fewer people are involved, as your reach the very bottom, there is only one person holding everything up. This is not a statement of pride, no - rather an observation.

6 - Heavy lifting - Trust that you will see a good solution to the problem. Resist the urge to implement the first solutions that pop into your head. There is always a better idea. I like to stay on a problem for a couple days, at least two, where i can give it my best brain power. Almost, without fail, after the second day, i see a better solution that what i had at the end of the first day. Think through the problem. The more time the better.

7 - If the update involves a heavily travled or common path in your application, then think REALLY hard about what you are doing. One of the updates i made to the application was to a very public object. The initital solution i saw added too much overhead to that object. The second solution i saw after a third day of analysis was much lighter. Lighter in terms of less trips to the database.

8 - Think in terms of tradeoffs - this is a mantra that i hear a lot of smart developers saying. Everying you do is a tradeoff. If you persist a piece of data via bean, in memory - saving a trip to the DB, the tradeoff is a bit more overhead. If you keep the overhead real lean, the tradeoff is more trips to the DB. If you choose to keep lookup code in your view page for simplicity, the tradeoff is less maintainable and reusable code. If you choose to follow a mature design pattern and layer your code in a MCV pattern, for ease of maintenance and troubleshooting, the tradeoff is a bit more complexity.

9 - Document your decisions - Someone once said code your documentation. That may be a little overkill, but the point is made. Think about someone else maintaining the code you are writing / updating. Add relevent comment to the code itself. I also like to add information around the bus. logic decision that i am making. I will admit, that i am making these decisions in a vaccum, so its important to document why i made decisions the way i did. 6 months down the road, when i have to update that area of the application again, im always thankful.