Underpromise, but overdeliver

Yesterday we gave the final demo of our two-semester professional workforce development project. It did not go well. We had fifty minutes to present, but our demo only took about five. One of the professors, who had been receptive of our pitch last semester, was very disappointed. We basically failed to deliver. I was defensive, and tried not to make excuses cause she was totally correct.

During the last few weeks of this semester, we were more focused on what was right in front of us than on the big picture that we had promised last semester. And by that I mean technical issues. As system architect I was more focused on getting the architectural components up and running than I was on whatever particular use case this person was expecting to see. So in that sense, yes, we failed.

There were a number of roadblocks that we had to overcome. Our team was made up of six members, two of which were complete dead weight. Another member had issues with her local development machine and was unable to contribute directly to the source code. This was fine, as this was a writing intensive course and there were several written deliverables, including specifications and testing plans. So we basically split the work: I lead the technical development and contributed to the written work as needed, but pretty much left management of the final written work to others on the team.

We relied heavily on Cookiecutter Django for our base deployment. In the long run, this was probably the way to go versus using vanilla Django, or another framework like Flask, but it hurt us in the short term. No one on the team besides myself was familiar with it, although I don’t think we could have avoided that with another solution. We wound up spending an inordinate amount of time trying to get the others on the team up to speed on deploying it via Docker and managing that through various IDEs. I spent a lot of time mentoring the two teammates who were assisting with actual code commits. And it had been so long since I had worked on Django that I had to relearn its model-view-template architecture all over again.

And this is where using Cookiecutter really slowed us down. The package implements several best practices on top of Django: overriding the default user model, implementing updated authentication forms, even deploying a Traefik load balancer on top of the production web server. All of these slowed us down.

In all, we spent less than forty five days doing actual development work on the project. That was following more than thirty days trying to get the framework up and running between local and production environments. The semester was actually focused more on the written deliverables and put off actual development work till the last half of the semester. In retrospect, holding to this schedule was a mistake, and it was probably a bit of hubris on my part not to start work a bit earlier.

We got an email from our instructor this morning:

“From a development (i.e., architecture, tool, collaboration, and project) standpoint your team has met all the requirements for the course. While your demo was less “interface oriented” than the other groups the evaluators referenced, the foundation of your prototype is more substantial. It was clear to me that there was a bias during the evaluation based on discussions that occurred […] last semester. Keep in mind that I have been equally critical of groups in the past (albeit in a less heavy-handed fashion). Your group as a whole should not worry about failing the course.”

So maybe I’ve been a little hard on myself, but I think it more likely that they were as much invested in our project as we were. Obviously there’s some University politics at play there.

So the question is, what comes next? We had hoped to pursue a grant to continue working on this project on behalf of the university post-graduation, but given the tepid response from the skeptical evaluator, I don’t see that as forthcoming without many additional changes. I’ve broached the subject with my other teammates, and I’m not sure there’s any desire to continue forward with that. Maybe after the semester is over. I still have two more classes to complete, and others have a full case load. At least one of them has taken a job, so it may just come down to me and one other person.

All in all, I know the experience was a positive one for me. I know that learning GitLab, Docker and Django for app deployment will come in handy in future projects. And we’ll just have to see if any of the relationships with the team members will last past this semester. Any decision about the future of our project will be on hold for now.

Leave a Reply

Your email address will not be published. Required fields are marked *