Requirements for our code

Completeness, correctness, unambiguousness, reliability, consistency, and traceability.

Any module should ideally fit in a single page.

If you're copying and pasting code, it's wrong.

How well do we understand system boundaries?

Aesthetics.

Reusable components in our code.

literate programming and the rational unified process

The wikipedia article on literate programming is very well laid out and was a good read. There are a lot of literate programming "languages" out there! I wonder if there is any style that generates test cases as well as code. It may be good and all to interweave thoughts and comments with the code in a natural-language type flow, but I think it would be hard to debug this, given the amount of text you have to search through, and all of the chunks of the same piece of code being scattered about. Maybe you compile it into source code, and then debug it, and then figure out the pieces you debugged and inject them into the original? Sounds a little too hard...

I would like literate programming if we designed a language that could take natural language and produce code, resolving ambiguities in the natural language by waiting until the last moment to evaluate and dynamically type any portion of the program, interpreting the language by the surrounding state at the time of execution. If it still can't be resolved, throw an error and let the user revise their language, or be more specific, or whatever.

Of what is out there right now, I think noweb would be good to learn.

On to RUP:

Developed by IBM, this process is very detailed, and seems interesting to learn. A summary of it is very interesting (about 20 pages). It turns out that it is all about using UML as a way to communicate design, requirements and architectures across teams. A bunch of tools are employed to keep the models up to date and to support bookkeeping.

I definitely see how important an easy tool for bookkeeping would be!

And the IBM 6 best practices for a software development team are:

1) Develop software iteratively -- agile methods I think work just as well here
2) Manage requirements -- they emphasize use cases and scenarios, as in agile!
3) Use component-based architectures -- I think Python is a great example of this in practice; developers of Python have made dozens upon dozens of robust and useful components for the language
4) Visually model software -- this is where UML comes into play. I think we need to use this more.
5) Verify software quality -- Here I think agile is better - test first!
6) Control changes to software -- this is what good version control software is all about, right?

Here's a visual of how they envision the "process":




















I think our team could do better with a vision document and a bigger overall picture of what we want to create.

The rest of the doc goes into details about this process.

class monday

I've been watching the video from Monday's class. My team has done a great job responding to what Joe brought up, based on our conversations in our meeting today.

I am very impressed by what everyone has accomplished, and it makes me committed to work harder this next week to output as much as everyone else is.

long, empty week

Somehow I accomplished nothing over spring break.

Well, I got my job back. Took a drug test. Read a computer science book. Accepted a counteroffer from a bank. Wrote a script for the Independent Sets problem. Wrote some variations on a self-assembler and missile in the Linden language. Spent some time on the next kaggle competition.

What has been delaying me here? Poor time management, I guess. Not focusing on this as my priority. I catch up on what my team is doing, and then I run out of energy. Often not having access to the internet -- I fixed that problem yesterday. I will renew my focus tomorrow.

Asana collaboration tool

http://asana.com/2011/02/asana-demo-vision-talk/

this talk is about a cool new tool. Their goal is to have a product that is as fast as notepad, that updates immediately across the network, that holds all "truth" about a project with multiple ways of distilling and viewing the data, and that keeps all conversations about the project attached to the actual tasks in the project.

I like how it is very notepad-like in updating and changing things. Every task has a chat attached to it, where people can "follow" the task and be emailed when a note about it updates. Responding to the email also updates the task chat, like in google groups. It is easy to move assignments around to people. When a task is finished, all the followers are notified.

Very social-appified, which makes sense because they came from Google then Facebook.

This tool could really help us with our team meetings and coordination, much better than Google sites. It looks like they also built in ways to collaborate your software and components with other developers, so you can use your social networking to get tools, information and help you need to progress as a company. Their goal is to have "business to business virality".

They also developed an in-house web app programming language to speed the design and deployment of that kind of software, called "lunascript".

I applied to see if our team can beta-test their product.

high-level stuff we need figured out

-- Design patterns

-- Coding standards

-- Commit patterns and how to stick to our process

Evaluation of Ekaterina Davydenko's proposal

Dynamic Traffic Control System

Total evaluation criteria score: 25 / 40

Actually, not bad compared to a lot of proposals. It only misses what many of the other ones also miss.

Part I

As far as I can understand it, the Dynamic Traffic Control System idea consists of building large overhanging and side-of-the-road electronic signs that can be either manually controlled or automatically adjust to road conditions. It wasn't clear in the proposal how much of the system would require continual updating from human personnel, and how much would be able to run on its own.

The system would also be connected to all the traffic lights in a city, have a centralized database (what for, I don't know), and be manipulable by law enforcement, emergency medical vehicles, DOT people, and firefighters.

Part II

One thing I don't get is why this system would be centralized. A decentralized, robust system seems to make a lot more sense to me. Rather than a centralized database, distributed servers that control their own portion of the roads and communicate with each other and whoever logs into them would make more sense.

Syntax score: 5/5

The structure of the proposal is professional, and the spelling and grammar are accurate and appropriate. The writing is, for the most part, clear and sufficiently detailed. It could cover more about how personnel will be trained to use the system and the interfaces they would have to learn and use. The story is consistent and well-structured.

Plausibility: 2/5

The project cannot be completed in 12 weeks. As it stands, full implementation, testing with agent-based models, and deployment (along with the training of relevant personnel) would take a long time. Furthermore, a centralized system for managing traffic conditions would be vulnerable to exploitation and reliability issues. Also, what happens when different bureaus decide to give opposing directions for the same chunk of road? Whose decision becomes final? Would a city really consent to such a project? It will need a lot more explanation and convincing data on other such systems.

If a decentralized system were chosen instead, how would it do better than other systems already in place, in terms of manageability, cost, and projected savings in time and money for consumers, and lives for medical personnel (and when it comes to traffic accidents, etc).

Support: 2/5

The arguments for the need for such a system are sound, but I find no convincing evidence that yet another costly city road project like this system would really benefit the city. For instance, traffic lights are very complicated to perfect, and the systems already in place have been tested and tweaked to be about as good as they can get. They also are remotely configurable and change with the level of traffic. The new system would likely not do anything to make them any better.

Novelty: 2/5

The idea of managing traffic conditions is not new. The approach offered really doesn't sound worthwhile. Just doing a quick search brought up, for instance, http://www.cttraffic.com/pages/CISV.html, which details the complex devices already employed in traffic control. They use fiber optics, video relays, remote monitors, exclusive relay lines and control software already. All this is very expensive and requires approval and control from various state authorities.

There is a book that covers many details of traffic control that is published by the Department of Transportation: http://ops.fhwa.dot.gov/publications/fhwahop06006/index.htm. It covers controllers, sensors, managing urban and suburban roads, freeways, and integrated systems. It covers communication and information systems, and design, implementation, and management of Traffic Control Systems.

For a history of traffic light management, see http://ops.fhwa.dot.gov/publications/fhwahop06006/chapter_1.htm#1-5 and sections five and six. I also think it would be useful to review Figure 1-3 from that page and try to see how the proposed system would fit in it. Table 1-2 from that page really gives a sense of the broad scope of details that need to be covered within traffic control. It gives the sense that the proposal largely underestimates the scope and difficulty of managing traffic, and overestimates the impact that installing more traffic signs around a city or freeway will have. The ability to post warnings about delays, etc, also already exists in many big cities.

I found some interesting research on decentralized traffic control: http://www.physorg.com/news114355988.html. It actually doesn't seem that useful when you really look at it. Not without even more research and simulation.

Stakeholder Identification: 4/5

"Private companies" are mentioned, but it sounds like the whole idea is intended for the DOT. This is a project that is meant, it sounds like, to be funded by tax payers.

Scope: 5/5

It's pretty clear what was intended. I liked the use of a diagram to show how components were to interconnect.

Profit/Impact: 4/5

The amount to be made from the DOT or other groups was never stated, but the impact on drivers and law enforcement, etc, was made quite clear. If this was to be a privately funded company, selling their services to state and federal governments, there would be a greater need for projected profits. As it stands, the true costs of all the hardware and construction for implementing such a system were never really covered, either. This would, therefore, make a great government project =).

Security/Risk: 1/5

The project proposal didn't really define any risks beyond that a "major concern will be the dependability and ... integration ... requirements of the system".

Some of the major risks I could think of off-hand were as follows:

1) There is danger of traffic warnings being ignored / no mention of social engineering to get the job done. Thus, a lane may be attempted to be opened up through signs flashing to keep it free for emergency vehicles. During rush hour on a busy freeway, without physical barriers, how many people would disregard such a rule? Enough to slow down cops anyway? The same applies for medical personnel. In the event that no one sees any immediate reason to follow a mandate, many likely will break the mandate. It also encourages disaffection with the system, when it tells people to do something but doesn't offer immediate positive results.

2) The securing of the systems is never presented, nor the ability to deal with conflicting orders from different organizations. The way to handle events like server failure isn't mentioned, either.

3) Sensing systems and their management are not mentioned. "Database" doesn't say enough, if that was meant to incorporate data from video feeds, scanners, and human input.