Populi: more advanced than the Space Shuttle

But not as advanced as Age of Empires

Information is Beautiful, a data visualization site run by one David McCandless, has charted the relative sizes of the codebases of some notable games, machines, and computer programs. Visualized in terms of number of lines of code, it's an interesting look at just how much programming's required to make things run.

click to embiggen

Populi, at around a half-million lines of code, beats out the Space Shuttle by a cool 100,000 lines. TAKE THAT, NASA.

Granted, that's a bit of an apples-to-oranges comparison—the Shuttle software was designed in the late-70's and early-80's for the high-end computers of the time. A more apples-to-apples comparison would measure Populi alongside another modern, complex, person-centric app driven by a relational database. The only other thing like that on here is... Facebook, weighing in at around 61 million lines of code (and one-point-something billion users).

The Harvard Business Review on building a startup outside of Silicon Valley

We've made no secret of our dislike for the typical startup-takes-venture-capital storyline and culture. Maxwell Wessel at The Harvard Business Review just about codifies what repels us about it:

Raising venture capital isn’t the be all and end all of entrepreneurial success. But it is an important metric... for an important subset of the business world — firms in pursuit of explosive growth — raising capital from angel investors or venture capitalists is an early step on a long and uncertain road to success.

So, firms in pursuit of explosive growth that raise capital to fund a long and uncertain roadtrip to success are an important subset of the business world.

If you judge entrepreneurial success as surviving or selling (including raising follow-on funding, being bought, or successfully IPO’ing) as no doubt your investors do, then your odds of success are lower outside of the superhubs.

What if you judge it by something meaningful, like building something that makes your customers' lives better?

Every business is unique, so I would never claim to have the perfect answer for any founder trying to select his or her location. It’s not that founders outside of superhubs work any less hard, are any less talented, or have worse ideas. The reason the numbers look the way they do is because the environments are fundamentally different in start-up superhubs. And until community members acknowledge the shortcomings of secondary markets, and come up with some way of addressing them, then we should be open and honest with our entrepreneurs about the heavy toll they will pay to build their businesses where they live today.

The heavy toll we pay here: we're home for supper every night; our wives, children, and friends know and love us; every customer is important to us; no one's forcing us into ill-advised moonshots; we spend a good 25% of any given workday laughing together; we don't spend our days making money for someone else.

Ah, the high cost of not moving to Silicon Valley to change Populi into something that won't be here in five years.

Privacy Policy updated

We just updated our Privacy Policy.

Previously, Section 8 (our policy towards children) included a blanket statement indicating that we do not collect information about children under 13—and that if we inadvertently did, we would delete it. However, we realized that this statement went a little too far for our customers. Many of you actually do keep records of children under 13—whether as relatives of faculty or staff, as prospects, and sometimes even as students. Not wanting to commit ourselves to deleting customer data that you're allowed to collect, we wanted to clarify the policy regarding information about children under 13.

So, the long and the short of it is that...

  • It's our responsibility to delete information about children under 13 that we may take in through this site (populi.co).
  • It's your responsibility to take all appropriate precautions with such information that you manage through your school's populiweb site.

If you have any questions about any of this, please don't hesitate to contact us.

Alan Klement: Replacing the user story with the job story

Expanding on Brendan's post about designing for the “job to be done” rather than starting with a visual design, Alan Klement introduces us to the idea of using "Job Stories" instead of "User Stories":

Summed up, the problem with user stories is that it's too many assumptions and doesn't acknowledge causality. When a task is put in the format of a user story ( As a [type of user], I want [some action], so that [outcome] ) there's no room to ask 'why' - you're essentially locked into a particular sequence with no context.

The distinction may seem subtle at first, but it's easy to make the mistake of designing a particular interface or workflow to meet the needs of one specific “user”, when it will actually be used by different people in different roles seeking different ends. Writing a story about the job someone wants to do—rather than assuming what kind of user they are—should lead to designs that work better in the real world.

Job Stories are great because it makes you think about motivation and context and de-emphasizes adding any particular implementation. Often, because people are so focused on the who and how, they totally miss the why. When you start to understand the why, your mind is then open to think of creative and original ways to solve the problem.

We've seen something like this at work in our Feature Request Forum. Users suggest features based on their own particular user stories (nothing wrong with that). But it's not until other users pile on with their own suggestions (and user stories) that the job story emerges. We've found that it often takes multiple perspectives on the problem for us to identify the job to be done.

"Include unfinalized courses" toggle on the students table

Now available on the Students table: the "Include unfinalized courses" toggle. When checked, it factors in-progress grades from your students' unfinalized courses into the Term GPA, Cumulative Units, and Cumulative GPA columns. When unchecked, it backs unfinalized information out of those columns, giving you the same figures formerly available only on individual transcripts.

9-25-13 No show unfinalized

9-25-13 Show unfinalized

Over the years we've tuned the Students Table to show as much real-time information as we could—thus, Cumulative GPA factored in student performance in unfinalized courses. But some users informed us that they also need the Table to give them snapshots of where the students were starting from in a given term... so that unfinalized info was getting in their way.

Thus, the toggle. Now you can get two perspectives on all your current students with a single click.

The job to be done

Inside Intercom's The Dribbblisation of Design lambastes software designers who start with the visual design of their program without first considering the underlying layers of a well-built app.

Much of the product design work from job applicants I’ve seen recently has been superficial, created with one eye towards Dribbble [an online design community]. Things that look great but don’t work well. Perfect pixel executions of flat design, but work that doesn’t address real business goals, solve real problems people have every day, or take a full business ecosystem into consideration.

The best software design starts with the unglamorous stuff: what is the user trying to accomplish? How can the software help them do that? How can the software explain how it works to the user?

This way of thinking owes much to Clayton Christensen, a Harvard Business School professor whose ideas on management and business are summarized in his "Job To Be Done" framework.  JTBD leads with this question: what job is the user hiring this product/service to do? It has a surprising range of applications—software, household products... and even milkshakes. And there's no doubt that it has plenty of uses in designing college management software.