There is a fundamental problem in building software, and that is deciding what to build. It is fundamental because everything else rests on this one decision, and it is often overlooked, or made in the wrong way. Because everything else depends on it, you have to start at ground level, from first principles, if you want to make a sound decision.
Thinking from first principles is simple but hard. Very hard.
The need for a piece of software may come from several directions. It may arise because of a critical need of the business. Then again it may be only a perceived need. It could be an impulse, driven by one strong personality or the tide of politics internal to the business. This would not be good.
You may need software because of new laws that must be complied with, from fear of competition, or just because you're feeling a little behind and want to keep up with trends by copying everyone else.
A good reason will arise from a true need, and if carried through it may result in a real benefit to your business. If you are working from faulty principles though, you will have not only a poor foundation but a poor result.
You need to know your business through and through. And your customers. One way or another you are in business to do something for someone else, something they cannot do, or do not want to do, so they come to you. If you can deliver they will be glad to pay you what you need to get by. But you do have to keep their needs in sight.
Somewhere along the way you will have to deal with staff, even if you are self-employed. The people you directly employ are the experts in running the business. They know how things work, and when, and all of them are acutely aware of exactly everything that does not work. They are your surface of contact with customers, the membrane your business breathes through, its nerve endings.
Staying close to your customer's needs is critical, but so is anticipating where they might be going, so you need to make your decisions match the long term interests of the business. With the customers, and your staff, and the long term in mind, go for the greatest gain possible from the minimum investment, but always focusing on that "greatest gain".
Plan to start small, with something functional, something you can use tomorrow, or the day after, but don't shoot for something sometime next year. You need to start small and see how it feels, then let the software evolve and accrete over time while it's being used, and lead you to a successful end point.
Evolution is a wonderful thing, and it has a proven track record.
If you build software that your business really needs, and start small, and keep adding to it, then you will get to keep testing it every day, starting from the first day, when that software is still very small and very simple.
Daily stressing of any living thing is the best way to have it grow up to be strong. The more you use the first parts you create, the more time you will have to fill all the gaps, and build more and more strength. As time goes by, your foundation will be more than strong enough to support the whole edifice, no matter how big it gets, and the whole structure will have been thoroughly tested by time.
By starting small you will also be able to stay within your budget, and within your competence, and assess all risks. You can measure small things pretty easily, so when faced with small problems you will be able to head them off, knowing that they do exist, and knowing exactly where they are, and that they are small. You can also measure progress a whole lot better on a small project. Because it is small, it is small enough to understand.
By starting small you can also keep an eye on resources. Not just money, but time and the energy of your staff as well. Burning through your money, wasting your time, and flaming out your staff are all bad, but much less likely to happen when your project starts small and grows organically.
Then, with a little success under your belt, and because you have learned to assess risks and measure resources, you can think about going outside your areas of maximum comfort and competence and gradually branch into new areas.
But first, last, and always, you have to keep your head on straight. There are some deep pits to fall into. Maybe you don't need software at all. If you do, you will likely be better off buying something rather than building it.
If you do decide to build software, there are two attitudes you especially want to avoid. One is dismissive, and it runs something like "Why should I have to get involved? You're the computer people. You should know what to do."
The other is arrogant, and follows the rule that we all have running around in our heads, no matter who we are, that if I don't understand something, then it can't be important, so I don't have to pay attention to it.
Considering that about 80% of software projects still fail all these decades after computer programming became a thing, you really want to avoid a losing attitude. If you are going down the route of building software, then you have to be real. You have to be serious about knowing what you want, why you want it, and what it will do.
You need a real plan, you need coordination, and you have to measure everything and make sure that you are on track. You need to keep checking your sanity all the way through, and every day you need to wonder if this is really the right thing to be doing.
If you don't treat software development like a real job, it can eat you up and put you right out of business. It happens every day.
Have anything worth adding? Then try sosayseff@gmail.com
Me? Yep.
Etc...
so says eff: sporadic spurts of grade eff distraction
definitions: outdoor terms
fiyh: dave's little guide to ultralight backpacking stoves
boyb: dave's little guide to backpacks
snorpy bits: nibbling away at your sanity
last seen receding: missives from a certain mobile homer
noseyjoe: purposefully poking my proboscis into technicals