Crunchberry Project

xkcd Webcomic

One of the challenges in managing the Crunchberry project is understanding what the development team spends everyday working on. It’s a fundamental problem anywhere developers and non-developers work together: programming is looked at as a black box, something people avoid if possible. As a small group students we each fill a variety of roles and this makes it even more important to communicate how development time is spent.

On Friday after our end-of-the week meeting, I took a half hour to explain the basic concepts behind how Web servers and databases work and what frameworks like Django are and what they do. I tried to keep the explanation as simple as possible, explaining key concepts like what a server is, what web and database servers are and how they fit together, what the difference is between a programming language and a software framework.

I won’t take time here to explain these thing when others have done a better job.

My brief tutorial was helpful to the team. People asked questions and generally understood some of the basics of what the development team does.

Django and its Model, View, Template methodology is relatively simple to explain on a high level. For those who are not familiar - this methodology breaks out logically separate parts of a web application. Models represent data in the database, Views handle the request from a visitor, and Templates format and display the data. I showed off my development environment and some code, trying to dispel some of the magic by walking everyone through a trail of code a visitor would experience when using the Web site.

Programming has a high learning curve compared to many things, but as tools get better and people spend more time using computer systems, that barrier to entry gets smaller. The walls that have been built around technology people need to be torn down. Developers should be able to explain themselves with little or no jargon to non-developers and non-developers should show an interest in understanding.

Ask questions. Challenge the developers to explain things plainly. This helps developers to better understand the problem, and non-developers better understand the tools and constraints the developer works with.