Three words

The three words I would like to see describe any development group I'm involved in:

    Reliable, approachable, competent

And the first three runners-up:

    Thoughtful, Socratic, opinionated

The first three words, in that order, really seem to describe whether a group ends up being tolerable. In many ways, the words apply slightly different to individual people, with only two out of three adjectives allowing me to like whichever person is in question. In a group or work setting, reliability is a must, since the rest of the group is often depending on each individual to provide some portion of a project. Approachability is a trait that often is lacking in developers, but makes a huge difference as to whether a project succeeds or fails. An unapproachable, but genius programmer writes wonderful and useful code, but doesn't help the rest of the group understand it, while a somewhat less able programmer that can help explain code to others makes a bigger difference in the project's success, and overarching design. In the past, I've had a few unapproachable developers who worked as team leads, and a considerable amount of unhappiness and frustration occurred for no real reason, drawing away from the project, and . Finally, competency matters, and is important. A competent programmer adds a considerable amount to a project, can figure out their own problems without pulling others away from their work, and understands the need for a good process to be in place, as well as adheres to good process themselves.

The runners-up still play into the first words somewhat. In particular, thoughtful in this context means justifying what a person is saying or expressing. Too often, I've been in a situation in which things like code reviews are failed or adjusted downwards for no explanation other than, "I wouldn't have done it this way," or some combination of buzz words such as, "The solution is too academic. Here in the real world..." Thoughtfulness and describing what, exactly, is wrong, as well as asking for justification of how code is written goes a long way into making a group work more effectively together. On the other hand, a successful group member should be Socratic, asking a variety of questions about how the project is, and should be working, and being somewhat critical of others' work as well as his own. While this has to be balanced with approachability, without any questioning at all, a project is doomed to go on for months with a poorly designed, yet critical, module or two, often causing a huge amount of pain and panic in later stages. Finally, a developer should be opinionated, to a point. While this seems like a bad trait, if a variety of people in the group are opinionated in different directions, it often shows that they approach the same problem differently, which is tremendously good for the health of a project.

Project Review: Khabbab

The review for Khabbab's project proposal is posted here, for a mobile/web based combination that allows employees to clock in or out of work with their mobile devices.

The idea's an intriguing and challenging one, and could certainly find a decent-sized market.

Project proposal - Final draft

After struggling to get an externally available link:
https://www.dropbox.com/s/9wwp29lxwydh25l/CloudConferenceBoard.pdf

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.