We’re nearly ready to launch our first software product and it’s a big step for us. We’ve been working on it for a long time and from our first idea to the current version it looks so different! Will our customers like it? Will we receive some good feedback? Will we be eventually rewarded for spending 12-15 hours a day working on it especially in the last few months?
Are you curious about how we are working on Geek Divers? It goes more or less like this.
Jörg is the developer and he’s really good at his job! He’s also the database administrator and the technical architect. I’m the business analyst, the software tester and when it’s needed I have some more hats to use: travel manager, office assistant, I take care of the laundry and I remind him that it’s time to eat something 😀 We’re a team!
Making software is not just coding. There are hundreds of books and courses about how to learn to code, how to choose the best technology for your software product, how to design your database, how to use the best practices while writing your code or setting up your server, but there is a lot more about it. Having well written functional and technical documentation is a good start. These are evolving documents in which you start writing your plan and then you update them regularly. More or less like writing a business plan before you start your business and while you might not know all the financial forecast of the next 3 to 5 years, you’ll learn how to calculate that and then you go back and update your financial plan. 😉
In the technical design document you need to define which technology you are going to use, plan your architecture (servers, databases, firewalls, workflows, web services…etc.) and basically how you are going to transfer which piece of information from A to B, defining both A and B (and C and D and E… 😀 ). I know it sounds complicated and believe me, it is! And how do you know all this stuff before you even start? Exactly! 🙂 Sometimes you don’t have all the pieces of the puzzle. You start with the information that you have and then, as soon as you know more, you go back and update the document. While you setup all the components of your architecture, you document the steps, define parameters and choose the most suitable among the available services. It’s always a work in progress.
In the functional design document you need to describe how the end user will use your software. Much easier, right? Well, yes and no. Easier than writing the technical document if you have no clue about software architecture or database design 😀 but even the functional document can give you a challenge or two. You need to describe every feature and its purpose, what kind of data you need as input and what kind of data this feature will produce as output. For every feature you need to think of all the scenarios, even the ones that do not really make sense because if that button or link can be clicked, sooner or later a user will click it. And then what happens? The answer to this question might be a new scenario. 🙂 And that’s why you need to consult software quality experts as early as possible, ideally when you start writing the software documentation. 😉 The rule is “K.I.S.S.” (Keep It Simple Stupid) which is a principle that was invented in the ’60 by the U.S. Navy and later adopted in software development not to call the users stupid, just the opposite: the goal of good software is to make users’ life easier, so complex calculations and interactions happen in the background instead of forcing users to use pen and paper or spreadsheets to get their results, while pulling out their hair! Users should enjoy a pleasant and simple interface where everything is designed to be easy to understand and follow a straightforward process. And as in the technical document, every time you think of a new feature or you need to change the logic of an existing one, you need to open the functional document and update it. Ah, and the functional document must consistently follow the rules defined in the technical document or even the coolest feature might not be technically possible!
As soon as the development starts (or even earlier than that, if possible) you need to think of the software test plan, which is the definition of a strategy to “break” the software 😀 You’ve probably heard about software QA (=Quality Assurance) or software testing: testing a software product is a way of hammering down a piece of code to see if you can find its weak point. If you do, then you’ve found a “bug” or a “defect”, which is an unexpected behaviour of the software. Unexpected because in the functional document the described behaviour is different. So which one is right: the functional document or the software? A developer would answer: “it’s not a bug, it’s a feature” 😀 A business analyst would reply: “the requirement states that this is not the expected behaviour, so this is a defect” 🙂 And the software tester? Well, usually the poor girl/guy is blamed by both sides! Hahahahah! Welcome to the software development life cycle!
With Geek Divers all the above is done by the two of us and we are grateful for those 10+ years of experience in the IT corporate world because without those we wouldn’t have a clear idea of our priorities and know which strategies work well and which don’t. The clear disadvantage of counting on just two people to do different jobs is that we only have 15-16 hours per day (yes, we need to sleep sometimes…) multiplied by 2 which in corporate terms means 3-4 “man-days” per calendar day (and yes, we work 7 days a week, especially in the last 3 months!). The awesome advantages are the very quick decision making process and the effective communication and information sharing. You might think that the latter is pretty obvious, but we learnt to appreciate it, especially when we think of the old times in a big company!
So where are we? Right now we’re in the final stage of the software life cycle: we’re completing the development while testing and bug-fixing. To be completely honest with you, there won’t be any final stage because we will start again from the beginning and design new features or enhance the existing ones, but for now we want to “freeze the code” as soon as possible and “go live” with a QA-approved version of Geek Divers. Our first customers are already looking forward to using it and I’m sure that they’re going to give us some very useful feedback to make Geek Divers even better.
Do you own or manage a dive center? Would you like to try Geek Divers? Drop us a line at info@geekdivers.com. We’ll give you more info and you can enjoy a very generous trial period. 😉
Note to the techies: the software development life-cycle described above here is intended only as a simplification of the real process.