A lot of software developers like to make things complicated. They get something that could be simple and easy and, due to what most people tell on the internet, make it complicated.
Software should be simple. Said that, it's easy to understand why so many developers have a hard time building software from scratch. In their minds, it's a totally complex and difficult thing and they get completely stuck in the middle of the process.
So, the question is… How do you build software from scratch?
Transcript From The Video
John Sonmez:
Hey, what's up? John Sonmez from simpleprogrammer.com. Today, I have a question about building software from scratch. This is a question I've gotten a lot of times from a lot of different people because this is something that is difficult to do when you're a beginner, to figure out how you could ever do this.
This question comes from Akash and he says, “Hey John, your videos are great and I highly value your advice. One problem I face is that when it comes to building a big software, I cannot think of how to design the whole thing from scratch. Say, how to break the whole thing into mini sub-tasks and then implementing each sub-task and putting them all together to make it work. It would be very nice if you can guide me on how to overcome this problem. Thanks in advance.”
What I would say here, Akash, is that what you want to do is you want to think—instead of thinking about taking a whole system, this kind of the top-down approach, break it down to all these pieces, assembling all these pieces and seeing how they fit together, and building this massive Transformer or Legos from—these huge Legos. You want to think of software development more like evolution.
What I mean by that is that start with something really simple. Start with the simplest thing that could possibly work that doesn’t have a lot of features and then evolve that into where you want to go instead of doing what they call big upfront design. It doesn’t mean that you should never like think about the overall architecture of the thing and that you don’t have the designs and certain things upfront. In a lot of cases, you don’t have to do as much of it as you think you need.
Now, if you're designing some software that is going to be embedded inside of an electronic device and a hardware engineer is going to have to develop the circuitry or a custom chip, or something for that to work, you're probably going to have to design a lot of this stuff upfront and you're probably going to have to do that. You might even be limited there. For most software that we're building today, especially web applications and things like that or mobile applications, we could build something that is very, very basic and then evolve it, make changes to grow it and to add complexity as needed.
One thing—one reason why this is so important is because the bane of software development, one of the worst things in software development is complexity. This channel is called Simple Programmer and my business is about making the complex simple, because that's what we need to do. As software developers one of your main jobs is to fight complexity because complexity comes into the system and it makes it difficult to maintain and makes it difficult to understand. It makes it more likely to have bugs and to fail. We want to reduce the complexity as much as possible. We want to simplify. We need to start as simple as possible, what is the simplest possible thing that could work?
A lot of times in the entrepreneurial world, they call this an MVP or minimal viable product. What can you do when you're trying to build a big software system or what you can do is that you can start really small. Start with a very, very small thing. I'm trying to think of the book, but I read this really good book on something, I think it was test driven development step-by-step or something like that. In the book, he was designing like a Notepad app or something. He started off with very, very incremental—he did this in a very incremental way and he started off with, I think, his application needed a database, but he started off with not having a database. Instead, just like storing the data in text files that he read from the text files. Then he got to his point where he needed to actually put it into a database, and then he modified the program and made it read the same data, except he created an abstraction to read from the database.
That's the natural evolution of things and that's how you can build this complex software. I guarantee you, most of the complex software that actually gets built today is built in this manner. A lot of it is not designed all the way upfront and then build all these pieces and hope and pray that they work. Otherwise, it ends up going way over budget and way over schedule. Unfortunately, that does happen. If you want to be successful, if you want to be able to do this, just start with something small. There's nothing that is difficult in this world. There is nothing that is complex. It is only that it's composed of a bunch of simple things that make it seem complex.
You can build the most complex architecture. You can build a huge thing, but you have to start with the simple. It's all composed of the simple. Then instead of trying to just take all those pieces, just start. Evolve the thing. Start. Build something. What is the smallest simplest thing that you can put out that does anywhere close to the functionality? Then start adding features. As you add the features, then you add the architecture to support them and you create abstractions.
A book that I'll recommend that would probably help you to do that is called Clean Code. It's one of my favorite books by Robert Martin. I definitely recommend that book, but you want to evolve your architecture. Then the other thing I would say about this is that as you evolve things, you're going to create abstractions to keep it simple so that you don't ever have this huge, huge complexity. Sometimes it might even be rewriting the entire thing or rewriting parts of it, but that's fine. That's how the evolution of software works. It's better than adding complexity.
A lot of times software developers want to prematurely optimize. They want to make things extremely flexible. They're doing premature optimization on the software because they're trying to build this very, very robust system. That often fails because we don't know what we don’t know. We don't know what we're going to need so it's better to not try to anticipate it, but just to say, “Okay. Now, I need to add this new feature or make this work in this way. How can I evolve it?”
Remember, software development is not like a bridge. It's not like you've got concrete laid and now you're going to change the architecture of the house. Software is malleable. It's like clay. You can change it around. It doesn’t have a high, high cost for you to modify that and to change it. You need to use the advantage of that medium as much as possible, which lends itself to an evolutionary process to develop software, as opposed to a big upfront design.
I hope that helps you Akash. Great question. I think a lot of people have asked about this in the past. If you have a question for me, you can email at john@simpleprogrammer.com. I appreciate you. Stay tuned until next time. Take care.