I'd ask yourself "How would a human accomplish this task if computers didn't exist?". Then think of how a computer can be used to then do the same work. The reason I say this is that many people write super inefficient code that does things in a way that no intelligent person ever would, just because they see the work the computer does as effortless. For example, if you were going to walk through a warehouse of toys and count the number of blue toys present and the number of toys made of plastic, would you figure out a way to look at every toy in the warehouse only once, and record if each toy was in either one of the categories, or would you walk the entire warehouse twice looking for only one attribute at a time. You'd walk it once right! You can't imagine how much code I've seen that does things in horribly inefficient ways. Therefore, plan the logic, then write the code.
ImDinesh Sharma wrote:
suppose your project manager and designer just comes to you and discuss about application they want you as developer to build.
What kind of question would you ask yourself in that situation?
As someone who prefers agile software development, I'd probably ask, "What the hell am I doing working in a place that has project managers and designers telling developers what to build? And when am I going to wake up from this nightmare?"
More seriously though, there are different ways this can be answered depending on the perspective you take. Matthew takes a somewhat micro level perspective. Let me take a more macro level.
(Note: This reply is largely influenced by the fact that I'm currently reading Jeff Patton's book, "User Story Mapping.")
Some of the first questions I'd ask:
1. Who is this for?
2. What benefits will they get from it?
3. What problems will it solve for them?
By understanding the answers to these questions and other questions that come out of them, you create a better understanding of what exactly it is you need to build for the users of your software. Jeff Patton writes, "Your job isn't to build more software faster: it's to maximize the outcome and impact you get from what you chose to build."
So one of the first questions you should ask after understanding the who, why, and what is "How much (or how little) do I have to build in order to have some kind of impact?"
Before I even think about what kind of classes I'd need and how performant I want my program to be, I would ask:
1. How do I ensure that I've created the right thing?
2. How do I ensure that I've created the thing right?
These questions lead me to a couple of practices I recommend:
1. Behavior-Driven Development (BDD) - gives you confidence you have created the right thing
2. Test-Driven Development (TDD) - gives you confidence you have created the thing right
What I'm getting at is that before you think about classes and algorithms, you might want to think about tests:
1. What tests will tell me that my software satisfies the users' needs?
2. What tests will tell me that my software has been built in a way that is maintainable, robust, resilient to change, and amenable to change?