You may be in the software development business and not even realize it. Even if you’re not in a Silicon Valley startup, your job may require you to work directly and indirectly with the creation of apps and websites. The good news is it doesn’t require a degree in computer science or getting your hands dirty with code to be successful. It does require some understanding of what makes software development different than other kinds of work.
Following are some of the things I’ve learned or discovered over the past 25 years in product development. Some are counter-intuitive and others may seem obvious after trial and error. They’re just some things to consider.
Things that look easy can be really hard
For people who don’t write code, their frame of reference with software is something that’s already working well. This creates a lot of tension when someone expects the same from their products without understanding the complexity that goes into building usable software. Easy to use software is hard to build and takes longer. Really crappy software takes even longer.
Things that look hard can be really easy
This isn’t quite the inverse of the previous point. Most people who don’t know how to code think all programming is difficult. Sometimes a simple thing, like changing the value of a single varible can have an exponential impact on the overall product. Keep this in mind when you see a flaw. It may look dramatic, but the fix may be very simple. This information might help you from freaking out too soon.
Software is like gas
The work of creating software will expand to fill the space available. That goes for every aspect, not just writing code. If you say it’ll take 6 months, it will take 6 months. Software development never ever feels done. The more time you give it, the more time it’ll take (see also Parkinson’s Law). Oh, and schedules are like gas too. When you compress them they become more dangerous.
Simple isn’t easy
When people ask for software to be simple, they’re usually talking about the scope of the project, not the final product. What they mean is don’t take too long or cost too much. They assume it’ll be simple as a result of limiting those two factors. Developers and designers have a totally different understanding of simple, and know that’s harder to build. Agree on which definition of simple you’re using before you start.
Anything that ends with “bility” will add at least 2x to the scope
Concepts like scalability, flexibility, maintainability, usability etc. don’t just happen. They’re capabilities not just artifacts of good work. They need to be designed and planned which requires an agreed upon definition of success. Ask about these things if no one else does. Otherwise, everyone else may assume these things come along for free.
Architecture reduces the cost of development
It might sound like a frill, but putting some deep thought into your project before you start code will cost more upfront but save time and money ovarall. Be warned, it won’t feel like that right away. Also, look out for those who say you’re just “overthinking” it. They’re probably not big on thinking in general.
You have to slow down to speed up
When adding people to a project, you may have to stop everything you’re doing to get them up to speed. Review more than just the work to be done, but why you’re doing it and how you made the decisions so far. These questions will come up no matter what. If left unanswered, they’ll kill any initial momentum you may have had.
Sometimes starting over will get you there sooner, than staying the course
This is similar to the sunk coast fallacy where people throw good effort after bad. I also call this one, “stop digging”. People really freak out when they hear someone say “start over” in the middle of something. It’s understandable, and it’s not without risks. However, it can make the team more confident in the code they’re building. It’s only throw away work if you didn’t learn anything by doing it. Remember to ask if there’s time to do it wrong, when will there be time to do it right? They’ll hate you for it, but they’ll know you’re right.
Programming isn’t fungible
The universe of software development is incredibly diverse. There is no one single area of expertise when it comes to programming. There are backend developers, frontend developers, data scientists etc. They all have very different skillsets with little overlap. That full-stack developer who says they’re good at everything is most likely full of shit. Don’t hire someone because they know a programming language. Focus on the area of your product that needs the work.
Bad business rules and decisions make software unsuable
When people complain about the usability or quality of software, they almost always blame the designer or programmer. In my years of experience, I’ve seen more dumb business rules or decisions lead to bad software than technical incompetence. The sad thing is, business rules are a hell of a lot easier to change. You just need to scrutinize them as much as you do the building of a product. Saying something “has to do X” is usually a sign of a bad business rule being hard coded into the product.