General Tech

Posts on technology in general

Creating the ideal university incubator for software development

The rationale for a new approach

Nearly every university I visit (public or private) does a great job at providing the fundamentals of computer science and engineering. However, very few spend the same amount of time teaching the more practical skills their students will need to develop sustainable software in a commercial environment. As a result, here is what I usually encounter when I hire new graduates:

  • Knowledge only of a Pure Waterfall Model (something I have not seen applied on any project in the last two decades)
  • Lack of knowledge of basic estimation techniques (causing many late all-nighters for their first few commercial projects)
  • Little understanding — or appreciation — for unit testing and quality assurance (creating many downstream problems on their first 3-4 projects)
  • Lack of experience organizing work into modules that can be split out and developed across multiple team members (resulting in lots of re-factoring and outright re-work of code)
  • Little-to-no experience branching and merging code (causing fixed bugs to “reappear” in later builds)

As a result, I have spent much of the last twelve years teaching (and re-teaching) new graduates basic fundamentals of commercial (i.e., professional) software development. After doing this for nearly 500 software engineers, I have come to the conclusion that we need to do something very different to prepare students for the workplace.

Why a university incubator?

When students enter the university, their minds are the most open to new ideas and possibilities. They have not “learned” why things “can’t be done” and are willing to try new ideas. If you do not believe look at developments like: Instant Messaging (Zephyr predated AOL—I was there for it), Web Portals (pre-Yahoo!), Search (Google) and Social Networking (facebook). Imagine how much innovation we could foster if we gave students commercial-grade development environments and taught them the fundamentals of building commercial-grade software when they want to try these ideas.

Why would Universities want to do this? Doesn’t it cross the lines of making them too commercial? I do not think so. Instead, it will make them leading research institutions that can attract large-scale investment from government and the private sector (look at MIT, Stanford, Carnegie Mellon and the University of California at Berkeley for examples).

What does it take to develop this?

Universities need three things to make this a reality:

  1. Change the teaching approach
  2. Recruit industry volunteers
  3. Provide capital hardware and software to students for use

Let’s look at they would apply each:

Step 1: Change the teaching approach

Once professors have taught the fundamentals of computer science and engineering it will become time to begin teaching the “art” of software development.

This starts with the basic premise that one cannot perfectly plan something as flexible as software (it is not the same as building a house). Throw out any references to the Requirements-Design-Development-Test-then-Deploy Waterfall Model. It assumes perfect knowledge (and perfect requirements) at the front of the project. Instead jump right into Agile Development Methods. Pick Scrum or FDD. Challenge your students to form teams to come up with project ideas, then walk them throw the visioning and spiral approaches to developing software in sprints. This will “feel” natural and they will immediately understand that requirements cannot be developed isolation.

Once they have built something, show them the importance of testing and documentation. Teach them what positive and negative path testing is and make them write and execute unit and certification test cases for each other’s work. They will learn how many bugs even the simplest software has and begin to appreciate testing (and upfront planning for testing after experiencing it directly.

Now, take it up a notch. Assign them bigger projects, ones that require them to break up and organize work. Nothing will teach them the importance of modularity and encapsulation than having to integrate the work of multiple people working on their first or second project.

At this point, they have some experience – especially experience recovering from mistakes. This is the perfect time to teach two or three estimation approaches (see my Books I Like for ideas). Make sure you teach them to account for things like optimistic bias and omitted takes like unit testing, integration and performance testing.

Step 2: Recruit industry volunteers

Most of us in industry would love the opportunity to come share our experiences with new students. It gives students insight into how products were built (and what mistakes to avoid). It gives those of us in industry a chance to connect with new students and recruit new talent. It is also fun.

As an added benefit, industry volunteers can provide ideas (or even sponsor) projects for students to work on. This gives students more real-world experience and industry some “free” R&D.
You never know where this could lead: take at look at what Sun achieved sponsoring a little project called Network File System in the late 80s (I remember Beta testing V2 as a student).

PS – I practice what I preach. I am very grateful that Florida Gulf Coast University lets come in from time-to-time to give wild lecture on things like turning off referential integrity to enable scaling to support 10,000 plus transactions per second.

Part 3: Provide capital hardware and software

Here is where those of us in industry (especially those of us who create hardware and commercial software) need to help the most. We need to donate hardware and software (licenses and tools) to universities to enable them to create full-fledged incubation environments. Here is what they need:

  • Enough hardware to setup separate development, integration, test and production environments
  • Licenses to maintain web, application and database servers for each
  • Integrated development environments and basic tools for version management (e.g., CVS), build management, test automation, defect tracking and performance measurement

Imagine what students could pioneer and develop if they had this. Imagine how much we would benefit if we could hire students who understood how to move code across environments, load test and optimize it, and manage multiple branches and versions.

If this is not enough incentive — donations can be costly — think of how you can use this to Beta test your new hardware and software (while writing off donations and seeding a whole market of users familiar with your newest products).

Is this possible? If so, is it possible in many places?

Yes and Yes. I was lucky enough to be exposed to all three of these things at MIT. As result, I began my career two grades higher than other new graduates who started on the same day I did on their first post-graduation jobs.

This can happen at more places than schools like MIT, Stanford, Berkeley, the University of Illinois or Carnegie Mellon. Every state should be doing this in the larger schools of their university systems. It is early-stage economic development that can pay off by driving much innovation at the state and regional level.

So let’s get started.

Don’t build technology, build Business Solutions

In case you forgot, most people are not in the technology business

Most people do not create software and information technology for a living. (This makes the world a lot more interesting than it would be if we all did so.) Instead, they work on providing the goods and services we all use everyday to live complete lives: housing, medical care, energy, food, entertainment, etc. Too many people in the technology business forget this. As a result, they focus on designing and delivering technology from the perspective of technologists. This tends to create hard-to-use products than can often miss their mark. If you do not believe this, take a look at all the comedy sketches and commercials that make fun of software crashes and that not-so-popular tech support guy.

We need to design technology for people who are not technologists

When we design technology, we need to start with the following questions:

  • Who do we intend will use it?
  • Why will they want to do this?
  • How will this make their life — or what they do for a living — better?

This is not a new concept. It has been around for years in many formats. The Chasm Group calls this product positioning. However, they did not invent the concept. The Rationale Unified Process (RUP) calls this the Problem Statement (and airs it with a Solution Position). Most of my friends in Marketing call this Market Positioning.

When we start with these questions, we build “Killer Aps” that are wildly successful. Many software and information technology examples come to mind, from WYSIWYG word processors to TiVo to iTunes.

This is just as important in the enterprise space

Often I hear people say that the above questions are great for consumer products but do not apply in the enterprise space. I am always confused when I hear this… Do people mean that we should not design enterprise products with a focus on enabling business (and public) leaders to make their day-to-day jobs running their companies and agencies easier, more intuitive and more productive? Just look at how successful was at doing this. (Remember their “No Software” campaign tag line?)

What happens when we design enterprise products around the technology (instead of the business)? We create whole new problems when trying to solve old ones. When do know this has happened? When you hear things like “you need to do [X] because [System Y] requires this,” and start to see job postings for people to run System Y — or worse — enter data into (and run reports from) System Y. Why would you ever build something so non-intuitive that you need to create a whole new profession just to operate it?

We can avoid this in the enterprise space by building “business solutions”

I coined the term “Business Service” (in the context of software and information technology) about six months ago:

Busi•ness Solu•tions |’biznis səˈloō sh əns | (noun)

  1. A reusable configuration of technology designed specifically to solve an enterprise problem (or address an enterprise need)
  2. That does not require its end users to understand how the technology is designed, built or adminstrated
  3. Which directly solves a business problems of the enterprise (or meets and unforeseen need).

I found this definition to be a good litmus test: technologies that are Business Solutions support their customers’ businesses, technologies that are not need to be supported by their customers.

What happens when we build Business Solutions?

  • We generate huge ROIs
  • We make our colleagues’ (or customers’) professions easier
  • We build something soon businesses cannot do without

I challenge all of my fellow enterprise technologists to build Business Solutions

Note: I am currently CIO and Vice President of Technology at Neighborhood America. We have codified this concept into the term Business Services (you can read Gartner’s discussion of this concept, here)