Michael Platt's WebLog

Computer Engineering

Blogs

Architectural Skills

  • Comments 9
  • Likes

So if Architecture is a skill that can be taught then can it be lost? I think it can in a very strange way, not through the passage of time but by a radical change in environment. I came to this conclusion after working with a customer in Spain.

 

This customer built event management systems for major sporting events. They had been doing this very successfully for many years on a CICS / Cobol mainframe platform. The team was some 15 very smart Spanish people who had been writing these sorts of applications for 10+ years and really understood how the programs worked and how CICS worked. It was great to work with such clever and bright guys except for one thing; they spoke no English and I spoke no Spanish.

The project was to build a event management system for a major event (actually it was the European football championships) on the Microsoft platform (VB4 and SQL 6.0 running on NT 3.51 at the time.. gulp!). This had to be very highly reliable and support up to 150 operators in 10 locations in 10 cities with ticketing level integrity and performance e.g. less than 1 sec response time (Double gulp). Finally if the system was down then tickets couldn’t be issued and if the software held up the cup final then riots were likely. One of the few systems I have architected which has had “no deaths” in the reliability requirements.

I was to do the architecture and SQL training and a tall and very bright Scot from Glasgow called John was going to do the VB and developer training and so off we went to Barcelona.

First let me say what a wonderful place Barcelona is, beautiful weather, fantastic architecture (the building kind), I even stayed in a Hotel which was designed by Gaudy, dined in the restaurant were Picasso ate when he was young and paid for his bill with sketches which were still on the walls. A truly memorable experience.

Work was also memorable because trying to move the development team to VB from CICS was a challenge. They were used to rigorous flowcharting and modular development with a 4 – 6 month analysis period before starting to program. They were also used to 24x80 green screen alpha input. They spent 3 days looking at a copy of Expedia we had bought in amazement and voluble Spanish. No matter what we did we could not get them to start programming so in the end John just started to write VB and they stood behind him and watched.

It was a sight I don’t think I will easily forget. A tall, skinny Scot pounding out VB code interspersed with swear words surrounded by a group of vigorously puffing Spaniards (they all chain smoked). By the evening you could hardly see through the smoke but could still hear the swearing; I think it was a couple of days before the Spaniards realised that F*** wasn’t a piece of VB syntax!

Suddenly the development team cottoned on. Their Lead said to me (via interpreter) “So you just write code”. I agreed that was pretty much how you wrote VB (and this before agile was even thought of J). I did point out however that they still had to be careful about locking and transactions to vigorous nodding from the team. I later found out that the interpreter may have known Spanish and English he didn’t know anything about computing so what he said that they agreed to I have no idea.

The team dispersed to their workstations, I set up the databases and servers and peace and harmony reigned for 2 weeks. Looking through the source I was concerned that I couldn’t find any locking or transactional code and quizzed the Lead. He nodded a lot so I assumed they were going to put it in later. Finally the day of the stress test arrived and we got to 10 users before the whole system ground to a halt. Consternation all around and I was given a Spanish computing publication which had an article about how “Windows doesn’t scale”; in Spanish of course. I think I could probably recognise that phrase in any language.

An all hands meeting was called and I asked: “where is the locking and transaction code?” Blank stares. After much discussion it transpired that they had not put any in. “Why not?” I asked, after all this was a crack team used to high throughput transactional applications. The lead (via interpreter) explained to me that as VB did all the screen handling in a magical (to them) way they thought it would do the same for the transactional code. Not so I explain. Dawning recognition of the problem on the teams faces and back they went to their workstations. Another two weeks elapsed (note how long it took to make the code scalable rather than just functional, although retrofitting transactions was not a joy) and now the application streaked through the stress test.

So the moral of the story is that you can forget your architectural training if you are working in a new environment although it is pretty easy to get it back, certainly a lot easier than it is to teach new programmers about transactions!

 

Comments
  • You know what Dijkstra said about COBOL...

    http://www.math.uwaterloo.ca/~shallit/Courses/134/dijkstra.html

  • Awesome story. I think it really shows the flexibility of VB. BTW, I did not mean to imply that your previous article about architecture was bad or wrong. I merely meant to share my epxeriences in trying to sell architecture. Hope I did not offend.

    Wally

  • No, not at all. I agree with you. Selling architecture is hard and will continue to be so until people understand what it is about, really the point of the bolg, how do we educate people about architetcure

  • Michael

    It sounds like spending a week working with you would be a great laugh ;)

  • I actually enjoyed COBOL, one of the few I guess.

    The teacher I had was a walking talking compiler. She always told us to have the solution before going to the VT100 DEC terminals. She would go around and compiler our code in her head. She was good.

    Ahh the days of VAX/VMS and COBOL, when REAL Multiuser platforms ruled the earth unlike today's wannabies. Cant beat the big iron.

  • Talking of architecting code, I always have lots of debugging helpful things in my code, if a method returns a retval, I set one, so I can see it clearly in the debugger with intellisense, and also its there to use later if I need to test on that.

    I always add lots of events that I can subscribe to for testing and debugging, and debugging interfaces. Im just tired of people crying this is a bug thats a bug when its not, this way I can just show them there and then on the spot, they can even test it themselves from theyre calling code.

  • Amen to everything you've said. I find that some folks get so hooked on being "loosely coupled" that they do so for the sake of being. It's annoying.