Questions to Ask at the Start of a New Software Project | Hacker News Reader

Questions to Ask at the Start of a New Software Project

spin.atomicobject.com

118 pointsphilk1032 comments

For me as a noob working on a SaaS product that gets pretty highly customized I usually try to tease out as much as possible what will need to be modular / customer customizable.

I never get it 100% right but I want to avoid as much customer one off code in the product as possible so I don't have to go out and dig it out and make it modular later. When I get it right it really reduces the amount of time setting up a new customer.

In addition to those described in the article, i have following question on my list:

# Risk

* What are the platform constraints?

* What are the performance constraints?

* Get clarity to what is an acceptable upper bound.

* Would it be acceptable if it took a week to calculate or 20 minutes to open the application?

* Does it need to happen in 30 seconds or 5 milliseconds or 100 microseconds?

* Can you demonstrate a failure?

* What happens when you go off script?

* Most of the complexity is in handling those off-script behaviors. If that’s not being handled well, the project is definitely not “nearly done”.

# Definition of done

* How does the “Definition of Done” look like? Ideally from whole project down to single stories.

* How would you verify that this is working correctly?

* What is the success criteria of this product?

* What does “good” look like?

* What will make it a worthwhile endeavor?

* What are other pain points and blockers?

# Costs

## Opportunity costs

* Is this the most valuable thing we can be doing?

* Is an 80% solution good enough for your needs?

* Is this work really where your team can add unique value?

Other question one might ask to get a feel for the lost opportunities:

* Which parts of the current system are hard to use?

* Which manual process stops the customer to do more creative, value-adding work?

* What changes would improve operational inefficiencies and save money from the bottom line?

* What evidence can you show that this will solve the problem?

* Provide a simulation or prototype or fake (but statistically relevant) data which can demonstrate the solution is at least plausible.

## What connects to this?

* Things with a more complex network of dependencies will be more costly to develop and maintain.

* What systems will depend on this?

* What systems will this depend on? Enumerate all the dependencies. Other systems, libraries, users, protocols, everything

## What’s Plan B if this doesn’t work?

* What are you going to do when we’re up against a deadline, this solution isn’t working as expected, everything is broken, and we still have to ship?

* Get an answer to that, then do that first. Then you can talk about how you can make it better.

* What would be the earliest point you can know whether the system has any value to you? What is the smallest step that would give us the most benefit? How will we do this?

* If we could keep only half the features what would they be?

* What if we take one dev away from this project?

* The 80/50 Rule:

If you’re not 80% done by the time you’ve used 50% of your resources, you are behind. When something doesn’t pass this test, it’s time to evaluate what needs to change:

* Does this project need to stop?

* Do other projects need to move? “I can make up the time” is not a realistic response.

# Maintenance cost

* How long will the system survive?

* When will this system be scheduled for replacement?

* During what period will you be making no changes to the system except for critical bug fixes?

* What are the prerequisites for using the solution?

* What must continue to be true?

* What do users need to know?

* What does the data need to look like?

uh.... sorry but that's now how we do things anymore.

Please submit this as a medium article with unnecessary and unrelated images or as a corporate blog post so that you can improve your seo ranking.

Highly recommend Shape Up by the basecamp team:

https://basecamp.com/shapeup

It's free. It's good.

The article doesn't say who should be asking these questions. I hate to say it, but sometimes "ordinary" software programmers (the most dangerous are the kind with just a little experience but not enough to know that they don't know) will start to feel that they should be asking these questions of the people asking them to build something. It's a good sentiment, but often (especially when there are sales/competitive/pre-emptive/other factors) at play, they're straying a little into "too big for your britches" territory and should just build what they're asked to. Leave the questioning to the engineers who both know how to build it in their sleep, and understand why it's needed...

For any business, the people responsible for a managing a project will also be the people that are both experienced and informed about various important factors that come from being at the level both related to the business and in terms of management skills.

If a new dev asking a questions is enough to derail a project there were bigger issues at play.

As a counter-point, I think it is good to also consider that even the wrong people asking the right questions is better than no one asking them. I think discouraging fledgling developers from asking these questions is a short-sighted choice. I believe a better choice is to have an environment where they can be guided to the right answers, even if they are "too big for their britches".

At my employer, engineers at every level are accountable for their work's business impact more than anything else. It is always your responsibility to understand and be convinced of the value of what you're doing, and to escalate your concerns or transfer out of the team if you're not. "The product requirements were ill-conceived but I executed them well" will not save you at performance review time, even if you're a new grad.

A competent PM has considered these questions carefully, and most of their thinking should be written down and circulated before the project starts. They will happily discuss lingering questions with anyone interested.

But how do you expect junior devs to get those skills, if your response to them when they try is, "Stay in your lane."

Everyone should be able to ask, that's how they learn, and sometimes that guy down in the trenches knows something that is in the plumbing that other folks don't automatically know.

I'd like to better understand your angle / experience here... it seems to me like death march projects start when questions don't get asked up front and/or developers put their heads down and do what they are told instead of being proactive in heading off challenges.

These are product-centric questions.

> What business risks or blockers exist?

Thats not a question that's readily available to developers, nor is it relevant until the project comes up in planning.

why not? developers are a key part of a business and shape it. they should certainly be paying attention to managements initiatives and what risks or blockers these may present to the project at hand. this would encourage alignment and clarification.

I'd like to add: Why does it have to be a project? For me atleast "project" usually implies too much upfront planning and not beeing very lean.

Where I work (a large, global corporation) a project is usually something that is so large that it requires it's own budget and involves so many different system dependencies that it is unfeasible for different teams to manage between themselves within the normal line of work. A project manager is assigned to it and he or she gets directions from a steering group, and there are multiple milestones to check if the it is ok to proceed to the next stage. Usually, in these situations it also motivated to have an assigned architect, an assign requirement specialist and an assigned test lead to take overall responsibility in coordinating respective areas.

If it happens that the scope is actually not large enough to motivate a project setup, this will be wasteful and inefficient. But if the opposite happens, that the scope is very large but it is not implemented as a project, it can lead to disaster. Typically, the solution will not work end-to-end because no one have had the complete picture.

EDIT: Forgot a word

I spent almost two years on a project of such a nature at a ginormous company in the low 8 figure budget that changed on an almost daily basis and was killed at the last second - in order to start an even larger and looser project, while simultaneously starting a second similar project in insane fashion. Coordination is mostly a hostile battle between high level execs, with lots of promises of this time it will be different and never is. I always question decisions if I can but often you get no access from a technical level to the people deciding (and battling about) what is to be done, so often you can only deal with lower level decisions in your area. Sometimes you win a little but often your winnings are lost in a sea of terrible decision noise.

Then again I've been in tiny companies with low 6 figure budgets for projects and you still wind up powerless to ask the right questions.

Sometimes you have to settle on getting your part of a giant project right and sigh your way through the rest.

The word project has a specific well known meaning in business. It is a work effort with at least these criteria:

* A start date

* An end date. Every project has a termination date, otherwise it is described as something else.

* A stakeholder.

* Business Requirements Document (BRD).

"too much upfront planning" is one thing I've never experienced before. perhaps, you mean wrongful planning or indecision?

I'm not a programmer/dev, however ...

You can plan and plan and plan. Then start and realise that you should have _tried_ earlier because that informs the planning more (close the loop, iterate, go again). That's why prototypes/MVPs are a thing, surely.

I can see how this is possible, but I've never experienced it. On the contrary, I see people just do and do and waste effort and redo because of things that could have easily been foreseen with a plan based on input from all stakeholders. Meaning, yeah, I see someone make a plan on their own and inflict their plan on others, but that is just a bad plan.

It easily develops into subcategory of "wrongful planning". I.e. planning things the people doing the planning do not have the expertise to make decisions about, but they felt like they needed to plan it. And now you're stuck with it, because otherwise someone would have to admit they didn't know what they were doing while justifying a change from the announced plan to the customer. (yes, there's a lot more than that wrong with the situation in that case)

> "too much upfront planning"

Maybe bad assumptions, or a general unwillingness to validate assumptions?

(IE, "Too much planning," not enough iteration / stakeholder feedback.)

Not the GP, but long term plans are at best inaccurate, worst case completely wrong. Plus, you spent all this time planning instead of implementing/discovering.

Both mindsets are necessary, and it's also possible to go too far in both directions. I've been on teams that took planning to an absurd end, which resulted in obsolete plans as soon as implementation started. I've also been on teams which went around in circles because they didn't have any direction and their implementation/discovery wasn't focused on a clear goal.

Long term plans are only inaccurate or wrong if they're over reaching. Plans, like every other part of a project, have to be able to change and grow throughout implementation. It's not long-term planning that is the issue, it's the stagnation of overbearing plans.

> Long term plans are only inaccurate or wrong if they're over reaching.

True, but for me the real problem is actually identifying that ideal amount of planning for some project.

It's easy in hindsight to say something was over reaching or not enough planning was done, but not always that simple prior to starting a project.

Ideal planning vigor and scope seems super context sensitive to me and even with experience I often feel I get it wrong.

There's no such thing as perfection, only the pursuit of perfection.

Hindsight is a crucial part of making sure you don't make the same mistakes. Don't worry, you'll have plenty of opportunities to make brand new mistakes.

Funny you say that. The way it goes with my boss is :

- boss: Yeah, don't spend too much time on planning it will be at best inaccaurate

- me: ok; I make a plan and, well, there are known unknows

- later on, my boss: why have you those unknowns ? don't you think it's obvious that unknowns are a problem and that we can't show our customer we have unknowns because we're-professionals-we-know-what-we-do ?

- me: err... well...

They're inaccurate, but they're fundamentally fate altering when you can put some pieces of information together to generate a non-obvious conclusion that prevents a huge disaster. Good planning is not about assuming something works, that's where most of the time the plan is wrong, it is to assume something doesn't work, and what can be done to forge ahead in such a case. Good planning is also revising plans any time new information is learned.

Technically, project is any task with a start or an end...

Oh, hey, Atomic Object! Just wanted to say it's neat to see you guys on here, and, if you're from the AA office, hello from just the other side of 23.

Reply on news.ycombinator.com