TITLE: Some Thoughts from a Corporate Visit: Agility and Curriculum
AUTHOR: Eugene Wallingford
DATE: July 21, 2017 3:47 PM
DESC:
-----
BODY:
Last Thursday, I spent a day visiting a major IT employer in our
state. Their summer interns, at least three of whom are
students in my department, were presenting projects they had
developed during a three-day codejam. The company invited
educators from local universities to come in for the
presentations, preceded by a tour of the corporate campus, a
meeting with devs who had gone through the internship program in
recent years, and a conversation about how the schools and
company might collaborate more effectively. Here are a few of
my impressions from the visit.
I saw and heard the word "agile" everywhere. The biggest effects
of the agility company-wide seemed to be in setting priorities
and in providing transparency. The vocabulary consisted
mostly of terms from Scrum and kanban. I started to wonder how
much the programming practices of XP or other agile methodologies
had affected software development practices there. Eventually I
heard about the importance of pair programming and unit testing
and was happy to know that the developers hadn't been forgotten
in the move to agile methods.
Several ideas came to mind during the visit of things we might
incorporate into our programs or emphasize more. We do a
pretty good job right now, I think. We currently introduce
students to agile development extensively in our software
engineering course, and we have a dedicated course on software
verification and validation. I have even taught a dedicated
course on agile software development several times before, most
recently in
2014
and
2010.
Things we might do better include:
- having students work on virtual teams. Our students
rarely, if ever, work on virtual teams in class, yet this is
standard operating procedure even within individual companies
these days.
- having students connect their applications programs to
front and back ends. Our students often solve interesting
problems with programs, but they don't always have to connect
their solution to front ends that engage real users or to back
ends that ultimately provide source data. There is a lot to
learn in having to address these details.
- encouraging students to be more comfortable with failure
on projects. Schools tends to produce graduates who are
risk-averse, because failure on a project in the context of a
semester-long course might mean failure in the course. But
the simple fact is that some projects fail. Graduates need to
be able to learn from failure and create successes out of it.
They also need to be willing to take risks; projects with
risk are also where big wins come from, not to mention new
knowledge.
Over the course of the day, I heard about many of the attributes
this company likes to see in candidates for internships and
full-time positions, among them:
- comfort speaking in public
- ability to handle, accept, and learn from failure
- curiosity
- initiative
- a willingness to work in a wide variety of roles: development,
testing, management, etc.
Curiosity was easily the most-mentioned desirable attribute. On
the matter of working in a wide variety of roles, even the people
with "developer" in their job title reported spending only 30% of
their time writing code. One sharp programmer said, "If you're
spending 50% of your time writing code, you're doing something
wrong."
The codejam presentations themselves were quite impressive. Teams
of three to six college students can do some amazing things in
three days when they are engaged and when they have the right
tools available to them. One theme of the codejam was "platform
as a service", and students used a slew of platforms, tools, and
libraries to build their apps. Ones that stood out because they
were new to me included IBM BlueMix (a l´ AWS and Azure),
Twilio ("a cloud platform for building SMS, voice and messaging
apps"), and Flask ("a micro web framework written in Python").
I also saw a lot of node.js and lots and lots of NoSQL. There
was perhaps a bias toward NoSQL in the tools that the interns
wanted to learn, but I wonder if students are losing appreciation
for relational DBs and their value.
Each team gave itself a name. This was probably my favorite:
int erns;
I am a programmer.
All in tools, the interns used too many different tools for me to
take note of. That was an important reminder from the day for me.
There are so many technologies to learn and know how to use
effectively. Our courses can't possibly include them all. We need
to help students learn how to approach a new library or framework
and become effective users as quickly as possible. And we need to
have them using source control all the time, as ingrained habit.
One last note, if only because it made me smile. Our conversation
with some of the company's developers was really interesting. At
the end of the session, one of the devs handed out his business
card, in case we ever wanted to ask him questions after leaving.
I looked down at the card and saw...
... Alan Kay. Who knew that Alan was moonlighting as an application
developer for a major financial services company in the Midwest?
I'm not sure whether sharing a name with a titan of computer science
is a blessing or a curse, but for the first time in a long while I
enjoyed tucking a business card into my pocket.
-----