I feel like it might be a good time to step back. This blog has existed for only a few years (going on 4), but it really has been enough time to see quite a bit change in the world of the internet. I maybe a dev in general, but I think a PM perspective is valuable especially from this perspective
I am by no means an expert on many topics including the ones I want to look at. I do argue that to be a feature in the regard that most of the world is not experts. Because of that, I can present a user’s perspective to a lot of topics.
I have wanted to see a wonderful and accessible web for a long time. From the client side, we have achieved that to a great degree. Browsers are actually overall acceptable products. I will not call them perfect by any means, but I do not think that a large concern of the web needs to be focused on the client. Instead I want to focus on the server side.
There are three major aspects to any application that are not foreign to the web: setup/development, usability, and maintainability. Now I usually play the role of developer on projects, but I am by no means foreign to the Project Manager role or big picture. For this post, we are going to stay with the big picture. To be very clear, we are going to start by defining each of the terms rather specifically:
- Setup/development
- Though these seem like two steps, they reference the same goal: what it takes to get the software running on the server. Setup here is referring to deploying premade software. These can differ greatly with a “from scratch” environment and something that exists. Development on the other hand references both man-hours needed to get the software created as well as the time based around the learning curve. This can differ for people of different backgrounds and should be approached from different perspectives.
- Usability
- From the web application’s stand point, there are two ways this must be usable: can the administrator easily achieve whatever task he wants (such as generating content) and can the users easily access and consume the results (such as reading the content). We are strictly looking at the amount of work needed for the day to day use of the product
- Maintainability
- Even when shipped, software is never really done. The web knows this to a great extent with regards to security. This also comes up with support from underlying technologies. For instance, does the software no longer work with future versions of the language interpreter/compiler? If so, now old software must be kept or new software needs to be located. This looks at from a required interactivity level, what needs to happen to keep the software in a safe and usable state.
I unfortunately have not tried everything I want to talk about. If at any time I misspeak or you have a different opinion, please bring it up. I would like more of a complete discussion than just my views. That said, I am going to generally only look at ASP.NET, PHP, Ruby, and Python and some applications and frameworks on those when talking. There are many more technologies that exist and I am happy to look into more if there is a compelling reason. For this post, however, we are going to stay above a lot of technological specifics and just look from a manager’s perspective.
0. Hosted solutions
The following discussion does not really apply to solutions hosted by others. This is because setup and maintenance is removed. Usability is important and out of box value is crucial. For hosted solutions, only configuring during start up and usability apply. It is assumed that the hosting provider will take care of the rest (which is a feature when what is provided is good enough, but tends to add cost as well as limits use besides sometimes causing legal problems for organizations).
1. To begin
All products need to get onto the server somehow before anything can really happen. This seems like a good place to start.
a) Set up
A very common situation is where some product is desired that already exists (mostly or completely). Even sometimes glorious ideas are really just different ways of expressing known problems. Some of the most common desires on the web are blogging, wikis, content management, and project/bug management. These flavors of problems can actually exist in many ways. For instance, a blog is very applicable if a small company has generally one source of news and some static pages or some site posting news. Wikis work well when trying to have collaborative document generation or simply a system for developing documents. Content management systems work for more general case web sites that tend to want to fill multiple roles at one time such as file/media management, forums, articles, and possibly more. The last category is generally set up for those working on projects (this includes non-technical ones) and/or developing software. There is many more categories of software available, but from the set up perspective, they all act about the same.
Finding appropriate software for a specific goal frequently is not trivial. This comes from the abundance of software that exists as well as constraints for the software itself (such as needed features, language/system requirements, etc.). The worst part is seeking a decent amount of features that are available with work from multiple sources. Generally, the concept that time is money is the best thing that I can suggest. When trying to start looking for software, try to limit the field as much as possible first. Less choices for whatever reason will allow you to either pick a product or choose to develop your own much faster than trying several.
Assuming software has been selected, installation actually occur starting with prerequisites. Package managers and installers really make this part easy is most cases. Installing databases, apache modules, and various other components frequently can be taken care of by either some other system or is described in the installation documents making this step the most predictable in general.
The final step of set up of premade software is configuration. This is frequently where many problems will occur and time will be lost. A concept briefly mentioned in point 0 is out of box value which is very important here. Products have a certain number of features contained in the default install. These features and the quality they provide can be described as the out of box value as no additional software was needed to achieve it. For many large projects though, there exist add-ons and plugins that will provide even more features. Sometimes that is the only way to actually get a desired feature. These frequently become a consideration for long term use though. This stems from compatibility between plugins and the main software versions as well as any required changed needed to make the plugins work. Many can simply be moved to the server and enabled through an administrative interface. Others may actually involve hacking part of the code of the product. The latter is much more prone to error and problems though the former is not without them either. Speaking from experience, something like WordPress (which runs this blog) allows plugins to attach to methods. These methods may be called all the time and could render the entire product unavailable until it is reinstalled or the database is manually edited to revert changes (which is how I fixed one problem with plugins). To truly get a system working the way that is desired, a lot of time is likely to be invested in configuration.
b. Development
Again, we are approaching this from a PM’s perspective for now. Actually creating software from scratch is time consuming and costly in a lot of regards. That said, you get full control over what is created and can therefore get the maximum out of a system. You also can basically remove configuration as everything will be built to fit the situation.
The entire cycle has to start out in the planning stage. The actual objective needs to be defined along with constraints. Due to a lot of organization’s limitations, outside code might be somewhat limited (based on licenses amongst other potential problems). The amount of available outside help (speaking of code, not contractors) as well as time constraints can change a project from following the best or latest means to being something more within the developer’s skills. If at all possible though, the best tools for the job should always be chosen. We will look at this from the developer perspective in the next post where we actually try to find the best tools for the job.
Effective development will need to have the actual code-writing section overlapped with a testing section. If large enough, people could be tasked with strictly testing the code and setting up automated tests for more thorough coverage. The web is an interesting beast in that 100% code coverage is almost required by tests because the potential user base can easily find all the errors that were missed in development. Also, a bug released to the internet could give arbitrary outsiders access to central points of data that are very critical. As such, a good testing phase is very necessary. Also, documentation should be written for all of the code. For this code to live on past it’s current developer, how it was made absolutely must exist (and be written in more of a “what this does abstractly” rather than a “what this code exactly does” sort of way; this will also keep documentation valid for longer even when the code changes).
I am extremely well aware that how to do all of the above is very abstract, but I think it is all better addressed from a developer’s perspective. From the manager’s stand point, development may give you a better product for your needs, but it is very costly to do right.
[Due to the fact that this post is probably over 1700 words, the rest of this is posted in part 2 of this series. The developers perspective on actual development comes after that and soon!]