The most hyped event of the year is over and the result was disappointing for the Patriots fans. However, it was a good game with a couple of unfortunate calls by the referee and a lot of dropped passes. Well, we had a great time at our home watching the game with a lot of friends. I just realized that I have not written for a couple of weeks because I have been extremely busy with a few software projects that I am working on. I am on Acela express right now, heading to NY City to participate in a Google Apps user group meeting at Google NY. Hope to not run into the ticker tape parade for the Giants and get delayed going to the meeting.

We have been marching along in terms of software development with a slight twist – web applications for the portal which rely on authoritative data stored in Banner and other systems (such as 25Live) that look and act with a level of consistency that the users expect in software. As I have written many times over, I favor this approach to “Let us wait for Banner to deliver these services” because we will be waiting for a loooong time! Also, because this framework is under our control, the interface can be manipulated in ways that are otherwise not possible. Also, if the users are happy with the navigational approach and display of data we provide, we can leave that alone for however long the users desire. This is obviously not the case with software vendors. They seem to know what is good for us when! We all know that they rarely do a good job and choose the most inopportune moments to make changes.

So, one of the first things we did was to develop a framework. We peeled off all the common parts to all the software – authentication, identifying information about the user, what role they have for an application etc.  – and made it common so that when you want to write a new application, you called a routine once and it took care of all of these for you. This is commonly done in software development, so no big deal. We just didn’t have this at Wellesley for a variety of reasons, so we did it to get started. Then you start asking the question of what is it that many people want in these apps and you will begin seeing repeated patterns – collect information from users, act on them, and reports. In other words some form of workflow. OK, so let us create an abstraction of this process – Create Forms, Allow users to Save and do final Submit, Reviewers to be able to act on these (accept or reject), Reports (all accepted, all rejected etc.) and then some administrative functions (someone by mistake submitted, so let us reverse it, someone is unable to post the form, so let me do it for them etc.). And each of these have open and close dates associated with them.

We also created the ability for selected people to masquerade as others (proxying), so that when a user calls about a problem, those with proxy rights will be able to look at the behavior of the software exactly the same way the user is seeing and help resolve issues. The proxy logins are carefully logged for audit purposes. These actions very closely resemble construction business – have blue prints for building a house which have the common components repeated – foundation, framing etc. are standard and done the same way. The variations exist at a very different level and it is true in case of software too. It is also clear that just like the homeowners, the application owners are thankful for the existence of  those who construct the house or the software developer, but they don’t want to depend on them unless necessary. At the beginning of the construction of the house, there is a lot of interaction between the two parties, but then both would love the separation! Same thing in the software development world.  Anticipate and build the app so that the application owner is given as much control as possible – be it setting open/close dates, modifying the forms whatever and get out of their way.

For example, we built the Tanner conference application. Then Ruhlman came along and we simply instantiated Tanner app and made minor modifications and there you are – another app. In fact these mods to Ruhlman will be transmitted to Tanner next year to make that better. Student Leader recruitment by student life has a lot of what Tanner had, but with some additional features, which then was instantiated for Science Center Summer Research recruitment (which by the way took just two days to create).

Now we are at a point where we will be revamping our system to bring in more efficiencies in coding and simplification. For example, based on these apps we have learned a few things as I said earlier – all of them collect information, but what they collect is different; they all have roles and they all want very similar reports. So, why not abstract some of these and parametrize them so that one could call a routine and say create a form with these fields with respective types and these names and have a routine which is asked to simply show select list of fields from a specified database and table? The beauty of the methodology is we can do all of these without ever changing the user experience.

When I began at Wellesley and proposed such a methodology I heard the usual “you don’t know the Wellesley culture” where the users are way too specific about what they want. These levels of abstractions don’t work here. Yes they do! It is just that one needs to explain the cost of delivery of such customized solutions. We can either build such custom apps to suit the individual requirements and needs and take forever to deliver (which has enormous cost implications) or go with consistent and highly functional solutions which are easy and quick to build which may not have all the bells and whistles one ever wanted.

Another great advantage to all of this is that any programmer should be able to dive into an app developed by another and get to issues right away. We need that level of redundancy. Individual touches are always welcome, but not at the expense of increased overhead of support!

It is really no different than building a home where the owners dream about all great customizations. They are brought down to earth when they hear the cost of such a venture. I think we have demonstrated what is possible at this point – over 10 different portal applications used by the faculty and students with very minor complaints which all have been addressed. One of them is my absolute favorite – why don’t you simply say that these don’t work in IE rather than saying that these work only in Safari, Firefox and Chrome! Great advice!

Hopefully what we have done so far provides the foundation necessary to build an app so that the creativity of the application requestor and the programmer can be spent on building more and more useful consistent applications quickly.