Who You Calling A Jesse?

Illya posted some thoughts on Agile Release & Testing Procedures and instead of writing a big long comment I figured it was worth a blog post. At the University of Waterloo I have had experience deploying a number of different applications for a variety of audiences… it is next to impossible to get all the details in a post but here is the general truth: there are no enforced institutional wide procedures for web applications. You might think the lack of procedures is bad but it is a result of the relatively low risk environment (even though the campus community has a low tolerance for bugs and changes). There are rarely formal teams of developers, it is mostly the loan coder building a specialty application – enforced procedures would frustrate them.

When you are dealing with a simple web page, say the uni home page, I have essentially covered the typical user acceptance, performance, and stress tests when the page goes live. I go through the gamut of web browser testing, try some OS variations out, and then get it out there. There is a relatively low risk here as the users don’t interact with a database or a whole heck of a lot client side. Once rendering issues are dealt with, it is pretty much unlikely to have other issues. This is with 30 000 or more people seeing it within a short period of time too. I had relative success but I think it was more luck and the fact we kept web pages simple.

Stepping up the development a bit, throw in a Ruby on Rails or PHP application. My testing procedures involved pretty much the same as the web page testing: poke away at it, fix bugs as they appear, and get it ready to go off of the development server to production. We (co-op student and I) never really sat on changes very long. The thinking was that if it went bad on the production end we just roll back the version, fast. When I made the jump to Ruby on Rails development with Capistrano and SVN that became so easy it was scary. On many occasions we had new versions going up two or three times a day. Minor changes, but they add up. This meant a lot of bugs made it out to the community version but as a whole the community appreciated seeing the progress. Our harshest critics were few and usually the type of people that would sit on things until they are perfect, the web is never perfect.

Now I find myself in the .NET/C# development world. I am happily hacking away at the JavaScript on the front end but I still live in the development environment. Here we have a solid team, a lot of developers, some serious tools, and totally different requirements from the client relationship/expectations end. At the moment we are doing limited testing that makes sure it works and then pushing it to an environment that a group has a ‘sanity check’ and gives us feedback. Releases are going out on a weekly build routine with a daily routine for an internal release. The whole process is evolving as we go but in a very general sense we are aiming to maintain a weekly build schedule for one set of users, daily internally. Our goal is to not leave the application in a non-working state and at any time the build could go live. This habit takes time to develop though… I don’t expect us to be in the groove until over the summer.

That is the nutshell version of what I have had experience with, I suppose it is Agile without the buzz terms. Personally I don’t see a reason why any web application couldn’t work on a daily build process. If you break the big change down to a lot of little changes you reduce the risk of breaking it and you ensure stability (so the theory goes). The problem is that in order to break a big thing down to a bunch of little things you need to take the time to talk it out, plan it out, and scope out what goes into a big thing. It is a way of thinking and it doesn’t happen overnight, most people need experience thinking that way.

I am interested to know what other higher education folks are doing with release and testing procedures.

This Saturday is BarCampWaterloo (number 6!) from 1pm to around 7pm (we may retire to the pub before that) at the Accelerator Centre. A much more toned down event compared to StartupCampWaterloo, BarCampWaterloo is where people come to explore ideas and maybe get themselves ready for a DemoCampGuelph (which happens to be April 9th at the Albion in Guelph). I might show some of the stuff I have been working on this weekend ;)

DesignCampWaterloo is March 26th (Wednesday)27th (Thursday) starting at 4:30pm in the Tathum Centre on the University of Waterloo campus. The first one was a bit difficult to follow being in the SLC and all so I am really looking forward to it in the TC. Plus I just have to go up two floors from my office to attend!

There is also a RailsNite next week on Monday at Ceaser Martini’s. Not sure of the start time but I think 7ish might work.

Update: RailsNite does start at 7pm and there is a Facebook event created for it.

Another update: Rick Segal is not coming to Waterloo for his VC roundtable, but he is coming to Guelph on April 28th… Perhaps Ali is influencing people now.

Yet another update: DesignCampWaterloo is Thursday not Wednesday.

You work on something for a couple weeks and then the due date comes close. There is a realization that you won’t meet the milestone unless you get a lot of code written today and deal with whatever UI issues and browser bugs you can. You order in some pizza, fill up on caffeine, and push through a 16 hour or more work day. There is something about that role you get on when you don’t leave your computer, things just make more sense.

My GUI team of co-op students have been pushing themselves this past week and this evening I think they achieved more tonight than all of last week. People will have to wait until May 1st to see it but our internal deadline is much earlier (demos to some stakeholders first and we need April to bug hunt). Maybe I will demo a bit at DemoCampGuelph in April or BarCampWaterloo ;)

Just wanted to post a just over mid-term thanks to Daniel, Shawn, Allen, and Michael for the commitment. They have gone from CS or Engineering students to fairly good AJAX developers in a very short time period. They have made some cool stuff, can’t wait to show it off.

It is interview time here at Waterloo. It happens once every four months, thousands of students and employers enter a dating game for talent and experience. Waterloo is a bit unique having a building dedicated to the process (just happens to be where my office is) and a frequency of three times a year for the process to run. Large companies like Google, RIM and Microsoft are hear hiring large numbers of students but so are local startups like AideRSS and Semacode along with all sorts of companies from different fields and different sizes. Posters on the walls with all the different information sessions show all the opportunities for students.

Why do the companies come here? Waterloo has the talent and I would argue there is far more and better talent than Stanford (update: Larry disagrees or does he?). Our students go to the Valley or Seattle or Boston or Ottawa and all points in-between to work for big names and get started on their carriers while they are working on their undergrad (or grad) degrees. A lot them stay local (Google and RIM are in Waterloo, along with a lot of other interesting employers) and even more would like to stay local for a term or two if a great job can be found.

For local web/tech startups this is a great opportunity. If you developing an idea and you need someone that can code and wants to contribute, for around 10K you can get a junior student for four months to do that. Senior students are more but you get higher quality and more experience. Just to prove a startup concept though, a junior co-op student is inexpensive and hugely beneficial.

The project I am working on depends on the quality of Waterloo Co-ops. We are building a new system to run the job/dating game and have a great bunch of students to do that. They code, they ask questions, they learn, they are excited, and they build really cool things from your ideas. Over the years I have worked with a number of different students and all of them made me look good—which is what you want when you hire someone, right? ;)

There is a side benefit to local startups hiring students I think as well. If you keep the students here, keep them engaged, and get them excited about trying out their ideas you help the local community build resources. I think it’s one part of the puzzle that may help Waterloo’s stealthy startup scene become even more open and exciting.

If you are wondering how to hire a co-op, contact CECS and they will have you set up in no time.

My ‘other job’ at the moment is President of the University of Waterloo Staff Association which represents 1800 or so staff and today I initiated the public part of a process with our members that I believe will make the organization relevant, effective, and very unique. The UWSA is not a union nor does it conduct itself much like a union. People choose to be members of the organization and pay a relatively low flat fee, we don’t do collective bargaining, and we don’t resort to arbitration.

Instead we work with the University Administration to ensure staff have a voice on policies that directly effect them as keep on top of issues like working conditions, pensions and benefits. We also assist staff in navigating those policies, understanding their pensions and benefits, and answer any questions they may have about their employer. Just recently the UWSA finished re-writing the dispute resolution policy making it more ‘usable’ and effective for both staff and administration. Major changes were presented today.

This work along with the expectations of the staff for a level of service have made it nearly impossible to function effectively with the limited resources we have (we collect $5 a month from members currently). I introduced today a strategy that would have a new constitution for the organization approved by members no later than early Feb 2008, a new full-time position of Executive Manager created, and a small increase in resources through a staggered increase in fees in the near future with a an eye on a very large reserve of resources in the future. If you would like some detail, the slides are available in a PDF.

The idea isn’t to be a union but to be a more service oriented organization that has the ability to make some serious moves to assist members if it needs to. With more resources comes the ability to offer services such as (no way near exhaustive list here): interest free loans for education and training outside of UW, daycare subsidies, larger and more student awards for members children, awards for members children not attending UW, heavier discounted tickets for things, build a community presence, etc. This list needs to be expanded and other ideas need to be considered as yet.

With the lack of UWSA blog and/or forum I invite staff to comment here. Yes the comments are moderated (keeps SPAM away) but I will strive to post all comments on the topic. Ideas and feedback are welcome.