Monthly Archives: September 2008

The Corporate IT Silver Bullet Illusion

I was reading last night about how corporations get themselves into messes. Each IT generation (5 years) it seems has a silver bullet that’s going to nail down a system and make it easier to maintain enforce standards.

The current silver bullet is SOA (Service Oriented Architecture). But in 5 years what will happen is that all of the problems created by multiple databases and links between systems will overwhelm an IT departments’ ability to maintain and programmers to code. In 5 years they won’t have a single system that’s spaghetti they have multiple systems which are spaghetti complicated by the fact that you have spaghetti linking them.

I have often marveled in that change is rarely incorporated into a Corporate IT strategy. It’s either because it’s too risky/difficult to mange/define or rather than appear uncertain, which is the way it really is, managers will put a line in the sand and say this is the way it is.

So how do you fix it? How do you pick a corporate IT strategy? How do you create a system of technology and people that entropy (state of disorder) does not increase over time? You can’t, well you can’t without doing some fundamental things and spending some additional time managing the change.

  1. Use an agile or similar process that involves technology (architecture/creative/development) and the business.
  2. Use a technology platform that enables development not hinders it. A developer should not have to fight with a technology to do something.
  3. Create and Enforce DRY (Don’t Repeat Yourself) coding practices.
  4. Enforce mandatory testing and code review.
  5. Publish and get business buy-in of the development process, release cycle, and testing review requirements.
  6. Embrace and Invest in DSLs (Domain Specific Languages)

On the technology/language front, many IT managers and directors want to “standardize� on a language or pick a “framework� that will be the best fit for their environment and frankly will not get them fired if they make a bad choice. But we are coming to a point where the underlying language will not matter as DSLs begin to be used on top of traditional languages for most day to day activities and application programming. The benefit of DSLs is they will change little as the language/frameworks become obsolete and they will grow automatically as the business changes.

What is a DSL? A DSL is a Domain Specific Language a programming language specific to a domain of knowledge or business process. You can imagine a stack of programming languages like this:

  • Domain Specific Language (SQL, CSS, make, ant, regular expressions)
  • Dynamic Languages (PHP, Ruby, Python, Groovy, Perl)
  • VM Languages (Java, .Net CLR)
  • Static Languages (C, C++)
  • Assembly

In conclusion there is no Silver Bullet other than embracing the change that will happen, and creating systems, and assets that enable that change.

Linux Webcam Success and A Shop

I have managed to scrap JMF (Java Media Framework) and instead created a roll-my-own JNI web cam capture with C and Java. So far so good, but it only works with a few older web cameras and performance is not optimized.

I also have a new shop. Now I have a place where I can build my robots, have meetings for the Columbus Robotics Society, and run my business.