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 still be referring to a software project as”coding”or”writing’ ‘. With better luck one might add’designing’and’testing ‘. Quite inaccurate.
It’s possible to consider several metaphorical comparisons to explain software development, such as for instance writing a book or creating a house. A number of them really are a good light at night, some are rather misleading. And while lots of people may argue whether creating software is an art, 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.
One of the common but instead vague things is comparing creating software with writing. Writing code, writing a book, and so on hr system. You can start writing a book with no plan and choose the flow; with custom software development you cannot, unless developers execute a rather small software application by themselves – 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 released – it’s a natural thing. It’s extremely difficult to obtain every need of one’s end user, catch up with business and technological changes once and for a lifetime. Books aren’t that determined by 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 language”create”or”build”software as opposed to”write’ ‘.
”Growing”software on a great basis and a great group of documentation is possible to a particular extent. Just as in writing, it’s not the very best description one can suggest. It partially gets the incremental, agile nature of creating and maintaining relevant software. But while”growing’ ‘, the item is rarely tasty until it’s ripe, and the dog owner has to attend awhile.
The difference is, in software development you can find different stages to be”ripe’ ‘. Startups usually demand rolling the very least viable software product on the market, getting feedback and making corrections and improvements. Each version is more”ripe”than its predecessor, and it has to be”watered”by support and maintenance, kept fresh amidst all the company and technological changes.
This 1 is known as by many specialists the closest way to explain software development, and we are able to agree with that. Construction works show the huge significance of careful planning, preparing, guiding the job, and performing it. The limits of software depend how its architecture is constructed. The total amount of works doesn’t grow gradually, since every building is different, and requires different approach. There could be a hospital, a company building, a college or perhaps a barn, and same physical size doesn’t mean equal level of labour. Something is performed with concrete, something can be achieved with wood and nails, and the latter doesn’t work well with complex and valuable software for mobile startups and other businesses.
– Everything depends upon the kind of a building you need. You’ll need to find out the problem the application will solve, and conduct the required preparations, do market research, gather info, etc. The more technical your software is, the more resources should be allocated to planning. Bad planning – and the entire app fails, falls like a residence of cards by the initial gust of a wind.
– Then you definitely and your chief architect (project manager) can proceed to create that perfectly combines functional requirements and interface, causing proper user experience. Sure you want people who works or reside in the building to be fully satisfied with it. Same thing with software. Yet another a valuable thing, once the style is approved, it’s way easier to offer more precise estimations for the rest of the construction (development) works.
– When furnishing a residence, 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 certain case. And if the team means business, they will easily find tools and technologies that’ll get your tasks done as fast as possible. Custom items of furniture take more hours and efforts, but in most cases you can find already existing pre-built ways to save your own time and money without compromising security and efficiency of one’s software.
– There will always be changes in functional requirements. Again, changes can painlessly happen within the planned architecture. Here we once more emphasize the significance of preparations – although this topic is worth a separate article. And we cannot go anywhere without mentioning quality assurance, which constantly checks different facets of how the application works. What’s more – even a change involves testing, so that’s not the spot to cut the expense (in fact, QA typically takes about 30% of the entire development time).
– Optimization of software (inner walls of a building) is limited to the approved architecture, and here main expenses are exactly about labour, not materials. But that which you receive ultimately is way better software and satisfied users. Meanwhile users speak their minds about what they’d like the apartments to look – and one should not neglect these opinions.
– One more thing worth noting – a great architect (or a great creative expert in software development) is obviously willing to consult you on things that ought to be solved immediately, and what can be left for later without breaking your plans or the caliber of your software. You are most likely to not know the subtleties of the technical side – so leave making suggestions and explanations to your team. If you don’t are an experienced IT person and you needn’t reading this article to obtain these insights.
Aug 09, 2020