Myths in IT Industry

Myths in Software Development

Software engineering for a very long time so let us understand what exactly are software myths so ask for the father of the software engineering the Pressman describes several beliefs or myths that software managers customers all practitioners believe falsely and he described myths as the misleading attitudes that have caused serious problems so basically if we understand this in a simple language software myths are nothing but something which affects the overall working of the software development process due to some beliefs which we have so let us classify them into different types of myths so we have managers myth we have developers myth and we have the customer you know the primary stakeholder the customers mid so let us break them down.

Let us understand what is this myth and then I'll also share what are the realities which software developer manager or the customer needs to understand so let us go through that so first, we are discussing is 

• Management's myth or the Managers Myth 

Myth and its Reality

Which is the primary one is that we already have the book that is full of standards and procedures for building the software won't that provide my people with everything they need to know so this is somehow a lot of people as with the managerial level or the management level people think that we have the standards of the book we have all the experience in the world we have the people, now it's the isn't that enough to begin coding and start the software so the reality is that book of standards are always existing but do we use our software or practitioners aware of its existence does it reflect in the modern software engineering practices are the answer to everything. It completes it streamlined to improve the delivery time while still maintaining the focus on the quality and also most of the time the answer to these questions is no right so this is a big myth where we think that we are the books and we can develop the software but they have much more criteria involved.

Myth and its Reality

My people have the state-of-the-art software development tools, after all, we buy them the newest computers so don't that mean that they can start doing the work right away the reality is different guys it takes much more than the latest model mainframes workstations or computers computer-aided software tools are more important than you know high-quality hardware only good quality and productivity can then achieve and yet the majority of the software developers still do not use case tools very effectively. 

Myth and its Reality

The next myth which is surrounding the managers or management Smith is not if we get behind in the schedule add up more people guys let's add more programmers and catch up on time which is also known as Mongolian hold a concept try to Google it out it will get what I'm talking about so the reality is software development is you know it's an artistic process, not a mechanical one so it's not like the manufacturing we add new people and the software can be done faster in fact tweening new people getting them on board and also explaining what the scenario in the currents in our software development is will take up more time than the normal intern delaying the project even more so this is the manager Smith which we have discussed. 

Myth and its Reality

If  I decide to outsource the software project to a third party I can just relax and let that firm build it you know so a lot of times companies think as soon as I outsource I'm done reality is completely different if an organization does not understand how to manage and control software projects internally it will fall guys, it won't work with outsourcing also so even if you are outsourcing you still have to understand that your role your communication is important.

• Practitioners Myth or the Developers Myth

Myth and its Reality

The biggest myth which they are you know feel in terms of the code is once we like the program get it to work our job is done guys that are never the case if you're a developer or a practice now that never is the case the reality is that sooner you begin writing the code longer it will take to get it done so it's like you know the saying which is there that if you are asked to that 'try to spend your 60% of time and sharpening the knife so that next 40% you utilize from well so same way the data indicate between 60 to 80% of all effort expended on the software is on you know how we can maintain the quality so that is how we need to understand that it's not only about writing the programs and coding it's much more than

that.

Myth and its Reality

The next myth is until I get the program running I can't access the quality that's the big myth in terms of you know developers because one of the most effective software Quality Assurance mechanisms says that quality is not one strap parameter it happens at each step so it starts from the inception of the project of IT you know formal technical review and up to reach the stage where you are coding debugging your code your third programming you're working with the team a lot of ways so there are you know quality filters which we can achieve why are different software engineering concepts.

Myth and its Reality

The next myth is that only yuri-chan you know I can deliver a deliverable work product is a successful project or a working program otherwise it's not deliverable the reality is a working program is only a very small part of the software configuration that includes many elephants like documentation is also a pioneer or a foundation of successful engineering and it also plays an important part in guiding for software support.

Myth and its Reality

The next myth which practitioners follow is that software engineering will take us to create a lot of documentation which is unnecessary and it will reduce the effectiveness of the time reality is software engineering does not only document its practical approach towards creating qualitative complete and reusable software development so it creates quality better quality leads to reduce work and as a result, we have faster delivery times. 

• Customers Myth

Myth and its Reality

So the customers as in the client they have a lot of beliefs and let us discuss that so the first myth is a general statement of the objective is sufficient to begin writing programs we can fill in the details  you  can start creating software and then they'll give you the requirements that are not the case guys reality is upfront if we do not have clear the requirements we cannot move further as in the formal you know documentation and description will be missing as a result we would be you know not sure what performance criteria what behaviors what interfaces or what design constraints we have to apply in the project and as a result, we can miss time our calculations project requirements continually change but change can be easily accommodated because software is flexible and nowadays because it is agile development lot of this also becomes you know reality but not all project requirements can be changed and we not be accommodating all the changes so the reality is software requirements do change but the impact of change varies with the time at which it is introduced.

Thank you guys for being with me till the end of the blog. See you in the next blog stay blessed. 

JazakALLAH!