Roles and Infrastructure
So let’s build a virtual software company. That is, a company that creates and sells software. While this kind of effort might be possible to do alone, to make it a bit more interesting it will be designed as a collaborative effort.
One idea of collaboration is to pool resources, and exploit the removal of redundant effort. This will be one motivation of that idea, but the other part will be that of a learning/teaching opportunity. Knowledge transfer if you want to call it that.
So in a highly structured effort which software development is, lets define a few roles, that might be worth considering.
Sets up Servers, installs operatingsystems, configures the routers. Eventually DNS, Firewalls, etc.
However, as cloud services, vservers, etc. are somehow a commodity, I’d prefer to keep these tasks to a minimum or outsource them entierly by using some service.
That role will be neccessery, even if it is decided that the company will use an external service for email. But someone has to add new teammembers, so this role will be admin for Email. The role could include setting up an email server on some virtual machine. Eventually the company will be sending out some kind of newsletter to customers, so somebody needs to take care that mail gets out. If a Newsletter Service is used, that role will include configuring that service.
Additionally, that role will likely include setting up and maintaining test-email accounts at various freemail providers, to make sure that mails go through to them unharmed, if custom email systems are deployed.
That role will essentially do the same thing for web as the mail-master does for email. It will include setting up webspace, provide ftp-accounts, eventually installing and setting up apache, etc. If some kind of external Hosting Provider is used, and that should be done, this role will take care of manning the web hosting control panel.
Eventually the Web Master will also make sure that there is webspace available for having some kind of testing stage, when web application changes are rolled out.
And if the kind of software that the company is providing is web based, then there will be close collaboration with the next role.
Development operations is kind of the glue between web master and programmers. Devops basically provides and maintains tools for programmers. This role will be doing nightly builds, will make sure test suites are run, will make sure git repositories are available. They will be packaging applications, upload them to the file area, etc. They will also install the applications that the programmers create. They will maintain the tools to continously collect code metrics.
They will install development tools on virtual machines, and set up images for build servers.
This role will be doing the actual programming, and that is for web applications. This means both, public facing widgets that are on the web site, signup-forms, databases, cms-tools, crm-tools. The application that is being sold, and internal tools that will support other parts of the business, may it be a company adressbook, wiki, or whatever.
The job of that role is to commit stuff to a git repository. Whatever is being used as development environment is up to the individuals, as long as coding conventions are followed, unit-tests are maintained, etc.
While related, the advent and wide spread adoption of smart phone app markets has probably made it necessary to have some of those as well, so this group will be working on that. Devops will be creating packages and submitting them to app-markets. App-Programmers will submit code and tests to git.
This role will make sure that programmers do not lose focus. Here Application workflows will be created, and layouts will be sketched out, and later refined. This role will probably work closely with programming. Much of this role will also include making sure that the programmers go all the way through and implement clean validations for forms, that everything is pixel perfect and not thrown together.
And finally, don’t get me wrong, every role will be programming, mail-masters, web-masters and devops won’t be doing their tasks by hand, they will be creating scripts and control panels to streamline whatever they find themselves doing. May it be shell-scripting or automating a service via an API.
The idea here is to have some “easier” tasks, that youngsters can get their hands dirty, while creating some automation that will allow them to move up from their roles and graduate into more interesting fields.