What should you know about software development (if you are not technical)
So you want to build a software.
No matter if it’s web, mobile or desktop app, you have to start somewhere.
We can specify a couple of points that you have to know in the beginning:
1. Describe business logic of you idea and write it with use cases.
2. Have knowledge about creating project documentation.
3. Know methodologies and development process.
4. Know how to choose a software house or freelance developer.
5. What technology you need to use.
6. Know IT jargon (scrum, deploy, use case, migration, refactor and a couple more)
Ok maybe it’s not just a couple of points. So let’s start from scratch, theory that will be useful for any non-technical person to understand IT. Later on we will move to more specific topics.
Who is this article for
People that want to build a startup, app, platform, game, any piece of bespoke software which will be outsourced to external developer or team, or even it might be a foundations of your own company. Also for business owners, who want to better understand software creation. We’re not talking here about corporate level with business analytics and milion dollars budget, let’s simplify or at least explain software development for average people who want to do something cool.
1) How to explain your idea to IT
General idea can be written in a couple of sentences to give developer a big picture. Some visualization would be awesome, like drawings, screens, wire frames are very welcomed. You don’t have to know anything about graphic design and do awesome wire frames using tools like:
www.uxpin.com
www.sketchapp.com
or a simple presentation tool like:
www.prezi.com
The best way of finding connection between your idea and developer who will implement it are Use cases.
When you have your idea formed in your mind, it should be easy to write it this way:
User Can register to the app using Facebook account. It will allow him to use platform.
User Can get to his profile settings by clicking his photo in the top right corner. It will open a popup and allow him to change his details.
User Can Add picture to his favorite pictures list, it will allow him to view it later in favorite pictures view.
I hope you get the point. Don’t skip any part of examples above. Adding ‘It will allow…’ is as important as the beginning. It will explain why something should be done and what is expected result. When you describe your app in such points it is much easier for developer to understand what functionalities are needed to be implemented. When you support it with wire frames it should be pleasure to watch how your idea is converting into code specification.
Also it has a significant advantages for you:
– you do it once, and it can be send to multiple developers
– you describe your idea in details, so it’s much easier to create some high level documentation
– estimations are extremely difficult in bespoke software creation – this way you narrow the misunderstandings between your vision and final documentation
2) Do documentation, always.
This point is extremely important, and don’t get me wrong, lacks in documentation is the number 1 problem between client and software companies. Let me explain why.
Detailed documentation of your project, what software should do, and what behaviors you expect from the system is a must. And both sides interest is, to have it done best way possible. Documentation should be done by software company, but it’s your job to control if it contains everything. Software house will estimate only things that you will give them, nothing more, nothing less, nobody can guess things that are only in your head.
When you are signing up a contract for software implementation, it’s done. Off course we do agile, scrum, try to make it as fair as possible for both sides, but let’s simplify to fixed price for a moment. You pay for what is written – documentation, description, wire frames. Everything that don’t work is a bug, anything more than in contract is a feature. You should expect that everything will be done on time, with all functionalities implemented.
When there is a bug, something is not working correct, and it is specified in documentation, it is clear that developers made a mistake and it should be fixed on their own, with no extra cash from you – it happens.
BUT
And this is a big but, when it’s not in documentation, probably it’s your fault – and it also happens. It is your best interest to have everything in a written form to avoid such situations. That is why this point is so important, and where most of the problems come from. You can’t change requirements and expect more in the middle of implementation (again, agile kick in here, but please wait one more paragraph).
Example: imagine you put some title on wire frame and that’s how it’s implemented. Meanwhile you think that it would be nice to be able to edit this text from admin panel, so many other fields are editable, probably changing this one won’t be a problem. It won’t, but don’t expect that software house will do it for free.
This example is trivial, but sometimes small behavior change, can take developer a couple of hours, and involve (like last example):
– switching simple text into 2 components: view and edit
– adding logic which should be presented and when
– adding field into database (when something is editable it must be stored somewhere)
– adding code that will send / read field from database
It’s not a detailed description, just shows that sometimes trivial change is not so trivial in code.
Documentation is a two-edged weapon, use it wisely and you won’t have problems with software development.
3) IT like and should work in agile.
And finally, the famous agile. It will be simple explanation, you can find books, courses, certifications and probably much more about agile. Lets simplify this for a ordinary mortal.
Estimating software implementation is a nightmare. No matter how much somebody says he’s good in it, it’s impossible to say that implementation of this app will take exactly X hours. We can estimate and give some overview to amount of work, but as guys from ‘Rework‘ say: “Estimations are guesses” and in IT I must agree with it. There are too many ingredients to be precise, especially when you are trying to estimate many months work of multiple developers on different levels of experience with 2 payment systems integrations which API just changed and documentation is weak – in one project.
But, here comes agile for a rescue. In simple words, development in agile methodology means:
– get your big piece of software
– divide it into smaller parts where every part brings new value for the client
– get every part and try to fit it into chosen time frame
– now you can estimate how much you can do during this time and act accordingly
– you pay only for job done – if you like it, cycle repeats. If not, you pay only for job done up to this date and get software somewhere else where you don’t start from scratch.
It would look like this, when you compare your app development for a car:
Source: Spotify’s MVP Process
I think it is a fair deal, both for developers and client. Also when you are planning a work for next 2 weeks, you can be much more accurate than 6 months project. Another advantage is, that after each sprint (~2 weeks period depending on methodology) you get something to see / test and you can provide feedback if everything is consistent with your vision or not.
This is a shortcut of what you need to know about agile, scrum, kanban or any other wild animal IT will develop through next years to do better job. Don’t learn details about any particular methodology, it is on IT company side how they organize their work and should explain it to you in details.
There is one more thing which a lot of clients don’t understand. (Probably now when you know what is agile and why it’s worth using you are not in this group) In many businesses you get fixed price and here IT comes with all this methodologies, sprints and so much stuff – NO I want a certain price for certain project, period. Off course it is possible. But take into account that the price will be around estimated hours * 2 (the bigger portfolio, the bigger multiplier). And for software house it still isn’t a 100% safe deal because of all ingredients I was talking about.
4) Freelancer or software house.
This is quite a big topic, probably for a separate article, but lets simplify. It depends on the project size, budget and deadline you have. Off course bigger company will build it faster than a single person, but will have less attachment, than a freelancer (off course if you find a good one). Software house probably will have higher price but you buy their experience and guarantee that when some developer get sick, job still will be done by somebody else.
When project is small and you don’t have some strict deadline, looking for a freelancer will be a good idea. On the other hand, when project involves a lot of work, for specialists with different skills, looking for a software house that already have similar projects in portfolio might be the only way.
When you are looking for a long term B2B cooperation, doing business with software house is much easier than with a freelancer(s). In the end results will speak for every company and recommendations might be the best way to find one.
5) Technology
What should you know about technology, programming languages and why.
There are thousands of programming languages, frameworks and libraries that programmers use on a daily bases, and it’s their job to know it. Each technology have it’s purpose and should be used for it. I don’t participate in all this debates that this framework is better than the other or this programming language is faster than that one.
Be open, talk with different people about your project and ask for technology they suggest. This part is hard and I can’t really give a good advice. Software house that have awesome Java developers will tell you that it should be written in Java. Another that build everything in React will laugh about that idea and will tell you that it will be 100 times faster to implement in React.
Ask and do your own research, that is the only way to start.
6) Jargon
Software developers have their company / industry specific jargon and it’s pretty natural. The problem comes, when developer is trying to explain something and get a little bit too much into technical stuff what is natural for him. To avoid simple problems you should know a little bit about software development terminology. This article is a very good starting point, you know now what is agile, how to construct use cases, and why sometimes simple change can cost you a lot of money.
I will describe most common terms like deploy, version control system or refactoring in next part of this series.
Stay Tuned!