Top-Down on Top Again

It's a little old-fashioned, but I remember when we used to think of procedural languages as "top-down", & object-oriented languages as "bottom up". In the former, you looked at the verbs - what needs to be done - & then you broke these down into smaller units of work, etc. In the latter, you looked at the nouns - the things in the system - & modelled these to provide the basic operations that were built up to create bigger relationships.

It's a long time since I taught this ... stuff ... so I do hope we've progressed. I'm not convinced that everyone's aware of the progress, though.

I'm a keen BDD follower - every product I build follows the general principles of answering

• What does this product promise to do? 
• (what is its behaviour?)
• How is it going to be used? by whom? 
• (what is the context?)
• How does the company make maximum benefit from (justify) any given feature? 
• (what is the value proposition?)

These are very top-down questions. I don't care about the technology or even the problem that it tries to solve. The architecture of the solution, its maintainability, etc, are not a priority; that's for engineering's expertise. Performance probably is interesting - or at least the importance of performance needs to be determined.

From a project management point of view, I have other questions -

• How do I know when it's ready (enough)?
• How do I prove that it's ready enough?

This is strictly BA/QA work. No devs need be harmed in the making of these decisions.

If you look at that approach, you might think that I am a non-technical manager (product or project). I'm not. I'm a top-down developer at heart.

I believe that, even if a developer is not involved in higher levels of abstraction directly, they need to be exposed to the helicopter view, be able to provide feedback on it, & always keep it in mind with their deliverables. Without an understanding of how a release (candidate) moves the product closer to its user base or marekting's promises, there is the increasing chance of disconnect between the product that is being developed & the expectations that are being set outside of engineering.

The days of "I can prove that this software solves the problem you gave me through statistical modelling of outputs correlating to the results provided by business analysis" are in the past.

The days of "You said you wanted a user to be able to check their status anywhere" are here.