Software development is an immensely difficult undertaking. I run a small software development company, and I struggle to keep up with everything. I don't consider myself a programmer, but I've developed some stuff before on my own. I know enough to be dangerous. I do know database design decently well, so that is how I keep my developers in line. I will take a look at the database calls, the structure of the tables, etc., and from that can get a pretty decent idea of what is going on in their code. I rely on my lead developer to manage everything else. I do look at the code periodically. I've helped debug stuff and on occasion am even useful in my efforts.
All that said, what I do have is an ability to think logically, from the big picture to the small details. I know generally what software can do: what is easy for it, and what is difficult. I use this knowledge to design products that meet clients' needs without breaking their budget.
A number of years ago, IBM and a couple other companies did a study where they looked at the custom software market. Projects under $20m, they considered small. Small development projects failed, outright, 2/3 of the time. By 'failed,' they meant, 'the system was never put into long-term use.' What accounted for the vast majority of those failures? Poor system design. NOT poor coding. It was a lack of understanding of the problem they were trying to solve that directly caused the failure.
Why do I say all this? Most people get software development backwards: they Google "How to code," and get started on their project. This is a great way to learn to code. Its is NOT a great way to build a successful project, unless you like rewriting software for years on end.
The way to build a successful project is to:
1) pick the right problem to solve (easier said than done)
2) Fully understand the problem and its solution (also easier said than done)
2b) Figure out how to market the solution - marketing influences design and vice versa
3) Design a solution to the problem that is easy to code and that makes good choices about where to spend development effort
4) Do the actual coding
5) Test & release the product
6) Market
7) Build support systems around the product
8) Learn from your mistakes and iterate
As you think about your project, make sure you spend enough time on steps 1-3.
I typically rely on my clients to be experts in steps 1-2, so I'm not the best person to ask about what to do there. Maybe other people can chime in on that?
Edit: it occurs to me that steps 1-3 are interdependent. Picking a problem that will cost at least $100M to solve using software isn't good. Designing a marketing strategy that relies on code that is expensive to build/maintain isn't good. Designing a solution that can't be marketed easily isn't good either. You have to either be really good at all those things, or work closely with people that are.
All that said, what I do have is an ability to think logically, from the big picture to the small details. I know generally what software can do: what is easy for it, and what is difficult. I use this knowledge to design products that meet clients' needs without breaking their budget.
A number of years ago, IBM and a couple other companies did a study where they looked at the custom software market. Projects under $20m, they considered small. Small development projects failed, outright, 2/3 of the time. By 'failed,' they meant, 'the system was never put into long-term use.' What accounted for the vast majority of those failures? Poor system design. NOT poor coding. It was a lack of understanding of the problem they were trying to solve that directly caused the failure.
Why do I say all this? Most people get software development backwards: they Google "How to code," and get started on their project. This is a great way to learn to code. Its is NOT a great way to build a successful project, unless you like rewriting software for years on end.
The way to build a successful project is to:
1) pick the right problem to solve (easier said than done)
2) Fully understand the problem and its solution (also easier said than done)
2b) Figure out how to market the solution - marketing influences design and vice versa
3) Design a solution to the problem that is easy to code and that makes good choices about where to spend development effort
4) Do the actual coding
5) Test & release the product
6) Market
7) Build support systems around the product
8) Learn from your mistakes and iterate
As you think about your project, make sure you spend enough time on steps 1-3.
I typically rely on my clients to be experts in steps 1-2, so I'm not the best person to ask about what to do there. Maybe other people can chime in on that?
Edit: it occurs to me that steps 1-3 are interdependent. Picking a problem that will cost at least $100M to solve using software isn't good. Designing a marketing strategy that relies on code that is expensive to build/maintain isn't good. Designing a solution that can't be marketed easily isn't good either. You have to either be really good at all those things, or work closely with people that are.