For now, this working name for this project will be referred to as the MMDB ALM, until I can think of a better name, which may be never. ALM stands for “Application Lifecycle Management”, which is what we’re building. MMDB refers to MMDB Solutions, who will own the source code to this application, under some sort of open source license to be determined later.
So what are we going to build? I touched on this a little bit in the last post, but here’s the general overview:
This application will be made of a series of integrated yet independent components:
- Project Planning
- Work Item Tracking
- Customer Response
I like bullet lists. Here are some high-level requirements for this application:
- Integration: These components will all be integrated into a single aggregated data source. This does not necessarily mean a single physical database, but all of the data must be able to be tied together and traced through easily.
- Independence: These components can behave as silos, so that any one component can stand on its own.
- Portability: These components will all have integrated points to existing systems, so that any part could be replaced with another third party system.
- Performance: The performance must be sufficient. Notice I didn’t say “as fast as possible”, just sufficient to meet the expected load of the system, as demonstrated by load test. If there is to be a tradeoff between code elegance and performance, the integrity and readability of code will always win over performance unless there is documented evidence that the performance change will resolve an existing issue.
- Usability: The system must be easy to use. No end-user reference documents will be provided, for several reasons. First, I hate writing them. Second, nobody reads the damn things. Third, they are perpetually out of date. Lastly, and most importantly, they are a crutch to avoid creating usable software. The mark of a truly usable system is that any person can start using it with no training and it never occurs to them to ask any questions. It sounds like a lofty goal, and it’s really hard to do well, but it is definitely doable, and it’s a lot better than writing documentation.
- Quality: All code will be run through automated tests, but not necessarily the type of unit testing you may be used to. A common approach is to create a series of unit tests for every little method in every little component, which I find to be a poor investment of time, and gives a false sense of security because it doesn’t account for the variations you get when you string components together. Instead, we will focus scripting out full end-to-end tests from the front-end UI (using WatiN or something similar), basically automating the QA regression process. I feel that this approach gives you a better return on your time by providing more useful tests in less time.
- Configurability: Administrators will be able to define their own rules for workflows, authorization, user defined fields, etc. I don’t want to create a system so configurable that it’s useless, but every company has different needs, so many of the most common rules will be configurable. For example, a company may want to say that anyone can enter a bug; but then it gets assigned to the development manager; who then can assign it to a developer, who must enter a fix description, number of hours, and version number to mark it ready for testing; etc. However, it should be noted that usability will always win over configurability.
This is a first pass, and we’ll add more as we go. You’ll notice that this approach will age this document, so that it will eventually be very out of date. That is intentional, as this is one of the problems we’re trying to solve. Yes, I know right now many of you are screaming “that’s what a wiki is for!”, but that’s just too free-form for what we’re trying to do. I’m reminded of those label-maker commercials that imply they will make your life will be more organized, but you still get stuck doing the same damn organization, it just looks a little prettier. I want to have an application to gently guide the users towards an organized solution, doing just enough to make it easy for them to do their job well, but not enough to shackle them into a subjectively awkward process.
Anyhow, we’ll get into these bullet points a little more in the next few posts.