Developing a Headache

By Michael Fienen - Mon, Mar 28, 2011

General, Programming

Developing a Headache

Back in February, Gagan Biyani of Udemy.com made a terribly poignant assessment of a particular facet of higher education: we are not in the software development business. We are in the knowledge business, and the other functions that take place on campus are ultimately designed around supporting that goal. What I am talking about is flattening. Ultimately, committing entire teams of people to producing and supporting software for the university is a growing burden for us, and it’s my argument that we need to know when to walk away.

To clarify, I understand there will always be specialized software needs at universities - especially in areas related to research that takes place or connecting disparate systems together. What I am talking about are specifically our institutional applications that we all have in common: learning management systems, common application, catalogs, student portals, CRMs, etc. These are areas that in the past, we had no choice but to venture in to on our own. Today, however, vendors can supply many of our most common needs: for a cost.

I don’t expect what I’m going to talk about here to be popular. I don’t expect a lot of people to agree with me either. This is one of those cases where you’re either going to be totally with me, or you’ll think I’ve gone off the deep end. I welcome discussion on the topic, and I know every institution is unique in ways that will make this more true for some, less for others. All I ask is that if you feel the need to lambaste me for what I say today, first consider if the core philosophy of what I’m getting at is flawed, and go after that - I’m already well aware of my personal insanity.

About That Cost

So obviously, cost is indeed a factor. But cost is a factor regardless whether you are purchasing software or paying developers. But because the money comes from different pots, we don’t always think about how they offset. Individually, each school should regularly sit down and audit programming hours versus software costs. Here is an extreme example: which is more cost effective - purchase licenses for 1,000 machines to install Windows, or write your own operating system? We’ll always buy the ready made operating system, because it makes no sense to write our own - heck, we can’t even be bothered to effectively fork a Linux distro for our own needs. I’m not saying buying software is always the answer, but it frequently will be.

And consider this: we already know this is true. Look at the number of schools around the country jumping on board with things like GMail and Google Apps. They’ve discovered that there are huge cost savings in outsourcing these tools. Less administrative maintenance, lower hardware costs, less overall overhead (in people or otherwise), along with better user experience. Google can afford to pour millions of dollars into their email platform to make sure it’s top notch. They employ the best programmers, HCI experts, and UI teams. Their security models would run circles around us. How do we stack up to that, by comparison? We can’t compete with those economies of scale, it’s fiscally absurd.

There’s another money issue as well: pay. The fact of the matter is we cannot afford to go after the highest quality or most experienced programmers. We don’t even stand a chance in the open market. Do searches on job boards for higher ed. On average, many universities are paying programmers between $35,000 and $55,000 depending on the position level. Even at the top end of the spectrum, we are miles below the industry standard. In fact, that’s even below the trailing edge of the bell curve.

payscale Developing a Headache

Average pay for a web applications developer (src: payscale.com)

How does that impact us? Several ways. One, we end up hiring more programmers, because it takes more inexperienced or entry level programmers to do the same amount of work compared to a single really awesome one. Two, we can’t retain the good ones. On the chance we get someone young and eager, they use us (knowingly or not) to get some experience, then jump ship to someone offering way more money once they’ve padded their résumé. The ones we keep around are the ones that can’t go elsewhere (not necessarily because they aren’t talented, but maybe they have ties to the area. Point being, their main reason for being there isn’t because they love the job) or are at the end of their careers. I mean no offense to any of our developer readers, and there are always exceptions, but anecdotally our community is littered with the stories of our friends and colleagues who have moved on to private sector jobs. Where we do need programmers, we’d be much better off competing with the private sector for them and just hire a couple really great ones.

The Higher, the Fewer

So, when we can’t compete with the private sector, we discover that we are trying to create software from subpar resources. In other words, we’ve already set ourselves up for failure. You can tell when you’re in trouble if you ask to look at documentation, or code revisions, or do a security audit. This is something you can actually test out yourself, just go attempt some basic XSS attacks on some of your in house applications (note: it’s probably a good idea to let your security officer know you’re doing this). Try running some accessibility tests, for some extra fun.

Why are those things so frequently issues? Because we aren’t getting the best programmers that also take time to consider things like UI/UX, design, and other factors. Consideration isn’t given to things like APIs. They think in code and code only, and deal with problems only when they come up, rather than planning for them ahead of time. This is ultimately bad for the end product and bad for the user experience.

You’re also likely to notice that higher ed institutions lack any kind of true development shop methodology. You don’t hear words like scrum, agile, or waterfall thrown around when discussing the development of your latest portal system. Commitments to a specific architecture like MVC, MVP, or MVVM are likely to get you quizzical stares. It’s all increasingly problematic at schools that employ multiple programming languages or platforms, as opposed to shops that specialize in one.

If we commit programmers to anything, we should try to focus on using them to create the necessary API interfaces to bind systems together. Work on the mortar, not the bricks.

It’s a Zoo Out There

The other problem we have is that higher ed simply doesn’t know how to treat programming staff. We treat them like animals in a zoo, caged up and limited. If they aren’t stuck in a cubicle farm, they’re walled off in offices or buried in a basement. Either way, silly things like natural light and open communication space isn’t even so much as an afterthought in a lot of places. It’s the kind of place you would stick criminals, not people you want building tools your whole institution would lean on. Use it for storage, not people.

On top of it, while programmers in higher ed tend to get pointed a dozen different directions at any time, in the private sector you usually will find yourself getting into a focused, goal oriented shop - a much better working environment. Good programmers will look for teams that focus on the methodologies they use, or build tools they are familiar with. Bottom line, they find a working environment that fits them like a pair of comfortable shoes.

Think about how the big boys do it. And if not them, think about how even tiny startups do it. Better yet, just think about how any business relying on programmers treats them: don’t hide them, give them room for creative freedom in their space, and give them means to collaborate and communicate (believe it or not, that’s important for everyone, not just programmers). You don’t have to look any farther than the homes of Google, Pixar, Facebook, or Zappos (that’s not to say you have to be worth a billion dollars to give employees a good working environment though, they just happen to excel at it) to see just how they work hard to create an environment that is conducive to work, and also inspiring and designed to keep developers happy. Again, we don’t even compare. That’s no way to attract or retain good employees.

Yeah, but…

I have no doubt the exceptions will chime in with comments to this editorial. And I’m glad they are exceptions. And here’s a good bottom line. If you have talented programmers, and you are paying them enough to keep them there and happy, and they are making software you are proud of that does an awesome job: SELL IT. I’m not even kidding. If you are that lucky, then you need to turn that around and make some money off of it, because you’ve found an equation that would make you capable of competing with the private sector. So milk it, and use the result to give back to the institution.

That’s your barometer. If you would be proud to sell the software that you make in house (customizations not withstanding), pat yourself on the back because you’ve mixed up a batch of the secret sauce. If, however, you give pause to the idea, then maybe - just maybe - your school shouldn’t be in the business at all. Instead, consider a partnership with a development firm that is well versed in addressing customer needs and build a good relationship with them - they know what they’re doing better than any of us could.

Higher ed is one of the few industries that remains hell bent on doing everything ourselves, and for no good reason. More often than not, attachment to these older practices comes out of legacy, rather than good leadership. “It’s always been done that way” is not an excuse that cuts it in today’s market. Even if you’re making it work now, you’re only a turnover or two away from your whole world changing.

Conclusions

End of story: we gotta stop fooling ourselves. This isn’t a world we can win in any longer - heck, we can’t even compete in the first place really. It did make sense once upon a time, but those legacy memories are not a reason to resist doing better. If nothing else, if we aren’t evolving, then the ultimate financial considerations of maintaining internal dev shops will force our hand at a point when we aren’t quite ready for it. We can ease that pain by starting to prepare now.

I don’t want to sound like a negative Nancy, or like an advocate for firing people or downsizing, but change will happen with or without our cooperation. If you aren’t already, questions like these will begin to be asked when it comes to how these efforts best serve our institutional goals, and the answers are getting harder every month that passes.


Photo Credit: cc icon attribution small Developing a Headachecc icon noderivs small Developing a Headache Some rights reserved by jeantessier


The content of this post is licensed: The post is released under a Creative Commons by-nc-sa 3.0 license


Tweet
Share
StumbleUpon It! Del.icio.us

Like this post? Be sure you've subscribed to the .eduGuru RSS feed or email to get all the latest news and articles.


Read Related Posts on .eduGuru:

  1. Equal Pay for Equal Work
  2. IMHO 7 Reasons Why Higher Ed Is the Best Gig in All the Web
  3. Is There a Brain Drain Coming?

This post was written by:

Michael Fienen

Michael Fienen - who has written 78 posts on .eduGuru

Michael joined Pittsburg State University in Pittsburg, KS (NOT Pennsylvania, they spell it wrong anyway) in 2006 and is currently the Director of Web Marketing.  He is also CTO for the interactive map provider nuCloud. Web development's role in interpersonal communication is a principle focus of his efforts to improve and enhance higher ed web commodities.  He is an active supporter of the dotCMS community, accessibility advocate, freelance consultant, frequent speaker at web events, and general purpose geek who wears many hats.  Read his complete bio.

Michael's Blog Michael's Facebook Michael's LinkedIn Michael's UWebD Profile Michael's Twitter Michael's Flickr Michael's YouTube Michael's Digg Michael's FriendFeed Michael's Profilactic Michael's Google Profile Michael's FoursquareProfile


  • http://joel.thegoodmanblog.com Joel G Goodman

    so - great article fienen. This is stuff I’ve been thinking about a lot this past year.

    There’s a huge hurdle: the marketplace. Even though vendors *can* provide what we need, often times it isn’t good enough. That’s beginning to change a little bit with some of the newer offerings (like Inigral and Coursekit), but for the most part we have to pick between the lesser of Sungard, Oracle, Blackboard, Jenzabar… which are all in the same boat of being subpar to what students, faculty, heck even your technical devs and designers, expect a webapp to be.

    When is that going to change? I think there’s a breaking point that’s coming - and it’s just what you’re describing - I just hope that when our hand is forced there are some better products out there.

  • http://fienen.com/ Michael Fienen

    That’s the rub. Everybody likes to complain that current marketplace offerings aren’t up to snuff, but frankly, I’ve not seen anyone in higher ed doing much better (and like I said, if they are, they should be selling that thing). So we should at least take the lesser of evils. Instead, internal politics almost always drive us to the worst process in many cases. It’s backwards, but that’s what happens.

    I have to give credit to people like Carlton College (who developed and released Reason CMS). There are examples of good work coming out of a few gems. But they are always the exception, not the rule.

  • http://www.lynchburg.edu Kris

    Very well put. To me most of this is about specialization; it’s an economic issue. The firms that specialize in programming will do it better than a jack&jill-of-all-trades team which has to provide CMS support and help people upload photos in between creating apps for the website. We’re simply not equipped to do it efficiently - leaving aside the issue of financial support.

  • http://stlcc.edu George

    Well done Michael. I have to agree with much of what you say. I believe that integrating the systems we have is more important than creating new programs. Why not let the companies that are dedicated to builing a particular program, that can amoritize the costs over multimple installations do what they do best. Just integrating the OTS packages is enought to keep our staff busy.

  • http://joel.thegoodmanblog.com Joel G Goodman

    yeah, that’s not my point. I guess what it really comes down is that universities are okay with mediocrity–-we practically force it in many regards.

    Someone who has a handle on what is wrong with the current offerings needs to break out of higher ed and build a killer app. Something inclusive, or at least something that is flexible enough to combine the greatest apps (think combining Coursekit, the Schools App, with an awesome CRM solution) in seamless ways. I’ve got a whole plan to do it, but I’m no programmer.

    I think it’s a more complicated issue than just “higher ed can’t withstand the financial strain of keeping production in house.” The reality is that we’ll still pour tons of money into software (outsourced/purchased) and continue to retention numbers plateau or decline, until we can really focus on the community experience (student, faculty, administrator).

  • http://www.ten-321.com/ Curtiss

    I agree in principle with what you have to say, but I wonder what the solution really is. I also wonder how much the real cost is calculated when making decisions like this. In most cases (especially when it comes to learning management systems and donor databases), the cost of hiring an outside vendor is generally much, much higher than the initial cost of purchasing the system. There are almost always serious limitations (in some cases, those limitations can even lead to lawsuits; particularly in regard to accessibility issues that are ingrained in the systems), and many of them are so user-unfriendly that you spend more time training staff and students on using the system than you might have spent writing your own.

    That said, I think there are also issues of accountability that weren’t mentioned in the article. I know plenty of programmers that are probably perfectly capable of writing a nice, user-friendly system; but do their best to stay miles away from it because of accountability issues. If a vendor’s database has inadequate security, and the information is hacked somehow, the vendor is ultimately on the hook for that breach. If an in-house system is hacked somehow, the developer is on-the-hook. When it comes to FERPA and PCI security standards, that tends to be a mire into which most independent developers would rather not wade.

    Onto another topic - Regarding your comments on Gmail; do you guys have any recent data on how many institutions have moved to Gmail? Did they move the entire institution to the system, or was it just the students? I suspect a lot of them are simply moving the students to Gmail and keeping the institutional mail in-house; and I think that may be more an issue of separating the wild, wild west that can be student e-mail systems from the more controlled environment in which institutional mail needs to reside.

    Also, although higher ed is woefully behind when it comes to financial compensation for its developers; many institutions do offer other benefits that make up for the financial compensation. I may be one of the exceptions to which you refer in the article, but I am very happy working in higher ed. For me, as a family man, there are things more important to me than money. The amount of leave, the great healthcare coverage (at a percentage of the cost I was paying for the same coverage at my last private industry employer - as a comparison; I now pay a total of about $200/month to cover my whole family under my health insurance; at my last private industry job - which was 6 years ago - I would have had to pay ~$800/month just to add my wife to the coverage), the retirement benefits, etc. make up for the lower compensation in many cases.

  • http://csumb.edu Kevin Miller

    When our campus moved to Google Apps, we argued to the campus that our offering Email and Calendar is like asking the Facilities department to build all the chairs on campus; however, when it comes to the business processes specific to universities, the vendors available are often pretty poor. We publish our Web Project guidelines for vendors (http://it.csumb.edu/best-practices-web-projects) and most hang up the phone out when they see our requirements.

    I think there’s a middle path, however. Our Web Services department is a Drupal shop, that’s just the tech we chose, but there are other frameworks out there (Django, etc). We leverage Drupal and its open-source ecosystem to build applications rapidly, and usually do custom coding just to do “enterprise integration” (read: working with our crappy SIS) and alignment with our campus visual design. On most projects, we share those projects back to the community.

    I think that by choosing a flexible framework that can get you 90% there with most projects, campus web developers can turn out awesome projects with less overall cost, and with the ability to fit snugly within their campus infrastructure and culture.

  • http://uwaterloo.ca Megan

    Interesting points! We recently had a major software project fail after three years. It was a good idea, but it seems that there were never enough resources allocated. Here it always seems like people expect you to be able to develop custom software with very few resources (e.g. let’s just hire some co-op students - seriously ??? You think that’s an appropriate way to develop a major application??). They think it’s going to be more cost-effective to do it this way. But, really, in many cases the cost of that development and the associated headaches are often not worth it.

    Application development is becoming so much more sophisticated than it was before the Web 2.0 era began. The UI expectations are much higher (in a good way) than they used to be. Like you said, trying to do this in-house is becoming increasingly difficult.

    Personally, I would like to see more of an open source culture in higher ed. We all have the same problems or at least similar problems, can we work together to solve them? I’m not thinking about major enterprise systems like LMS or web CMS’s. Something like the UNL events calendar comes to mind.

  • http://Www.lcmsplus.com Allison Wood

    This is great - couldn’t agree with you more on every point. You have basically sketched the story of our company, LCMS+ - built from the ground up at Duke School of Med by an exceptionally talented prgmr who also understands business goals and objectives and knows that tech has to serve those masters. While Duke has been aggressively supportive of this project, on those rare days when he was told “don’t bother with that” he would just go home and do it on his own time. And now that a hot market has been ID’d for this system (med ed

  • http://Www.lcmsplus.com Allison Wood

    Sorry - lost my ending! Basically, Duke was smart enough to follow your advice and sell this system that the marketplace is obviously ready for. While I am extremely grateful for Duke’s support for this unique in- house success, I agree with you that U’s should generally not be in the SW devt biz - or if they are, know when to cut bait and hand the reel over to the pros. Thx for the great read, look forward to following you.

  • http://www.inigral.com Michael Staton

    Michael,

    I really enjoy this post (and also the honorable mention). At Inigral, we strive to understand Higher Ed AND have well-designed, well built software. We have a great company culture and really high standards that we strive to keep.

    It’s disheartening when we talk to schools who seem to evaluate our software as something they consider as a build or buy. It’s difficult to build a great app. It’s even harder to increase the depth and breadth of the problems that software solves, while keeping the software simple and usable. It’s even harder to maintain that software as you start to get competing priorities asking for different functionality. If it takes us every day all day, plus $7 million in investment from three venture capitalists and the Gates Foundation, I have trouble imagining an educational institution throwing underpaid developers in a zoo pen, pulling them in different directions, and building successful software.

    One challenge that we also needs to discuss is raising the standards Higher Ed has for their current vendors, and switching to vendors that are more “with it,” building great products.

    Best Regards,

    Michael

  • http://www.markgr.com/jboye-and-the-end-of-the-web/ jboye and the end of the web | Mark Greenfield

    [...] How much of our work will be outsourced (See Developing a Headache) [...]

  • jim o

    i am not disagreeing or agreeing.

    it is hard to take one aspect of a huge 20 thousand plus institution (students, faculty and staff) like the “programming” department (whomever that is) and say ‘it should run like a programming shop’ or you should just buy software.

    large institutions are giant lumbering beasts with multiple, most of the time, competing departments. not a business with a bottom line. you may see ‘waste’ from a development level but until that changes into a loss of bonuses at the higher level it is not something that is going to get a very close look.