week4.html

<title> CS349 Spring 2019: Robert McInvale</title>
<h1 style = "font-size:300%;"><b> Robert McInvale CS 349 Blog</h1></b>
<h2 style = "font-size:200%;">Week 4 - Good Business Practices (PP & CI) </h1></b>

<p>
	In order to avoid the creation of a majority of the bugs found in code today, the software industry would need to stop hiring unqualified individuals. 
	If absolutely forced to hire someone without an education in proper programming practice, companies should, at very minimum, provide a thorough training course 
	lasting 3-6 months. Additionally, CS education programs across the country should make mandatory courses like Dr. Downing’s Software Engineering and Object Oriented Programming classes, 
	which instill students with a fundamental set of practical skills necessary to avoid churning out shoddy work.
	<br><br>
	However, seeing as this solution is both imperfect (even the most experienced programmer still makes mistakes) and impossible (the market demand for coders far exceeds 
	supply, even without a training revolution), it might be prudent to think about changes that we, as individual software engineers, may effect in our own companies and 
	circumstances. In my view, the two most of obvious of these are Pair Programming and Continuous Integration.
	<br><br>
	Pair Programming is quite as simple as it sounds: developers are divided into pairs when working on a project, and while one person works on the keyboard, the other 
	watches and provides suggestions and feedback. The pair can take turns alternating roles, but it is important that only one person is ever actually operating a computer at a time. 
	While many developers may, at first thought, dislike the idea of having someone constantly looking over their shoulder, the constant feedback and bug-checking of an invested teammate is 
	likely to end up reducing the number of bugs in a final product. This all comes, of course, at the drawback of investing twice as many programmers per feature, but many companies have 
	still found the practice worthwhile.
	<br><br>
	By contrast, an investment in a Continuous Integration (or CI) system comes at very little cost to manpower, but may be difficult to initially set up, train employees on, and enforce use 
	of. CI aids the programming process by continually incorporating changes made by developers to their own, isolated features into the larger system as a whole. This gives developers constant 
	feedback on the quality of their code and the changes they are wreaking on the final project, all well before a formal “testing phase” would traditionally begin. This feedback is truly invaluable 
	and, once properly set up, automatic - but it does require a considerable initial investment to get running.
	<br><br>
	Both of these methods are capable of reducing the number of bugs present in code, and both are currently in wide (but not ubiquitous) use across the software industry. However, they do 
	come with considerable costs, and not everyone agrees that they actually benefit the industry. As with anything, the costs must be weighed against the potential gains in deciding whether to 
	employ these methods in a specific circumstance.

</p>

<p>

</p>