Many business people don’t fully understand the complexity of a software development process. It’s natural, since specialized books about development are read by developers and other IT people, and numerous others might be referring to a software project as”coding”or”writing’ ‘. With better luck one might add’designing’and’testing ‘. Quite inaccurate.
One can consider several metaphorical comparisons to describe software development, such as for example writing a book or building a house. Many of them certainly are a good light at night, some are rather misleading. And while many individuals may argue whether creating software is an art form, a research, or perhaps a precisely elaborated process, we’d leave that choice to someone else. It can not be described sparsely. But we’ll try to offer some descriptions and comparisons in a concise and clear way.
Among the common but instead vague things is comparing creating software with writing. Writing code, writing a book, and so on. You can start writing a book with out a plan and opt for the flow; with custom software development you can’t, unless developers do a rather small software application independently – and for themselves. Moreover, an outsourced software project never starts with writing code.
Books and software may both have strict deadlines. But once a book is published, what’s written is written; rewriting is not an option. But software keeps being under constant improvement with new versions hitting theaters – it’s a natural thing. It’s nearly impossible to have every need of your end user, meet up with business and technological changes once and for a lifetime hr and payroll software. Books aren’t that dependent on changes; software is. But that’s good: your software, unlike a book, can’t become yet another mediocre thing on the market, can’t become irrelevant and outdated. The processes are absolutely different: we prefer using the words”create”or”build”software rather than”write’ ‘.
”Growing”software on an excellent basis and an excellent pair of documentation is achievable to a certain extent. As with writing, it’s not the best description it’s possible to suggest. It partially gets the incremental, agile nature of making and maintaining relevant software. But while”growing’ ‘, the merchandise is rarely tasty until it’s ripe, and the dog owner has to attend awhile.
The difference is, in software development there are different stages of being”ripe’ ‘. Startups usually demand rolling a minimum viable software product on the market, getting feedback and making corrections and improvements. Each version is more”ripe”than its predecessor, and it must be”watered”by support and maintenance, kept fresh amidst all the business enterprise and technological changes.
That one is known as by many specialists the closest way to describe software development, and we can trust that. Construction works show the huge importance of careful planning, preparing, guiding the task, and performing it. The limits of software depend on how its architecture is constructed. The total amount of works doesn’t grow gradually, since every building is significantly diffent, and requires different approach. There can be a hospital, an office building, a college or perhaps a barn, and same physical size doesn’t mean equal quantity of labour. Something is completed with concrete, something can be carried out with wood and nails, and the latter doesn’t work very well with complex and valuable software for mobile startups and other businesses.
– Everything depends upon the kind of a building you need. You will need to determine the situation the software will solve, and conduct the necessary preparations, do market research, gather info, etc. The more technical your software is, the more resources must certanly be allocated to planning. Bad planning – and the entire app fails, falls like a house of cards by the very first gust of a wind.
– Then you and your chief architect (project manager) can proceed to design that perfectly combines functional requirements and interface, leading to proper user experience. Sure you want those who will continue to work or are now living in the building to be fully satisfied with it. Ditto with software. One more positive thing, once the style is approved, it’s way easier to offer more precise estimations for the remaining of the construction (development) works.
– When furnishing a house, you needn’t building things you can get: household appliances and furniture. It’s much cheaper and way faster. Same with software: if your software development team is experienced, it will use all of the available resources to stay away from writing needless basic things: there are lots of software toolkits, frameworks, classes, and libraries for that, each for a specific case. And if the team means business, they’ll easily find tools and technologies that will get your tasks done as fast as possible. Custom items of furniture take more time and efforts, but typically there are already existing pre-built ways to truly save your own time and money without compromising security and efficiency of your software.
– There can be changes in functional requirements. Again, changes can painlessly happen within the planned architecture. Here we once again emphasize the importance of preparations – although this topic is worthy of another article. And we cannot go anywhere without mentioning quality assurance, which constantly checks different areas of how the software works. What’s more – even a small change involves testing, so that’s not the place to cut the expenses (in fact, QA often takes about 30% of the entire development time).
– Optimization of software (inner walls of a building) is restricted to the approved architecture, and here main expenses are exactly about labour, not materials. But everything you receive in the long run is way better software and satisfied users. Meanwhile users speak their minds on what they would like the apartments to appear – and one should never neglect these opinions.
– Something else worth noting – an excellent architect (or an excellent creative expert in software development) is obviously willing to consult you on things that should be solved immediately, and what can be left for later without breaking your plans or the quality of your software. You are usually never to know the subtleties of the technical side – so leave making suggestions and explanations to your team. If you are a skilled IT person and you needn’t reading this article to have these insights.