Project Timeline

The timeline for deploying the proposed webservice would be somewhat tight. Here it is presented in two-week blocks:

Considering the large variety of persistence methods, and . In total, a minimum of four or five technologies would be required for this. A framework language, front-end language, database, and hosting provider would all be required, not to mention pre-made services for actually hosting and serving each of the components. Week one would be dedicated to selecting these technologies, and building proofs of concept for varied parts of the final application, to ensure that the selected technology is workable, and would fit the task. The following technologies would be suited in some way or another for each of these areas:

• Framework
• Java, Spring framework
• C#, ASP.Net
• Front-end
• Javascript
• Actionscript (Adobe flash)
• Database
• MySQL
• MongoDB
• Hosting
• AWS
• Google App Engine

After appropriate technologies are selected, the remainder of the next week would go into planning, structured around architecture and team roles. After this, initial structure framework (Read: Testing and interface writing) would finish week 2.

The next two weeks would be devoted to creating an initial marketing/display page, integrating the database technology, and creating accounts on that database.

Weeks 5 and 6 begin the development on the customizeable ruleset engine, and rendering on the front-end site. Considerations towards how a user would interact with the creation of rulesets would occur here, and making the framework easy enough for a lay-person to use, but general enough to create a huge variety of rulesets would be first and foremost.

The next major milestone occurs at week 9, with the deployment of a partially functional alpha version. One ruleset would be completed by this time, and any users that had signed up for the site would be able to log in and use it, with the ability to submit problems they may encounter on the site itself. Along with handling some of these bug reports, development would continue on exposing the ruleset creation to the user.

At week 11, the ruleset creation feature would be exposed to the user, along with another sample ruleset. At this point, most of the development effort would be pointed to bug reports, with some minor planning on what next to implement and how, if anything.

By week 12, a working webservice would be hosted online, and the project would be open-sourced. The ability to purchase additional features and subscribe would become available, and continued development would be community-directed.

Project proposal -- Initial

My proposal is creating a webservice that allows users to access online, interactive map-spaces.

In business and varied other activities, one of the primary things that nearly every single person needs to do is collaborate with others in some fashion. Considering a large number of collaborative spaces, including both online and offline, there are a variety of shortcomings in each. Offline collaborative space, such as offices, meeting rooms, parents' basements, are not always accessible to everyone, and often involve effort, time, and money to prepare, and assure that all participants can be present. Online collaborative spaces, which can be accessible to everyone, often have the problem that they mimic the wild west, with contributors edging out or overpowering their peers, to everyone creating an unclear jumble of chat logs that takes considerable time to work through and, in some cases, decipher into readable language. Additionally, that spaces tend to be extremely limited as far as expressing complicated ideas in the form of diagrams, pictures, etc., requiring any coordinators to meld usable, physical space with online space, using physical whiteboards or presentation material separate from the primary meeting space.

My goal with this project is to merge the best aspects of both offline and online interactive spaces, in creating an extensible, usable, online meeting space in which project coordinators can "do it all," from managing participants, to defining rules in which those participants can interact with each other, and the coordinator(s). From creating an empty meeting space to quickly communicate, to a single-dimensional schedule, to multi-dimensional designing, for work or play, to balancing input from participants.

The primary maintenance for this project would be paying for web hosting, and continued support would come from a combination of places. First and foremost, features beyond the basic set for the map-space would have two different models: a monthly subscription, or a feature-by-feature one-time purchase. The revenues from those purchases would be put directly into server costs, rather than pulled out, to attempt to prolong the existence of the site. Additionally, the project would be open-sourced after some base service amount was met, allowing communal bug fixes and feature additions, as well as secondary site-hostings, with the provision that any use of the software could not be used for any sort of profit generation (excluding, of course, the original site) without explicit written permission.

As creating a functional, completely working set of services would be a much longer term project, this proposal primarily concerns creating the framework for a map-space webservice, along with at least two sample rulesets. I would suggest that these sample rulesets model drastically different areas, with one in the realm of business or meetings, and the other in the realm of gaming.

Software Engineering -- Intro

The wikipedia article on software engineering presents a number of almost contradictory views on software engineering, which is understandable as is a relatively new (Read: Younger than 3 decades) discipline.
In many ways, I'd have to most agree with the Dijkstra quote on the page; that software engineering is "How to program if you cannot," with one caveat: The ability to program or not doesn't always accurately measure value on a team of developers creating software. One of the best examples of this, and completely unrelated to actual Software creation, is the salesperson. While they're almost completely divorced from the software itself, without being able to market and/or sell a piece of software, almost no companies or groups of developers would be successful in generating interest for the software they've worked to create.

An interesting comparison with other engineering disciplines is the ability to measure resource use and value creation. Many of the Agile paradigms recognize this, claiming time and planning for that time to be the most important commodity, and structure themselves around being unable to successfully t=plan much longer periods of time. In actual practice, though, traditional business models seem to favor non-Agile models precisely for that reason, sometimes causing a split between developers and the company they immediately interact with.