Many business people don’t fully understand the complexity of a computer software development process. It’s natural, since specialized books about development are read by developers and other IT people, and many more might still be referring to a computer software project as”coding”or”writing’ ‘. With better luck one might add’designing’and’testing ‘. Quite inaccurate.
One can think of several metaphorical comparisons to describe software development, such as for instance writing a guide or creating a house. Many of them certainly are a good light in the dark, some are rather misleading. And while many people may argue whether creating software is an art form, a science, or a precisely elaborated process, we’d leave that choice to someone else. It can not be described sparsely. But we’ll try to give some descriptions and comparisons in a compact and clear way.
Do We”Write”Software?
Among the common but alternatively vague things is comparing creating software with writing. Writing code, writing a guide, and so on. You can begin writing a guide with out a plan and go with the flow; with custom software development you can’t, unless developers perform 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 guide 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 extremely difficult to have every need of your end user, meet up with business and technological changes once and for a lifetime hr software for uae. Books aren’t that determined by changes; software is. But that’s good: your software, unlike a guide, can’t become yet another mediocre thing available on the market, can’t become irrelevant and outdated. The processes are absolutely different: we prefer using the words”create”or”build”software as opposed to”write’ ‘.
Do We”Grow”Software?
”Growing”software on a good basis and a good pair 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 earning and maintaining relevant software. But while”growing’ ‘, the product is rarely tasty until it’s ripe, and the owner has to hold back awhile.
The difference is, in software development you will find different stages to be”ripe’ ‘. Startups usually demand rolling a minimum viable software product available on the market, getting feedback and making corrections and improvements. Each version is more”ripe”than its predecessor, and it needs to be”watered”by support and maintenance, kept fresh amidst all the business and technological changes.
Do We”Build”Software?
This one is recognized as by many specialists the closest way to describe software development, and we are able to agree with that. Construction works show the huge significance of careful planning, preparing, guiding the work, and performing it. The limits of software depend how its architecture is constructed. The quantity of works doesn’t grow gradually, since every building differs, and requires different approach. There can be quite a hospital, a company building, a school or a barn, and same physical size doesn’t mean equal number of labour. Something is done with concrete, something can be done with wood and nails, and the latter doesn’t work well with complex and valuable software for mobile startups and other businesses.
– Everything is dependent upon the sort 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 complicated your software is, the more resources should be allocated to planning. Bad planning – and the complete app fails, falls like a home of cards by the initial gust of a wind.
– You then and your chief architect (project manager) can proceed to style that perfectly combines functional requirements and interface, resulting in proper user experience. Sure you would like those that will continue to work or are now living in the building to be fully pleased with it. Same task with software. An additional positive thing, once the design is approved, it’s way easier to give more precise estimations for the remaining of the construction (development) works.
– When furnishing a home, you needn’t building things you can purchase: household appliances and furniture. It’s much cheaper and way faster. Same with software: if your software development team is experienced, it use all of the available resources to avoid writing needless basic things: there are plenty of software toolkits, frameworks, classes, and libraries for that, each for a particular case. And if the team means business, they will easily find tools and technologies that will get your tasks done as fast as possible. Custom items of furniture take additional time and efforts, but generally you will find already existing pre-built ways to save your 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 more emphasize the significance of preparations – although this topic is worthy of a different 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 complete development time).
– Optimization of software (inner walls of a building) is limited by the approved architecture, and here main expenses are exactly about labour, not materials. But everything you receive in the long run is better software and satisfied users. Meanwhile users speak their minds about what they would such as the apartments to appear – and one should not neglect these opinions.
– Something else worth noting – a good architect (or a good creative expert in software development) is definitely ready to consult you on things that ought to be solved immediately, and so what can be left for later without breaking your plans or the caliber of your software. You are likely not to know the subtleties of the technical side – so leave making suggestions and explanations to your team. Until you are an experienced IT person and you needn’t reading this short article to have these insights.
Read More
Recent Comments