When you set up a web application, often you will start small with everything running on one server. Everything, in this case, typically means the application and the database and data files. That is nice and simple. It has the advantage that everything it fast because it is all one the one server.
The capacity is, however, limited. Suppose the load on your application increases. You can get some way just by upgrading the one server, adding more memory and faster processors, but that will only get you so far.
Eventually, you will have to scale out. You will get a number of separate web servers, with a load-balancer to distribute the incoming requests between them. All the web servers will connect to a shared database sever, or cluster of database servers. The files will probably go on a separate file server.
While this increases the total load that the whole system can support, it means, paradoxically, that processing a single request is slower. For example, if you switch from one server to three servers (application server, database and files) your site will not support three times as many users. The scalability will not be linear. That is because every connection to the database or to get a file now has to travel over the network. Accessing something across a network tends to be an order of magnitude slower than accessing something on the same server.
The above is all standard knowledge about scaling web applications. I have been thinking about about it recently because it explains the way my working life has been evolving. Just over six months ago I was working essentially on my own, re-developing the Moodle question engine. I had been working away like that for a year, and I had got a lot done.
Since then, things have changed, and I am now managing a team including three other developers, and two out-sourced development contracts. It has been particularly 'bad' this last couple of weeks as one development period of the project came to an end and I had to review a lot of code, and then I had to sort out everything we were supposed to be doing for the next three months. I am starting to wonder if I will every get any of my own development work done at all!
That is, however, just some exasperation showing. I know really that this has just been a brief spell with an excessive amount of administration. Overall I am happy that the OU is investing so much in its eAssessment systems (and the other parts of its VLE); as a team we are achieving more than I could on my own; but right now my inner geek would really like to go and hide in a cave for a while and just write code undisturbed.
Been there myself tim. Great post. One thing that can help a bit is seeing this as both a learning and teaching opportunity.
ReplyDeleteI say that both because we work for a university but also because we're both passionate about learning and teaching.
A large part of managing a team is, in my view, about ensuring every one can read your mind. They need to read your mind because they need to know the kind of code you like and don't like. The way you prefer problems to be solved and the way you like to work.
Since we don't yet know how to read minds we could do with the next best thing. Examples of what you do and don't like. I say examples because it doesn't always have to be documentation per se but something that's going to teach us what you like.
So it helps if you teach us over time what you want. What do you want your team to stand for and produce. What are your standards. Help us understand that.
At the same time learning about us as a team. Helping us teach you about our strengths and weaknesses. That's going to help us support each other as a team.
You are already doing a lot of this so well done. Just thought this angle might interest you.
I feel uncomfortable with paragraphs two to five of your comment, which seem to lay too much emphasis on 'me', 'my standards', 'what I want'.
ReplyDeleteI hope that instead we can phrase it as: what tools the Open University (and Moodle users more generally) want to teach and learn with. On the more technical level, it is what sort of code we want to sign our names to, support and enhance in the future, or to bequeath to the developers who follow us.
I absolutely agree with your reference to teaching and learning. That is a great way to think about any team, but particularly in a university. However, I would like to think about it with reference to 'Martin's Five Laws' (as Jason Cole christened them).
Of those, I think we are currently falling down on number 3: "We learn a lot by just observing the activity of our peers". At the moment, I am the one doing all the code review, and therefore learning the most from my peers, even though I am probably the most experienced member of the team. That is something to think about.
Just a note that my colleague Jenny wrote a related post.
ReplyDelete