8:00 am – 9:00 pm

• Checked on customer stuff. All is going smoothly.
• Had an epiphany about visibility and contracting in general.
  • There are two types of software projects that succeed with the Government. The first is pure COTS. Think Microsoft Excel. The government buys copies and distributes them. It gets used because it’s widely available, and the user base is already familiar with it.
  • The second type is the full custom application. Someone who’s needs are not met by what’s currently available and has access to funds for the development process can have a team put together and have something built. Often this turns out not to be what they need, and the program dies, but enough programs succeed that the pattern persists.
  • VISIBILITY represents a third way. It works right out of the box like a COTS item, but without the large installed user base to support it like Excel has. Rather, it requires that the team that made it continue to work on it. Otherwise, the team disbands and the project dies. In this third way, the  team adds capabilities to VISIBILITY to get it to provide what most customers need, but because it has to be more general, it can’t be exactly the way that that the customer wants.
  • This means that VISIBILITY, although it still costs a significant amount (let’s say 60% of a full development effort), it’s not as emotionally satisfying for the customer as a full custom application. This implies that unless we find a customer that wants VISIBILITY with very minor changes, we’ll never be able to sell the concept.
  • That being said, VISIBILITY can serve two very useful roles. First, it can demo what we can do for a customer. Second, and more importantly, it can serve as a backstop to prevent FGM from being “low-balled” into providing a custom application for less that it can actually be done for
  • The strategy would essentially be as follows. We are contacted by a customer that wants a custom application. We bid 6 engineers for two years. They counter with 3 engineers for a year. We say that we can’t build a custom app like what they want for that kind of contract, but we can take VISIBILITY and extend it so that it can provide the same capabilities as the custom app, albeit in a less emotionally satisfying way.
  • This gives us a good bargaining position. The floor cost of a full development effort can be maintained because we have VISIBILITY providing the roll of the “low-ball” price point. If the customer is truly strapped for cash, then they can accept the VISIBILITY option. If not, then they can get the application that they want.
• Spent about 2 hours working on the space. Got material and paint for the molding
• Went to the Washington Flex User’s Group (http://www.dc-flex.or) meeting with Dong. Very interesting, Andrew Trice was the speaker. The subject was touch interfaces. About 17 people showed up. Most are developing smaller apps, though a few had dabbled with Maven, no one had been driven to it yet.
  • Check out gesture works, particularly their open source licenced version
  • Flash apparantly has a physics engine
  • These guys – http://www.openplug.com/ – have a compiler that turns flex into native code for a variety of devices
  • And most importantly, it looks like Spark is going to be the basis of Flex moving forward. Spark is a way of defining objects (appearance and behavior) independently of business logic, so that the “skin” of an object can be swapped in and out at runtime. This could be a very nice way of organizing our widgets such as the Advanced query widget Skins can be loaded based on the type of data that they see, instead of examining the data and deciding what component to load. Might even be possible to have some kind of dependency injection, since a skin can be specified using a style.
  • Spark is incomplete though. It will have DataGrid and AdvancedDataGrid as of Flex 4.2. Still, we need to get on this bus, I think.