PandaByte

A strange place where pandas and technology meet.

Sprouting Engineers Need a Soil Bed — May 24, 2018

Sprouting Engineers Need a Soil Bed

Note: Article has been updated since submission on September 28, 2014. Interview based on class assignment. 

Click, click, click, and clack.  The sounds are more than common in a room filled with computers.  Worn pads are evident on many keyboards.  Cycling intervals of intense strokes intermixed with silent pauses are familiar.  Some people converse about a current project, while others are dedicated to finishing the job.  This is a workspace of software engineers.

Erik Allar is currently employed at Sprout Social, a social media software company.  He defines his workspace as casual.  It is not a monotone space, such as a cubicle.  There are couches, ping pong tables, bean bag chairs and more.  His favorite thing about his space are the snacks conveniently located in the kitchen.  The entirety of this space is where budding minds create applications.

These applications entail managing social media for big name companies.  Companies of notable mention are GrubHub, Urban Outfitters, Spotify and more.   Sprout Social’s products analyze and publish tools to monitor social media influences.  Their products are available in web browsers and mobile applications.  Since social media is changing how companies interact with consumers, it becomes necessary to find better ways to manage those interactions.  Sprout Social is an answer.   It creates a better experience for customers and allows businesses to flourish.  Erik found that this company was doing what he wished to do.

Erik Allar graduated from Michigan State University in 2010.  He earned a Bachelor’s of Arts in finance.  He was a bright graduate itching to grab on to life.  Yet, his degree did not lead him to where he thought it would.  The dreams of success and prosperity were not turning out how he wanted it to be.  At this point in his life, he did not have an exact goal or path, but he found that finance was restricting.  The creativity associated with programming lured Eric into his field.  Finance was not as enjoyable as he thought.  Fortunately, he mostly taught himself how to program.  Erik realized “how much potential there was for me to create”.

He further studied programming from Dev Bootcamp, an intensive program for learning computer programming.  There he gained the skills necessary to begin his career in programming.  Starting with back-end applications, Erik did not believe that he would eventually end up where he is now.  In November 2013, Erik began working for Sprout Social.  A friend had enlightened Erik about his own experiences, and Erik was hooked.  He was interested in the types of problems that Sprout Social was addressing and decided to get an interview.  Yet, the most important part that influenced his decision was the people.  Erik found that the people were “very kind”, “down to earth”, and “enthusiastic about what they were doing”.   As described by Erik, “There was an infectious energy at Sprout and I wanted to be a part of it.”

As part of the Sprout Social team, he begins his day with a simple hello.  Each day typically starts with some coffee and oatmeal at 8 or so.  Next, Erik attends any stand-ups, meetings for current projects.  Then he gets to coding.  Currently, at Sprout Social, he is a software engineer with a concentration in iOS applications.  Erik maintains and builds iPhone and iPad Apps.  His most used programming languages are Objective-C, Python, Java, and a few more.  He types away until the next part of his day.  Lunch is usually with lots of chicken and other colleagues chatting about current projects.  In the afternoon, there is an occasional meeting, but usually, Erik is programming again.  When the day comes to an end, Erik leaves around 4:30, takes the L, to avoid the blunders of Chicago traffic.

A typical work week is the standard Monday to Friday set, but it is possible for Eric to work from home.  Yet for Eric, going to Sprout for the people is one of the best things about the job.  Even there, he can be an independent and or a collaborative engineer.  There are times when working alone is best to finish the intended project.  His team is incredible and with high energy, so working is a good time.

Yet, there are times when he is being challenged.  Ironically, Erik considers his greatest challenge to be not knowing any mobile development before becoming an iOS engineer. Any problem does not go without kinks.  Obstacles do not stop Eric.  Although they may be difficult at times, working within a team while solving problems is fun.  According to Erik, “We work on some very unique problems at Sprout, so we need to come up with some very interesting solutions”.   If there is ever a time when Erik feels the need for help, he talks to other iOS engineers and together they solve the problem.  Collaboration is a key characteristic of the engineering teams at Sprout Social.

According to Erik, it is necessary to handle frustration and have patience. Being able to learn quickly and efficiently is an important skill for someone in computer science.  The discipline is about solving hard problems, which allows intuitive minds like Eric to grow. Erik values being able to work out these problems, despite being frustrated.  He has learned that “Eventually you’ll figure it out, but it takes patience.”

It has become important to be able to manage his time and improve his focus, but these qualities apply to life, not just work.  He does not feel that Sprout Social has “changed” him, but rather he feels energized as a person.  “Most of the stuff I did before Sprout is still there, it’s just been amplified because of the energy, support, and balance I find in working at Sprout”.  He would say that “developing a sense of trust” and “following instincts” are what led him to Sprout Social.  If he had chosen to continue finance, he may be a different person.  The intense and hard work at Sprout Social is unmatched.

Ecstatic is a one-word description of Erik.  “I love my job, work at a phenomenal company, and most of all have met tremendous people, the best.”  It is because of the space at Sprout Social.  It is where hard problems are solved despite having such a pleasant atmosphere.  The soft couches and the high number of computers create a haven for software engineers to grow.   Although there are times when assignments are uncomfortable, Erik will do it.  For him, “If you are comfortable, you are doing something wrong”.  The way to learn and discover new things is being outside his comfort zone, despite the luxury of Sprout Social.  This is the way of a software engineer.

Inspection is the basis of quality control… —

Inspection is the basis of quality control…

Note: Article has been updated since original submission March 26, 2015 for a college assignment. 

Summary:

The following report outlines the capabilities of software inspections.  Software inspections can be used as a supplementary error-finding process to the software development scheme.  They may even reduce the cost and time used by other phases in the software development process.   Even more so, software inspections can improve the overall software quality of a system that may not be covered by testing.  Inspections are possible and are arguably a more reliant tool for finding errors in software.

 

Key Things Learned 

  • An inspection is only as good as the person inspecting. It is hard to do a good inspection.
  • Software inspections are not a replacement for any phases of the software development process, such as testing, but a supplement that makes the process more efficient and effective.
  • When regularly done, software inspections is a formal process. They may be conducted regularly with specified reports that are to be documented.
  • Inspections are not used as often as they could be. Many people skip over software inspections in favor of testing, although inspections can reduce the number of defects just as much as testing, if not more.

Software, Tools, Apps, Used and Evaluated

There are many self-automated tools for conducting software inspections.  Some are even included within an integrated development environment (IDE).   Some examples are CodeSurfer, C++ Test, and TestTrack Pro (“Tools”).   But the more practical software inspections, and what this report is focused on is self-inspections. The people working on the software inspect it themselves.  This can be seen as a more formal process, rather than an informal process. As earlier stated, software inspections are meant to be a formal process (Stellman and Greene).  High use of software inspections will reduce cost and time inefficiencies when conducting other phases of the software process such as testing and implementation.  Figure 1 is an example course of how a software inspection process may be conducted in a formal setting.

Figure 1.  Chart of Inspection Meeting Script

softwareinspect.png

Source:  Stellman, Andrew, and Jennifer Greene. Chart of Inspection Meeting Script. Digital Image. Building Better Software. O’reilly, 10 Feb. 2015. Web. 26 Mar. 2015.

 

Findings:

1.1 Software Inspections
A software inspection is a process of evaluating the validity of a software system.  This includes, but is not limited to source code, design models, requirements (Sommerville 666).  The process is done to reduce errors that can be caught before testing and implementation of the system.  Inspections are a way of finding defects at a relatively low risk (low costs, less time, etc).  They can be done by self-inspection or an automated tool.

1.2 Advantages
When conducting a software inspection, such as on source code, it helps mitigate the possible errors hidden by other errors.  Errors because of interactions among the system cannot be easily found by software inspections, but errors that are an error in itself can be found and fixed before any testing (Sommerville 208).  If an error is found by software inspections, a developer will know where it is, and most likely know how to fix it.  This will minimize the number of defects to test the number of errors will be reduced (Radice).  The same cannot be said if errors are found by testing, which the error can be hidden by another error.  Another advantage of software inspections is that inspections can reduce cost.  It does not necessarily require more testing or tools, just knowledgeable persons who can evaluate code.  Also, software inspection increase the likelihood of finding an error earlier rather than later, which tends to be cheaper (Radice).  All possible errors do not show up at the same time during the software cycle.  Therefore there are always reoccurring costs; inspections helps reduce the need to repeat a process with cost, such as reintegration.  Figure 2 outlines the entire software activity cycle, and the number of defects throughout it.  Note that with inspections, the amount of defects noticed is higher than without having inspections throughout the complete cycle.

Figure 2. Example of Defect Removal With Inspections

softwareinspect2.gif

Source:  Radice, Ron. Example of Defect Removal With Inspections. Digital image. Improve Software Quality with Software Inspections. Methods & Tools, 1 Jan. 2002. Web. 26 Mar. 2015.

Inspections also consider things beyond the source code itself.  It could be the system architecture or the style of programming that is inefficient or inadequate to fit the needs of standards, clients, etc.  The software quality of a system can be improved when using inspections because they help find defects that cannot be found by testing or automated tools.  Inspections can improve the maintainability, reusability, efficiency, without having to conduct a test (Sommerville 209).  Also if inspecting something such as the checking the architecture for defects, it is not possible to “test” this as easily as source code.  Furthermore, software inspections help promote understanding of the software, since it forces developers and other workers on the project to comprehend what is going on in the system (Radice).  This may help ameliorate the abilities of junior developers/workers.

1.3 Disadvantages
Software inspections are done based upon the idea that one knows how to evaluate software.  That is, a person must be knowledgeable about how the source code or system should look like before it is ever implemented.  If one is not knowledgeable about how the source code is to work, then a good inspection will be hard to conduct (Radice).  It is necessary to have a high level of skill in terms of knowledge and style of programming, perhaps in algorithms or coding language syntax, to ensure a workable system based on using the right formulas.  Since software inspections are not as practiced as they could be, there is a limited pool in which people know how to conduct a software inspection (Sommerville 666-667).  Even then, many developers on projects are not necessarily masters of what they are programming and may depend on testing to find errors rather than doing self-inspections of the system.  Another issue associated with software inspections is that its lack of use may be due to social concerns.  Since software inspections are not highly used, managers may find the process time and cost consuming, when it actually does the opposite (Radice). Also, since there is lack of documentation that explains how well software inspections can be used, many do not find it absolutely necessary to do.

 

Problems / Questions / Further Work

The report has outlined the basic capabilities of software inspections.  In order to get more in-depth about the process of software inspections itself, they must first be widely implemented.  If anything is to be done to implement software inspections, it must be that developers have to be more willing and adamant about conducting them.  Software inspections can have a greater outcome when done, rather than not doing them at all.  The benefits outweigh the costs, and software inspections should be a seen as a reputable process in the software development plan.  Again, a software inspection is only as good as people allow them to be.  With that said, there are also automated software inspection tools, which were not covered in detail by this report that may make the transition of not using software inspection as a practice to a highly used one.

 

Change Control and Updates

  1. Version 1.0 (original) <<Julie Leong>>, <<3/26/2015>>
  2. Version 2.0 (updated) <<Julie Leong>>, <<5/24/2018>>

 

References  

Radice, Ron. “Improve Software Quality with Software Inspections.” Improve Software Quality with Software Inspections. Methods & Tools, 1 Jan. 2002. Web. 26 Mar. 2015. <http://www.methodsandtools.com/archive/archive.php?id=29&gt;.https://sw.csiac.org/databases/url/key/165/169

Sommerville, Ian. “Software Quality.” Software Engineering. 9th ed. Boston: Pearson, 2011. 208-209, 663-668. Print.

Stellman, Andrew, and Jennifer Greene. “Applied Software Project Management – Review Practices.”Building Better Software. O’reilly, 10 Feb. 2015. Web. 26 Mar. 2015. <http://www.stellman-greene.com/applied-software-project-management/applied-software-project-management-review-practices/&gt;.

“Tools.” Inspections. Cyber Security & Information Systems Information Analysis Center, 1 Jan. 2015. Web. 26 Mar. 2015. <https://sw.csiac.org/databases/url/key/165/169&gt;.