July 2008
M T W T F S S
« Jun    
 123456
78910111213
14151617181920
21222324252627
28293031  

Chris Donnan : Programming - Brooklyn Style

software, trading, family, fun

SCBAT, Guidance Automation, Code Generation and Rails

While reading Sam Gentile’s blog today I came across an article regarding the SCBAT (Smart Client Baseline Architecture Toolkit) and GAT (Guidance Automation Toolkit). I was also discussing this stuff this morning with my friend and collegue Marc. In any case - this stuff reminds me of something I had advised doing (and have begun doing) for a current project. It also reminds me of something in Rails.

The essence of all of this stuff:

You have some application patterns, structures and practices. You want to create all the ’stuff’ you need to use the architecture pattern effectively and efficently, with as little confusion as possible.

For example:

In the now famed Rails web development framework - when you want to create a new project, new view/ controller etc, you just issue some command line .. commands.

For example - to create a new application you can issue a command like:

rails path/to/your/new/application

This will create the folders, base files, etc for your new web application: folders for views, controllers, models, etc. You can also use the rails generate command to create new controllers etc. like:

rails script/generate controller SomeController

Now you have the basics of your Rails application.

SCBAT with GAT

Now - looking at the SCBAT - these great fellows are trying to do is to allow you to enter some data - and it will spit out all of the folders, code etc to make a compliant CAB application. This automates away all of the grunt work, it makes it clear what is needed and it provides the guidance needed to use the frameworks. This is what Sam is talking about in his post here. Cool stuff - making it easier for the team to work effectively with the frameworks.

Frameworks/ System architectures for non-trivial applications are complex. It is a fact of programming life. That being said - doing as much ‘Guidance Automation’ as possible sets the team up for success and takes away increasing amounts of potential error.

Prototype Spiked for a current project as Guidance Automation

I will be leaving my current project (a credit derivative trading smart client application) in 6 weeks. I will be going to a new project (FX options trading stuff). As I have been trying to set up the team I am leaving behind up for continued success using the application infrastructure we have developed - I considered making a custom sort of code generator that functions as these other GAT type things/ Rails type things do… it would take the basic data and go create all the classes, events, folders, etc needed to use the framework effectively.

A screenshot of the basic code generator.

Code Generation

In a few hours I was able to create an application that would take in the information about what the View was to do - and to automate the creation of many classes needed. Since we are using a Model/ View/ Presenter pattern where the View communicates with the Controller via events, there is a set of pattern classes that we can simply create if we know what the view/ controller are trying to do. Hopefully before I leave here - I will be able to leave the team with their own custom Guidance Automation type applicatio that will help keep them on track. This was in truth inspired by how rails works. I am looking forward to using CAB, SCBAT and enabling more and more code generation and other types of guidance automation.

-Chris


1st Day at Finetix

Well, today was my 1st day at ‘the new gig’; Finetix. While not too much went on, I will say that it was interesting nonetheless.

One of the main things that attracted me to Finetix is that they seem to basically try to only get technically ‘heavy hitters’. That is exactly the modus operandi that I had for years. It is certainly possible to ‘throw’ 40 mediocre developers at a project - then get 20 or so middle managers, follow-uppers and other ‘helpers’ to make the project close. This is of course unfortunate for many reasons. You get mediocre, hard to maintain software, lots of mediocre documentation and the whole deal is well… mediocre. IF however, you are able to just get the ‘heavy hitters’ to work on your projects, you can reduce the head count needed (you will of course pay more for better developers) and you will get good, maintainable software out of it - with a better chance of getting it delivered in a timely fashion.

Some organizations opt for the former, some the latter. My belief is that you just want to be able to have software that you can maintain, understand and that someone was proud of.It tends to follow that your cream of the crop developers actually care about their work. They take ownership and pride of and in their projects, teams and this is what makes 200% of the difference.

We did have some interesting discussion today about how to present agile methods to your classic CMM level gozillion organization. Many organizations have been doing business as they have for eons - and old habits die hard. Old habits die hard even when the new habit could actually offer compelling bottom line benefits. In any case, it is imperative that tech companies are able to effectively portray the value of agile development mechanisms. The ability to deliver in a measured, more quantifiable way is important and a key selling point in my mind. The ability to manage the overall risk of a project by having frequent deliverables that you can see and touch is also key. It seems that it is just a question of presenting the benefits in a way that is comprehensible to the business at hand.

Anyhow - wife is out of the shower - I am off to real human interaction.

-CD


Last day at PCH

Today is my last day at PCH. I will say that I have learned a bunch here and that I will miss all the people. As a Lead Software Architect at PCH - I have been able to hire lots of great developers to work for me. I have also been able to take on some very challenging projects. I think that in the end - I really did not like commuting to - or living in Long Island. I also can say that I really did like building applications for the web that need to service millions and millions of people. They have 2 web sites in the top 100 - both of which were rewarding and challenging to manage over a  few years. Another facet that I really enjoyed was working on the internal facing desktop applications. We were able to really remodel workflows, business practices and ways of doing business - and it helped the business. I think that the modeling process - understanding the business and modeling it in software is also extremely exciting and something that the team here was able to do amazingly well. Another thing that I am proud of from my time here is how well we developed our process, methodology and standards. We were able to work out what we have referred to as a ‘Scrum Derivative’. We were able to move to a methodology that was agile, yet organized. We could take requirements (user stories, prioritized and scored) and make effective plans that we could deliver on. I love the idea that software teams can get highly tuned and execute repeatably at a high level of complexity…. That whole thing is just great - Live, in Tune, and on Time!

Anyhow - I wish all my former folks the best and I know there are many genuine friends that I will keep in touch with.

So long PCH…


New job….

Wow  ~4.5 years of being with Publishers Clearing House - it has been great.

  • Built 2 top 100 on internet web sites
  • Built 1/2 million LOC SmartClient app.
  • Manage > 1 million LOC of pure C# code over several years.
  • Hired many excellent developers
  • Learned immesurable amounts from my peers, superiors and everone else I saw on the day-to-day

That being said - it was time to change things up for various reasons - so… Now I look forward to starting with Finetix real soon. Wish me luck!

It is hard to take a new position when you are comfortable. It is hard to leave a team you spent years building. It is hard to trade comfort and offers of more comfort for more work, the need to re-prove yourself etc. The bottom line is that, as I have often said “If you are too comfortable - you are not learning”. So - bring on the learnin’


Hiring good developers is hard
I am trying HARD to hire people - and boy is it hard. (been doing it for years and it is still hard)Senior C# Developers in New York - here’s the catch - it is in Long Island - 45 min outside of NYC. MAN is it hard to get good talent out here. We HAVE an amazing group - world class developers, but MAN is it hard to get em’ out here. We have been doing great top 100 web site projects as well as really large smart client application development. It is all SOA based - exciting and great as dev work goes. I interview person after person, we have professional screening of candidates, many people work hard at this process. At the end of the day - when I am discouraged, we sometimes see those great developers - and I remember that they DO exist and I am re-encouraged. But BOY is it hard to get there.

Also hiring; QA Manager, Business Analyst, SQL Server DBA, 5 more C# Devs in early 2006. It is painful - because we are picky. I often get criticized for being too ‘tough’ on candidates, but - frankly - I am not. If people put something on the resume - I WILL ask about it. I find this amazing pattern - and it gives me a theory. Here it is…..

Theory of Most Desired Skills

My primary method of interview is to allow people to give their own context and talk freely. I say something like “So - what do you like to do in programming world? What are you good at doing? What do you think is key? etc.”. I find that SO often what happens is that people start talking about something they know less about than other things. So - my theory is that developers believe that the areas where they are most vulnerable, where they know the least or perceive as the ‘hardest’ - they believe this is what you want them to know. I have seen it so many times, that I just had to rationalize the pattern. I really believe that so many developers perceive the areas where they are weak to be the most important areas and they just lead themselves right into talking about those weak areas. This is of course awful for them. It hangs a large percentage of unqualified candidates.

One of my favorite interview hangs was with a gentleman who insisted that he was using XQuery. The problem was that there were NO implementations of XQuery at that point in time - just a W3C spec. In any case - he fessed up - what a joke!