So you want a software factory?
A friend recently found a behaviour they weren’t happy with in a piece of software I was involved with writing. In the ensuing discussion, we talked about testing software, and my friend indignantly said “I didn’t have to test my car when I bought it, why should I have to test your software?”.
Aside from the other potential flaws in that argument, the idea of software as something that can be mass-produced, dropping off the end of a production line like a car comes round now and again. I think that drawing this analogy with production lines as it stands is flawed, but by changing perspective slightly we can make it work.
Simply consider software as the factory, not the product.
Now, each release of a software solution can be what it is (at least, based on my reading and my personal experiences); a custom job tuned to maximise the efficiency and quality of producing the real product – the information and functions that the software provides for its users. Every time a button is clicked and does something at least as good as what was expected, a unit of product has rolled off the production line. If something bad happens then that unit of product was defective and we can use that to improve our production line. The users of software don’t generally care about the software, they care about what it does. The software itself is just a platform – the sales, factory and fulfilment departments rolled into one.
The reasons why we can’t mass produce all software easily are perhaps a little easier to see under this analogy. We achieve cheaper and higher volume production as we invest more in the factory. Some parts of the factory – maybe some of the machines, the conveyor belts, the security controls, and so on – can be bought in as off the shelf components, but how we make those components work together efficiently and effectively to achieve our goals is a challenge requiring creativity, invention and innovation. This challenge must be met not just when we build a factory, but also when we change something, potentially upsetting that careful balance of efficiency that was there before.
So back to the original argument. The idea of mass production and production lines saw large scale success in the automobile industry, breaking the big, complex task of creating a car into many small, relatively simple pieces so that identical copies of a given car could be churned out in huge numbers. Mass-producing the design, decomposition, construction, testing and other myriad jobs required to produce a production line may be unrealistic for some time to come.
As always, your views most welcome.
Done with the Background Report
According to this blog, I started work on the background report around the tenth of October last year and today it’s all done, ready to be submitted.
As you might expect, there was a lot of reading involved, and a great deal of writing, re-writing, editing, and all that other good stuff that comes with trying to put together a 25-page document with proper referencing. Since New Year, I’ve also started prepping for the final taught module I’ll be taking which starts in February.
There hasn’t been much time for blogging in amongst all that, so the posts are a even more sparse than usual! The project submission deadline is September, so I hope that life will return to something like normal following that. Until then, I expect things will be a bit pressured!
In: MSc, Project
What scientific literature?
One of the great things about doing an academic qualification through a major institution like the University of Manchester is the access you get to scientific literature.
A huge number of research papers are locked away behind paywalls. Sites like Google Scholar can show you what’s out there, but you’ll only be able to see abstracts for most of it. To get at the good stuff, you’ll be paying tens of poinds Sterling. That doesn’t sound like much, but to do a reasonably rigorous literature search you’d need to access lots of them. I’ve probably read a few dozen papers now that are related to my project, and many that weren’t – which would have been annoying if I’d paid for them individually. I expect there must be ways to pay for bulk access, but there are also many different sources you might need to get that access with too.
It seems like a shame this information needs to be locked away but of course it’s additional revenue for some organisation – hopefully the money goes back into supporting research and researchers.
The breadth and depth of research going on out there on every conceivable topic is astonishing. Getting access to all that stuff is a definite plus.
In: MSc, Project, University of Manchester
First three courswork items submitted
I’ve been wrapping up the first set of coursework assignments for the project today with a quick check over the material before submission.
The next job now is the background report. This document will summarise what I learned during my literature search in the context of my project and needs to be less than twenty pages long (not counting paraphernalia like covers, tables, references and appendices). I’ve prepared a new git repository for the work, but I’ll be hosting a git server on my EC2 instance this time. Whilst having my git repository on Dropbox was convenient and gave me a backup, it wasn’t the easiest thing to clone if I need to pull a copy down for some opportunistic work. The setup was pretty straightforward with gitosis and we’ll see how it pans out.
Best get cracking then!
In: MSc, Project · Tagged with: mscproject
Well, the website is up…
After a week of beavering away with JSP, HTML and CSS, I reckon my project website is about ready.
I was in Manchester on Tuesday, meeting my project supervisor and one of the guys who runs the taught module associated with the project. There don’t seem to be any problems, and it helped to clarify some of the vagueness I referred to previously.
So, the website content needed to include a statement of the project aims and objectives, a summary of the progress to date, the project plan (significantly cut down from the previous detailed exposition) and a summary of the literature search so far – bringing together what I’d already done, about a week’s work so far. I also decided to take a middle road between the simplistic html-in-a-zip approach and an all-singing-all-dancing one. I’m not going to get any more marks for going nuts on this thing, so I just took the aspects that mitigate risks or save time – for example, using a custom tag library to template out the elements that would otherwise need to be duplicated, thus saving time especially when they needed to be changed. I also decided not to compromise on the HTML/CSS separation, again in the interests of making changes to stylistic aspects as simple as possible.
All three elements of the project to date save data in a text-based format: the summary is written in LaTeX; the plan saves an XML document; and the website of course is a structure made up of HTML, CSS and JSP files. This means that all three play nicely with a version control system, and I decided to give Git a whirl at the outset. In a nutshell, I’ve been making small changes, then storing those changes along with messages as part of a ‘commit’ process. These messages can be extracted, providing a kind of timeline of what I’ve been doing for the past few weeks much better than I would have done in my own notes. I can take those timestamped messages and push them into the website during the build process, then use a simple renderer to print them out on the site when certain links are clicked. Seemed like a good way to augment the ‘summary to date’ deliverable.
I’ve also spent a few hours updating and tidying up this blog as I’ve linked appropriate posts into the site as another way of tracking progress and my hosting provider took it down over the weekend, as well as a nasty surprise with my original EC2 instance… maybe good for another post.
In: Machine Learning, MSc, Project · Tagged with: mscproject