If you like it, please Retweet it! Thanks!
It's hard to ignore all the positive recommendations surrounding Python / Django and Ruby on Rails. But if you're at an all Microsoft Shop, how do you squeeze some of the newer "hip" technologies in the door? Whether you're the boss or just one of the team, it's a challenge! You have to deal with a potentially huge switching cost, training issues, support of multiple environments, selling your co-workers on the technology decisions, and a multitude of other issues.
Here's a strategy that I stumbled upon quite accidentally. It might not work for all situations, but looks promising so far for me.
1. Define a project that you want to get done. Ideally, it's relatively independent of the rest of your systems. This can be a reasonably complicated new project, as ours is.
2. Create a skunkworks team to work on the project. My team was two talented college freshmen (home for Christmas break) working part time, and myself.
3. Assemble the necessary resources. For us, it was a "server" (a 5-year old laptop), a work room (my basement), a couple of laptops and a network, a lot of Coke or other caffeine products (biased recommendation: ávitàe 45) and the phone number to the local pizza joint. Also, we had on hand several Python books. Total setup time: an hour to clean the basement and run a few cables. Unfortunately I had to "tear down" the environment twice for entertaining over the holidays!
4. Set an unrealistic deadline. Because the team would be quickly disbanding to return to The Ohio State University for their second quarter, this was a very firm deadline in our case. I knew I had their attention between December 17 and January 2 - roughly two weeks which included two holidays (totaling about 100 developer hours, since they were working part time), but no time after that.
5. Be ruthless on defining the objective for that time period. We focused entirely on the basic "guts" of the web application - the Python heavy lifting, and totally ignored certain areas that would get filled in later. We continually strategized by asking "what can we do in two weeks?", and eliminated entire sections that were unrealistic to complete. We had a lot to learn and build in two weeks, having only a little experience in Apache/Linux web serving, Python, and MySql, and no real world experience in Django. Our list looked something like this:
- Get "portable" (laptop) web server running, including Apache, Python, MySql, and mod_python (but not Django).
- Build a single, simple web page that performs the main function of the application: accept user input, store and retrieve data in the database, return a meaningful result to the user. Add individual pages only as time permits.
- Focus on "end-to-end" web interaction for one trained (non-malicious) user, and in the case where everything goes right. Focus on the Python guts of this interaction. Focus on the logic, not the presentation.
- Get a "web server" and simple application up and running in this period.
- Utilize off-the-shelf open source components if they come close to meeting the needs of the project (even if we'll replace or enhance them later).
We avoided spending time on the following elements:
- Graphics design, HTML and CSS (there are companies that do this a lot better than your average college freshmen can).
- Django and Django's strengths: user administration, data models, database crud - record manipulation - Create, Retrieve, Update, Delete. Actually, we handled Create and Retrieve, but only in a minimal sense (knowing that Django would help tremendously here).
- Google App Engine. (Tough call here; GAE offers a lot, and we utilized it and our portable web server for our prototype. But ultimately, we made the decision that it was better to have one less thing to learn, and better to have the server "in hand" for learning purposes. Cloud computing adds extra abstraction and increases the perceived learning curve.)
- Error checking, protection from malicious users, security.
- Reinventing any wheels.
Our mission was, at the end of two weeks, to have a few things that worked, as opposed to twice as much stuff that only half-worked.
6. Spend very little time in the design phase - Just code! This two week effort may end up being the guts of your system, or it may end up being throw-away. Design decisions will become much more clear-cut after the prototype is built. But we never called it a prototype. And this was never considered to be throw-away code - I don't want to insult the developers or minimize their efforts! They do great work, and it was hugely valuable!
7. Prepare a "pitch" to the rest of the team. I knew that upon returning to work on January 5th, I'd have a challenge to transition the skunkworks project into a supportable product. I'd have to pitch it to the rest of the team. My strategy was to sell people on the project one-by-one, since it'd be controversial to bring a bunch of new technologies into the organization. If I "pitched it" to 10 people in a meeting, I figured mob-rule would take over, and they'd conclude that it only makes sense to do this using the technologies that we know - Microsoft technologies.
Since I'd be revealing it to co-workers at various times, trying to bring them on-board one at a time, I thought the best way to do this was a recorded format. I prepared a series of four videos (I called them "shideos", because they were really rough). That way I could explain the system and some of the design ideas in a prepared fashion, and wouldn't need to repeat it over and over as we involved more team members.
The videos / shideos focused entirely on the system, and not any of the potentially controversial technology decisions (Python / Linux).
8. Create a short list of items to complete, to turn the skunkworks project into a real project. Short is key here. The objective is to get other developers on board (the Microsoft guys), and not to overwhelm them. They now have a lot to learn - in addition to the new technologies (Python, Linux, MySQL), they also have to wade through the prototype code to see how the system works. But you don't want it to look so overwhelming that it seems easier to throw it away and start over on a Microsoft platform.
Migrating to new technologies is not all that daunting of a task if you can see it already working!
Our short list looked like:
- Get it up and running on a real server
- Fix this short list of bugs
I almost apologetically presented this list to my coworkers - a team of professional developers. "Here's some code that two college freshmen threw together in a couple of weeks, let's see what we can do with it to make it production-quality."
9. Transfer ownership to the internal team, and continue to advance the project. By now, you should have management approval and even directive to get it done, if the project is worth doing. Acquire any necessary resources (our developers found that materials online were sufficient, but I wouldn't hesitate to buy books to smooth the transition).
We decided to continue to steer away from building things that Django would help us with, as we got the system running in a production-capable environment. Once the development team thoroughly understood the prototype software, and was comfortable making changes in Python, then we'd make the leap to Django. (Obviously it's better to design and build on Django from the start if you can. But our strategy worked pretty well, so that there wasn't one more technology added to the learning curve. Django's benefits are more obvious once you see the "hard way" to create a Python Web Application.)
10. Introduce Django into the environment. We set up Django on our web server, without impacting the running prototype. Then we copied the prototype files into the Django environment, refactoring the code to fit the environment. The cool thing about this approach is that the old prototype never went down, during the migration. We could see how the code was "supposed to work", while we migrated it to the new environment. We made the switch to Django one weekend when no one was looking!
11. Implement Django's strengths: The Model-View-Controller (or Model-Template-View) style, multiple environments (dev / test / production), better data CRUD, user administration, data abstraction, database model versioning, and more. Migrating the small prototype to Django made a lot of sense, because we had something to work with. We weren't staring at a blank slate trying to invent a data model for a new system; we could see one that was working!
There aren't a lot of Django books out there. But you can't go wrong with the book by the authors of Django! We also bought this one because of the discussion of Google App Engine in the appendix (ten pages).
12. Roll it into production. At this point, all the developers who are involved are excited about the project, and seem to appreciate the opportunity to learn something new, without being overwhelmed by the learning curve and unrealistic expectations. The process has improved their capability (and market value), and provided a fresh perspective on how to design great web applications.
We'll still have a legacy of Microsoft technologies for many years to come, but it's refreshing to now have an alternative platform!
If you like it, please Retweet it! Thanks!
