21st Conference on Software Engineering Education and Training

Undergraduate Software Engineering Students in Startup Businesses

Steve Chenoweth
Rose-Hulman Institute of Technology
chenowet@rose-hulman.edu

Abstract
Fresh ideas from startups are a driver of the electronic business world. Software
engineering students who will be a part of this E-world therefore should benefit from a
working knowledge of new businesses. Their school can organize opportunities to help
ensure that familiarity. This paper describes results after four years of organizing such
endeavors. We believe that those results for students are mixed, and that this can be
explained by the reluctance of new entrepreneurs to adopt consistent software development
processes. Schools seeking to make their software engineering programs match industry
profiles will find these results of interest.

1. Introduction
Easy entry and the promise of world-wide markets stimulate the creation of new electronic
businesses. The fresh ideas of these startups then spawn new directions for E-business
generally. As an educational initiative, it makes sense for software engineering students to
acquire a working knowledge of new businesses, and their school can help create
opportunities for that familiarity. This paper discusses results for students who reported their
experiences, after four years of a program to provide this kind of business experience to
undergraduate students. Our focus is specifically on the students’ reactions to learning about
SE processes in classes, following their work in startups.
We describe research and prevalent pedagogical best practices related to student work in
software engineering startups. The issue is what the students gain from experiential learning
in these organizations. A basic model is proposed, for desirable outcomes from such student
experiences, which can be compared with the reported outcomes for students we studied.
These studies are about students who worked in startups at an incubator. Students working
for non-startup companies in the same incubator are used as a control. The summarized
results of the student startup experiences, and students’ later reactions to process knowledge
presented in SE courses, contrast with the model of desirable outcomes.
Lessons from these studies are intended to help guide schools seeking to make their SE
programs match industry profiles. To prepare students for the electronic business world, an
optimal set of learning activities would be expected, in theory, to include student experience
with startups. We thus conclude with practical implications and recommendations for
educators whose students are involved in coop or other work at startup software companies.
Extensions to our investigation are suggested.

2. Research and prevalent best practices

Quality focus and process focus are the foundations of software engineering. These foci
support essential goals such as finding more defects at an earlier stage [1]. The quality is
driven by the process, and so process is valued in established, successful software
development organizations [2]. Their key software engineering processes provide for

978-0-7695-3144-1/08 $25.00 © 2008 IEEE 118

DOI 10.1109/CSEET.2008.27
requirements management, project management, software design, quality assurance, and
configuration management, among others.
Despite the strong relationship between process and success, there remains some resistance
to process in the software industry itself. An entrepreneurial style may be inherent to software
culture [3]. Industry is motivated by profit, and processes tend to be ignored by industrial
organizations which are in a hurry [4]. Startups in particular are creative, flexible and able to
move quickly into opportunities because they are unencumbered by stifling layers of
management [5]. They have to move fast: Due to their lack of a customer base, knowledge
about requirements does not come into a startup in an orderly manner. As a result of this
chaotic flow of requirements, any of the deliberate processes of software engineering can
seem off-track in regard to keeping the new enterprise moving with that flow [6]. The author
saw this lack of process in his industrial experience, doing technical diligence studies for a
computer vendor and a telecom vendor, as each of these acquired smaller software
companies. Commonly, the winners in a first-to-market race had little documentation. Their
requirements, designs and processes were largely in the heads of key people. However, even
in small startup software businesses, experience, skills and methods are as important as new
ideas in generating success [11, 12].
There is evidence that quality education in computer science (CS) and software
engineering (SE), which familiarizes students with these processes, leads to quality in the
software industry [7], and that poorly educated software developers hinder quality and
timeliness [8, 9]. This is notwithstanding the fact that software engineers traditionally are not
the process experts in their own business [10]. Lack of business experience by software
developers in general is a problem. Lack of process skills in particular negatively contrasts
US computer science students from those in India and Japan [13]. Yet we see impatience
with process in undergraduate students majoring in computer science and software
engineering. As Lethbridge, et al. describe it, “Anyone who has tried to teach topics such as
ethics, quality, process, configuration management, maintenance and requirements will
recognize the glassy-eyed appearance in the eyes of some (or most) students. These are
critical topics for industrial practice, yet it is a particular challenge to motivate students to feel
passionate in these areas, and hence learn what they need to know” [9].
Efforts to overcome student resistance have centered on providing students with realistic
software engineering activity. The need for such experience is now a generally agreed upon
pedagogical principle [14, 15, 16, 17, 18]. That need includes, in particular, preparation of
students for the world of e-commerce [19, 20]. Relevant experiential learning helps to get
across, to novice students, why software engineering processes are valued in business [21].
Thus, there has been an ongoing effort to bring associated work experiences closer to the
classroom [18]. In addition to lessons simulating experience within the classroom,
experiential learning typically includes work in the actual software industry – via internships,
part-time, coop and summer jobs.
Because of industry’s own partial reluctance to adopt and adhere to processes, it is not
clear that all such “real world” experience is of equal value to students. What commercial
experience benefits the students, reinforcing their learning in school, and what, perhaps, does
not? Mulder, et al. expressed concern that while gaining sufficient industry contact with
students is an ongoing problem, this collaboration specifically needs to demonstrate use of
disciplined processes [22]. Curran reports that, for students, industry experience and software
engineering curriculum can conflict: “Computer science students are sometimes skeptical
about the relevance of software engineering course topics,” and this can be particularly

119
students who have had some experience in industry. A major cause of their skepticism is that
the processes covered in school are not the same as those they see used in industry [23].
The challenge of teaching process is one aspect of a broader concern to academics: “How
to improve the synergy and communication between industry and academia” [9]. We propose
the following basic model for students learning software engineering: The students’
industrial experiences and their educational experiences should reinforce each other. That
is, neither domain of early experience should cause the student to reject valuable lessons from
the other domain. Process lessons in these places may vary, yet together they should provide
the basis for a successful career in software engineering.

3. Methodology
As a report on an attempt to establish an institutional frame, between industry and
academia, this paper follows after Rohde, et al. [15], whose study dealt with integrating
industry experience into a single course. Our methods are similar to theirs, used here as well
to analyze connections and learnings between software development companies and students.
To evaluate cultural variables, Schein recommends using complex interviews, observation
and joint inquiry [24]. We used these methods to extract knowledge about businesses, about
student interactions with those businesses, and about student reactions to classes following
their business exposure. We wished to discover especially the underlying values of the
businesses which had impacts on the students.
Over a four year period, undergraduate SE students worked for four software startups and
for four more established companies in a business incubator associated with an undergraduate
engineering school. Two of the products for each group of companies were E-business-
related, and the other two were desktop applications. Our inquiry was coordinated with
managers of the incubator. In studying the effects of startup experience on students, the
experience of students at the four established companies was used as a control. We did not
compare either group with students having work experience outside the incubator, or with
students having no work experience. On all projects, the management of the company
exerted a strong influence over how the software development was done for them. Related to
this, the entrepreneurs of the startups had had either no prior experience with software
development, or experience only with very small projects (e.g., less than five people).
The students, their project managers, the entrepreneurs and others representing the
businesses were interviewed during or after work projects. Students and faculty also were
surveyed, during or after SE classes the students took. From these sources, information was
gathered regarding the lessons learned by the students in each venue. In two cases (both
established ventures) the author also consulted for the companies, observed and interviewed
students in their coop assignments.
Students worked at the incubator for one of these companies, full-time during summers,
and part-time during the school year, typically around 10 hours per week. They began this
coop work sometimes during their freshman year, but more often during their sophomore
year. Most students worked on the same project at the incubator for at least two terms (half a
year). They usually had completed the three-term curriculum in fundamentals of software
development, including Java programming and data structures, and they also may have
completed courses such as introduction to database systems, operating systems, computer
architecture, and programming languages. As underclassmen, however, they had not yet
taken the junior-year curriculum which includes courses in process-related aspects of
software engineering.

120
 Thus, the common sequence of events for students included in this study was that they first
worked at the incubator, and then took courses whose focus was software engineering
process. In each of the junior SE courses, a mixture of process types was taught – traditional,
agile and extreme. Examples of these courses, and ones which all computer science or SE
majors take, are the course in software requirements and specification, and the course in
software project management. Companies eventually hiring the graduating seniors with these
majors represented everything from startups through large, established software
organizations.
Student data was collected from interviews with 15 undergraduate students who had
worked at the incubator, while they were taking, or had already taken, the junior year SE
courses. Most but not all were advisees of the author, and these interviews were a part of
asking students to reflect on software engineering learning from industry and learning from
school. Ten more students were interviewed in a similar way as they were working on their
project at the incubator. Additional data was gleaned from ten exit interviews from the
bachelors program, for CS and SE majors, where those with this work experience commented
on process topics. While 35 students thus contributed to this study, their comments were
derived at different times, and usually in an unstructured manner. Corroborating data was
taken from anonymous student feedback in 12 sections of the junior-level SE courses.
Typically, one or more students in each section identified their work background at the
incubator in their discussion of the course they had just taken.
We interviewed the incubator’s project managers for a total of eight hours, in addition to
working with them and with people from the companies on two projects. We interviewed the
entrepreneurs and others in their organizations related to the student work, for an additional
eight hours. Questions were partly structured in each interview, including key questions
about business decisions and the processes and practices they used.

4. Findings
We describe the work situations which we believe influenced students, followed by a
discussion of those effects.

4.1. Work situations

We discovered that most of the new entrepreneurs had pressed strongly to reduce or
eliminate standard software practices, even agile ones, in their rush to market. The
incubator’s project managers felt they were in a struggle with these entrepreneurs regarding
the delivery of a quality product.
Three of the four startup entrepreneurs we interviewed were characteristically impatient
with even agile software engineering processes. This impatience was very clearly stated by
the entrepreneurs as being due to their need to be first into the market, or to meet the needs of
a key customer. The new businesses all added or changed processes during development as
they became aware of issues. They especially changed how things were done in hopes of
meeting their aggressive time-to-market expectations.
The entrepreneurs’ “bias for action” [5] perhaps translated into the following logic: What
has to be accomplished in order to reach the market? The most crucial ingredient, without
which they have nothing, is the code itself. Everything else, therefore, is secondary in value,
in the sense of Herbert Simon’s “satisficing” behavior for businesses [25]. They did tend to
act as if this were their logic, showing much greater interest in code completion than in any
other project step.

121
 The impartial market knowledge with which they operated had the expected effect on
project direction: After talking to a new potential customer, the entrepreneur would return to
the development group with a list of entirely new requirements, hoping sometimes to merge
these into the existing development with little impact, and at other times trying to replace in-
process development with new work on these now higher-priority features. Meetings with
new customers often were accompanied by new deadlines, as well. With one client, such
news bulletins were a weekly event. Most clients delivered their newly-found requirements
informally, via emails, notes, and verbal discussions. Students we interviewed on-the-job
during these times reported dismay over the flux; after all, the code they had been working on
had just been devalued. At the same time, they shared at least some of the entrepreneur’s
excitement over discovering a new, even more important direction.
The three project managers at the incubator did ease the impacts of novice entrepreneurial
behavior. All knew to expect such things. They understood the need for an iterative overall
process style to minimize disruptions, and they argued in favor of establishing suitable
processes early on and sticking with those. They moderated changes to requirements.
However, their power to eliminate the disruptions was limited by the business relationships
with the entrepreneurs. In at least two incidents, the incubator had to keep students on the
project at their own expense, doing testing and documentation, because the entrepreneurs
refused to pay for them, claiming their work was slowing down the project.
In contrast to the new entrepreneurs, discussions with the more established business people
who had worked with these students showed a different attitude about process. A typical
concern of the established businesses was that the processes and tools used on a new project
at the incubator be like those used in other projects by that company. One established
company brought-in their own on-site project manger to the incubator, specifically to help
students use their processes and tools. Another company was there in order to use well-
defined processes to reverse-engineer their existing, successful system which they had created
without much process as a startup, so as to begin building its successor.
In general, versions of processes and documentation to be taught by the school were used
consistently by these established companies throughout their development cycles. An
exception to this difference was found in an existing company which was incubating a
product for a new market. This company had always had a very small software staff and was
having its first try at a larger scale development effort. Essentially none of the company’s
previous processes were suitable for such an upgrade in staff size. The project furthermore
was to enable them to move quickly into the new market. In this project, process variations
were tried and discarded in much the same way that the new entrepreneurs did this.

4.1. Effects on students

Impacts on the students from both kinds of experience were strong. In classes on software
process which they took following their work experience at the incubator, they valued most
the processes they had used on the job. Overall, their value of process topics in class
reflected the work experience.
Students can easily revert to non-process based methods of problem solving, even without
an industry experience which says to fall back to this when you’re in a hurry [15]. We
believe that it was a strong influence on students, seeing such reversion modeled in a startup
client. Students working for startups were sometimes openly at odds with process lessons
taught in their SE classes. They most devalued the more traditional and robust methods but
tended to generalize that critique. Some said that software engineering process itself was of

122
only slight value, noting that this mirrored the sentiments of the entrepreneur they had worked
for. These students sometimes cast their arguments as claiming that courses were not
teaching about the “real world” they had come to know. End-of-course feedback from these
students, about process-focused courses, included comments such as, “Class was instructed
well, but had little content.” In exit interviews, two of the students who had worked on
entrepreneurial projects listed their SE process courses as the worst thing about their
undergraduate program.
In contrast, students who worked for more established firms at the same incubator tended
to bring with them the perspective of discovering more value in whatever tools were a part of
the culture of that company. In interviews, they said these were preferred in practice by the
organization they had worked for. Thus, for example, students who had created use cases and
detailed those into test cases, in their work for an existing company, were pleased to find this
method included in their junior year SE program. One student who worked for an established
company at the incubator, in his exit interview, listed as of greatest value to him the
communication skills he learned in the course on requirements. Another simply said, “SE
stuff” was most valuable. A student with the unusual experience of working in an established
company after leaving a startup (both sponsored by the incubator) listed the required courses
in order of importance to him as software architecture, then requirements and quality
assurance, adding that he’d found these were important subjects, and he enjoyed them
personally.
We did not see the same negative relationship with students who worked for new
entrepreneurs at the incubator after they took the junior year process-focused courses.
However, the number of students in this situation was small. One student said that knowing
the processes and documentation methods helped him in such a project his senior year.
Another, who took the process courses early, later on brought department faculty from the
school into his new-entrepreneur-led project at the incubator, to help with process.
Overall, we believe our interview data supports the position that, when students worked at
established companies prior to taking process-focused SE classes, their industrial experiences
and their educational experiences did reinforce each other. However, when students worked
at startups prior to those classes, this model of reinforcement was not the case. We believe
the most distinguishing factor in this difference was the hesitant and inconsistent use of
software processes by the startups.

5. Conclusions, practical implications and future work

We believe that students are influenced especially strongly by being a part of a startup
enterprise. Despite the fact that such software enterprises are embedded in the electronic
business revolution, there are concerns about the messages undergraduate SE students will
learn from employment in those enterprises, if they get that startup experience prior to
learning about software processes in school. We see a reverse function working here, the
opposite of the desired one that process knowledge drives quality into the software
development workplace. This reverse function is that a lack of process or inconsistent use of
process in the workplace sets up students to get less than full benefit from their education
about quality software processes. The enthusiasm and dedication of the entrepreneur appears
to have a stamp of realism which transfers their values, including reinforcing a possibly
already natural impatience with process in young students.
Rohde et al. reached similar conclusions for why they were not very successful in
establishing a “community of practice” between students and start-up practitioners: “The

123
start-up companies were very young enterprises which had not established a consolidated own
practice.” In repeating their endeavor to have students learn a unified practice in school and
at work, they selected start-up companies “which were thought to have a more stable software
engineering practice, and which had been founded earlier and therefore had a longer history,
and more employees” [15].
Schein lends theoretical support to our conclusion about a startup’s strong influence. He
rates the strength of an organization’s culture in terms of its homogeneity and stability of
group membership, and the length and intensity of the shared experiences. A new venture
would rate very high on intensity, if not on the other variables. Schein hypothesizes that
young groups “strive for a culture strength” as a way of creating an identity for themselves,
suggesting a high level of value transfer. He further states that cultural elements based on
anxiety reduction will be more transferable than those based on positive problem solving, and
startups are notoriously anxiety-ridden because of the flux. He adds that cultural solutions are
strongly generated by the founders of new groups [24].
A structural way to fix the problem, of student work experience versus their following
educational experience, would be to dissuade students from working in novice entrepreneurial
situations until after they had taken process-focused SE courses. This might reduce their
work experience time while in college, but could add value to their education and provide a
more mature framework for the coop employment experience.
At present, students become ready for useful employment in coop jobs before they are
ready to take the more sophisticated process courses, typically during their sophomore year.
Those who work in startup businesses while their ideas about software engineering are still
forming need to be given some introductory training and/or debriefing afterwards, in
preparation for process courses. In the author’s circumstance, these sessions could be
provided jointly by the school and by the project managers at the incubator, as a means of
maintaining a clear link between school and work.
Further exposure of inexperienced entrepreneurs to software engineering processes is
recommended. It is uncertain that any amount of training will counteract the abruptness with
which new entrepreneurs morph how they are doing business, in their race to market.
However, providing them with even more ongoing training and advice could be a partial
remedy. The entrepreneurs studied were novices to software engineering, not in a position to
appreciate the forces at play in creating a quality product which is invisible.
A larger data sample and formal interviewing are needed to verify our results.
Longitudinal studies would allow isolation of variables. For example, students who are
attracted to working in a startup while in school may already have attitudes about process
which differ from those of other students.
This investigation is a spin-off of a more general software engineering curriculum study, in
which the author noticed that there were differences in student attitudes about the course
material which seemed related to their work organizations. It is possible there are additional
variables of interest in this mix. For example, perhaps students with entrepreneurial
experience do learn as much about software process as other students, but simply do not value
this knowledge. Studies of impacts of cooperative education on students are a common topic
of the Journal of Cooperative Education and Internships [26].

6. References
[1] Hilburn, T.B., Townhidnejad, M. “Software quality: a curriculum postscript?” ACM SIGCSE Bulletin, Volume
32 Issue 1, March 2000.

124
[2] Carrington, D., Strooper, P., Newby, S., and Stevenson, T. “An industry/university collaboration to upgrade
software.” The Journal of Systems and Software 75 (2005), 29–39.
[3] Nash, S.H., and Redwine, S.T. “People and organizations in software production: a review of the literature.”
ACM SIGCPR, Volume 11 Issue 3, January 1988.
[4] Bass, M. “Examples of successful technology transfer: A survey of software related academic collaborations at
Siemens.” Proceedings of the 2006 International Workshop on Software Technology Transfer in Software
Engineering, May 2006.
[5] Barton, L., and Barton, J. “Being an entrepreneur.” IEEE Potentials, Volume 9, Issue 4, Dec 1990 Page(s):26
– 28.
[6] Software Engineering in Startup Companies. Java Developer’s Journal. http://java.sys-
con.com/read/36006.htm, last visited Nov 28, 2007.
[7] Saiedian, H. “Software engineering education and training for the next millennium.” The Journal of Systems
and Software 49 (1999), 113-115.
[8] Saiedian, H. “Guest editorial: The new context for software engineering education and training.” The Journal
of Systems and Software 74 (2005), 109–111.
[9] Lethbridge, T.C., Diaz-Herrera, J., LeBlanc, R.J., Jr., and Thompson, J.B. “Improving software practice
through education: Challenges and future trends.” FOSE '07.
[10] Lethbridge, T.C. “Priorities for the education and training of software engineers.” The Journal of Systems
and Software 53 (2000), 53-71.
[11] Denning, P.J. “The social life of innovation.” Communications of the ACM, Volume 47 Issue 4, April 2004.
[12] Umesh, U.N., Huynh, M.Q. and Jessup, L. “Creating successful entrepreneurial ventures in IT.”
Communications of the ACM, Volume 48 Issue 6, June 2005.
[13] Fernandez, J.D., Garcia, M., Camacho, D., and Evans, A. “Software engineering industry experience: the key
to success.” Journal of Computing Sciences in Colleges, Volume 21 Issue 4, April 2006.
[14] Fincher, S., Petre, M., and Clark, M. (Eds.) Computer Science Project Work: Principles and Pragmatics.
Springer-Verlag, 2001, ISBN 1-85233-357-X, p. 42.
[15] Rohde, M., Klamma, R., and Wulf, V. “Establishing communities of practice among students and start-up
companies.” CSCL '05.
[16] Smarkusky, D.L., and Smith, H.H. “Team projects throughout the curriculum: course management, teaching
initiatives and outreach.” Journal of Computing Sciences in Colleges, Volume 19 Issue 5, May 2004.
[17] Williams, K.A. “Industry and university collaborative learning pilot project.” SIGCSE '97, Volume 29 Issue
1, March 1997.
[18] Woodfield, S.N., Stokes, G.E., and Crandall, V.J. “On-campus cooperative education.” SIGCSE '87, Volume
19 Issue 1, February 1987.
[19] Trudel, C., and Trudel, A. “World's first undergraduate e-commerce specialization offered by a computer
science department.” Journal of Computing Sciences in Colleges, Volume 20 Issue 2, December 2004.
[20] Software Engineering for Internet Applications (6.171). (MIT Course description.)
http://philip.greenspun.com/teaching/one-term-web, last visited Nov 28, 2007.
[21] Reichlmayr, T.J. “Collaborating with industry: strategies for an undergraduate software engineering
program.” SSEE '06.
[22] Mulder, M.C., Prey, J.C., Haines, J.E., and Lidtke, D.K. “Collaborative learning in undergraduate information
science education.” SIGCSE '95, Volume 27 Issue 1, March 1995.
[23] Curran, W.S. “Teaching software engineering in the computer science curriculum.” ACM SIGCSE Bulletin,
Volume 35 Issue 4, December 2003.
[24] Schein, E.H., "Coming to a New Awareness Organizational Culture," Sloan Management Review, (Winter
1984).
[25] Simon, H. Administrative Behavior: A Study of Decision-Making Processes in Administrative Organizations,
4th ed., 1997, The Free Press.
[26] Journal of Cooperative Education and Internships, ISSN 1933-2130, http://www.ceiainc.org/journal/, last
visited Nov 30, 2007.

125