10 Things about Software Development Process for each CEO

Introduction

Developing software is no easy feat. But sometimes, watching it being created from the sidelines is even harder. Oftentimes, CEOs, managers, and other stakeholders get overcome by frustration simply because they don’t fully realize how the software development processes look like.

Here are some truths about developing software that might clear some of that confusion.

#1 Everyone’s perspective is limited

You probably want to look at the to-be app as a ready product – aesthetically pleasing and seamlessly working for you and your clients.

The devs don’t necessarily always focus on the same things as you do. Even though the product’s vision and your requirements should always be the main drive to what they do, they don’t always fully embrace the business part of your needs.

Mostly, their priority is to write a high-quality, clean and functional code.

That is why it’s important to be as thorough as possible while explaining the product’s vision and purpose to the dev team. It’s even better to have a Product Owner on board, who will not only keep that vision in the foreground but also help plan the work accordingly. This way, their means become your goal and everything is all the better for it.

#2 Features don’t equal quality

Focusing on quantity of features instead of the quality of the essential ones is the bane of the existence of many developers out there. Probably, the more gutsy ones, that would be ready to tell you the honest truth, would say that focusing on good quality will:

• Increase the usability of the app for the end-users, who don’t have to sift through tens of features he’ll never use in his life
• Decrease the potential for unforeseen bugs and downtimes
• Make upkeep and maintenance much easier for everybody involved
• Allow for a more thought-out, user opinion-based development in the future
• Save you quite a lot of money, as you wouldn’t have to spend it on unnecessary components, refactoring, maintenance and even server space

So if your devs, UX Designer or Product Owner suggest that your budget can be better spent on honing and properly testing the Minimum Viable Product (MVP), please take their word into account.

#3 There are more people involved than you think

We can safely assume, that you are a CEO and/or a businessman and this is what you want to focus on – developing your business. Not constantly keeping tabs on how the coding is going. That is why a good, versatile team that takes care of the whole software development process in your stead is the best thing that can happen.

This means not only the developers but someone to take care of the designs and testing as well. Add to that a Scrum Master and a Business Analyst and suddenly, there are quite a few people taking interest in making your project awesome.

Is it worth it? There are pros and cons, as with everything. But the most important thing should always be for these people to be useful to you.

#4 It takes time

In corporate and marketing settings, there is never enough time to deliver perfect products and services. Everyone struggles with deadlines. This is a much less pronounced but still important issue in software development.

Why less pronounced? Because good software doesn’t get created in a week. If you’re really after quality, it’s good to give a proper amount of time for the team to plan, design, develop, check and test it.

Usually, a medium-sized project will be handled by 5-7 people and all they need to do is to coordinate with each other and swap parts of work and add their own for someone else to verify it. The more you scale, the more coordination and development time is needed, as various dependencies grow in numbers, both development process- and code-wise.

Taking this into account while planning budget and marketing is highly advised – a Business Analyst on the software house‘s side can usually help to gain perspective on that.

#5 You get what you pay for (In timeframe you give)

No one likes to overpay, but let’s face it – developing software is pretty similar to buying a car. The cheap ones are rarely worth it in the long run. Sure, you might get lucky and find a great bargain, but more often than not, you’ll just end up with a golf cart where you expected a Mercedes.

It rides, has a steering wheel and even a breezy AC system (in certain conditions). But it’s not exactly the vehicle you want to take to a Wall Street business meeting, is it?

If you cut corners with your funding, the same applies to app development. Developers will try to do their best with the time you’re paying for, Product Owners will push them to deliver as many of the important features as possible. But will there be enough time to insert that ‘zing’ that all great apps have?

If the deadline is too short, will they manage to carry out the awesome vision you have for your product?

#6 All information matters

There is no such thing as too much information in software development. The more the development team knows about your approach, future plans, and current going-ons, the better they can plan and prepare for anything you might throw at them in the future.

There is no such thing as too much information in software development.

A single time when they don’t know about your prolonged vacation can result in an important decision not being made. A miscommunicated plan change can lead to the development of completely unnecessary features that would have been essential before.

Even an idea you have loosely formed in your head but decided to not share could have become a great opportunity to further improvement of your project.

Good communication is absolutely crucial in an endeavor as big as software building. So when in doubt, share your thoughts – a good team will only appreciate your input!

#7 Developers assume you know things

Devs are a highly specialized bunch, with their technical terminology and code-oriented approach to life. And like all specialists, they assume that at least basics of what they talk about in meetings are common knowledge.

If you don’t ask for clarification when one is due, they will most probably move on without a second thought.

That is why it’s necessary for you to speak up when things are unclear – you might be missing some vital information in what you don’t understand.

It’s in the interest of both parties to avoid communication impediments.

#8 There is no such thing as a perfect plan

This is the kind of truth that everybody knows but is very hard to take into account while working with outsourced projects. You might have the best, most optimized plan for the development process best practices that has even the parts that not many people take into account – testing and refactoring time, holidays, even the vacation quota for each team member.

And then something goes exactly the way you didn’t account for.

This could be anything – a feature takes longer to develop than anticipated, one of your stakeholders pushes for early release (because marketing), heck, the Tech Lead’s kid gets sick.The lesson here is to first and foremost keep a mind open to change.

Today’s Agile approach to software development is a tremendous help in this regard. And as long as communication inside and around the project flows efficiently, this collective effort to talk, listen and adapt should be the main development process focus.

#9 Different devs speak different dialects

There are various programming languages. And one might expect, that they behave the same way normal languages do – you learn it and use it in accordance with some pre-established ‘grammar’ rules.

And more often than not, a software house should be treated as a region in this international landscape – it probably has its own ‘dialect‘. This means, that aside from the basic ‘grammar‘ of the language, they have their own additional rules that help the natives unify their code and create it more efficiently.

Those rules vary between companies and often it takes a long while for devs to find their way in the legacy code they inherited from another software developer.

That is why it’s always good to make sure, that whatever is being created for you comes with a thorough documentation that allows for an easier transition.

#10 Development doesn’t end on release

Your app went live, everyone is ecstatic. But is the software actually done with? 99% of the cases the answer will be “no”.

Maintenance is needed, your users will probably come forward with wishes for improvements and new features, even the system and browser requirements will sooner or later need some work on upkeep.

That is why it’s always good to think in long-term categories – who will take care of those things? Do you have a DevOps team to take care of the most pressing matters? Who will be responsible for the app’s evolution?

These questions lead to financial and functional decisions that are best discussed as soon as possible. Even if your current team doesn’t provide post-release support, it would be good for them to know, how to prepare everything for their successors.

In conclusion…

As long as you talk to people, ask questions, listen and come into a project with an open mind, many problems can be easily solved or avoided altogether. If you have a solid, well-chosen development team, you should also be able to count on its members to support you in this new, unknown to you endeavor with their knowledge, experience, and wisdom.