Why don't I buy tech books anymore?

Somehow I stumbled on a reference to this book on architecture by Eric Evans. The table of contents looked like this guy may have had something good to say and the reviews on Amazon were favorable, including one by this guy Brad Appleton who lives in Chicago and I think is a really sharp guy. I actually interviewed him once for a project, but he didn't take the offer.

Anyhow, before spending beaucoup bucks on this book, I decided to check it out at the local Barnes and Noble (where it was $50 instead of $34 on Amazon). After about 15 minutes of browsing through this book, I have mixed feelings. The content is good, but I feel like he doesn't really get into the details of a lot of serious stuff like app partitioning and packaging. Of course I haven't seen a book yet that does a better job. Maybe this is so hard that no one has a good answer how to do it. Maybe it is just not something that sells books. The long and short of it, I passed on the book. Although I liked the Kandinsky on the cover and the little intros and segues. It reminds me of the school textbooks my dad had in the Soviet Union. They always gave you a little historical context about whatever math or science topic they introduced. So that you learned a little about Pythagoras and Archimedes instead of just studying triangles or water displacement.

Performance testing continues

The results of the parallel runs of the batch seem real good. We seem to be scaling linearly with no ill effect. Started testing the online systems today. We got some decent volume through but we need to figure out what to do about getting better input data. Overall, it didn't look too bad.

Well, I missed the Christopher Hitchens interview. By the time I got to the tiny bookstore, the line of people was out the door. Had to go home disappointed.

Every architect needs a sugar daddy

As proven by Mac vs PC, Betamax vs VHS, it's never the technology. If you want to be an architect on a successful project, you cannot be successful on the merits of your technological skills alone. You need a a sugar daddy. Basically someone powerful in the organization that trusts you and believes that you are beneficial to them in some way. Otherwise, your efforts will be undermined by a multitude of different rivals, ill wishers, nay sayers. To convince an organization that your technical solution is the one they should go with is almost an impossible task if you do it from the ground up. That is just signing yourself up for misery. You need to come in from the top with the backing of some important people, and then do a good job.

Technical update. After the fiasco with the faulty DASD, we got a successful run with a bunch of parallel streams. Encouraged by this we decided to scale up. Bang! The servers go into a spin loop and crash. On the screen I notice that top is reporting all maxed out on memory and zero swap is available. Calling down to the systems guys, it turns out there was a problem with configurations. All the servers have been set up with no swap. Had them fix it, bring the servers up, and try again. Success. Got almost 100 streams running on the four servers. The system is humming. Need to do a lot of tuning to bring down the memory usage per stream. Also, still spending 85% percent of the time in I/O wait. New DASD would make this scream. Next, we analyze the data, and move on to the test on the online system. After that, will run the mixed load.

Architect = Asshole ?

Is it possible to be an architect on a big project and not have people perceive you as an asshole? Managers think you are an asshole because you keep sticking your nose into their business. You may tell them that you want certain things scheduled earlier to mitigate technical risks. You may want to integrate the system as soon as possible to mitigate technical risks. You need to procure sufficient capacity to start performance testing early.

Programmers hate the architect. If they are smart, they have a huge "You can't tell me what to do" complex. If they're stupid, then they have a huge "Why do we have to do things this way" or "I can't believe you're making me rewrite this" complex.

I think this is a more specific instance of the general truism - if you want anything to get done, you have to be a little bit of an asshole. You can't piss off everyone, but you can't make everyone happy either.

Speaking of assholes... Planning to see Christopher Hitchens at a bookstore on Thursday. This is one contrarian, bitter sounding, European bastard. But the guy is razor sharp and not afraid to speak the truth as he sees it. Seems to spare no one.

I am turning into Holden Caulfield, also - the day of the big test.

I can't stand phonies. Although I haven't started wondering what happens to the ducks. The best remedy for dealing with project bullshit is seeing technology work. Got the eight monitor war room display configured and it looks pretty cool. Yesterday we scheduled the first in a series of tests to start testing our architecture. It was a dismal failure. It appears there is a hardware/firmware problem on one of the disk packs. Response time for I/Os was in hundreds of milliseconds. The vendor was in running diagnostics the whole day - no luck. Today we decided to move the database off the bad packs. Took about 4 hours, not bad for a 4 TB database. Then started the test again. Seems like it is working. We had about 32 streams hitting hard against the database. No locking problems that were evident. Tomorrow we'll start gathering the stats on throughput and scaling.

I have to stop reading www.theserverside.com but for some reason it is addictive. This guy from www.tangosol.com posts there all the time. After looking into another product - Prevayler -(http://www.prevayler.org/wiki.jsp) I just about gave on on finding Java people that know anything about real transaction processing systems. But the guys from Tangosol had me pleasantly surprised. Even talked about read-locks and transaction isolation levels. Don't really see how I could use this on my current project, but I'll keep them in mind.

Do the opposite of what you think is right

Being a systems architect, you inevitably get caught up in project politics. Whenever you are faced with a situation where you feel like saying something which would cause problems politically, even if it is the right thing to do technically - don't do it. Fight the urge to be rational and to think of the greater good. Those are still your ultimate goals, but you can achieve them better through indirect means than confronting a bunch of people in a political struggle.

Nothing new under the sun

Just did a google search for technomusings and found a whole bunch of people using this word. And here I thought I was being pretty original.

Similar, yet different

I've always been captivated by this phrase, and for some reason, it really rings true in my exprerience with software development. It seems like I run into two kinds of people. The first kind seem to think that any innovation is really exactly the same as what they were doing 20 years ago. This is usually said in a grumbling tone - "Web based apps is nothing but a fancy 3270 terminal stream. We were doing thie same thing 30 years ago in CICS". The second kind is usually the guys 3-4 years out of school that are completely on the other side of the spectrum. This is usually said in a haughty, condescending tone - "Virtual Machines are totally revolutionary. These guys just don't get it."

It seems like both kinds of people suffer from the ability to see the truth is somewhere in the middle. Very few things are truly created ex nihilo, and therefore the ability to relate something new to lessons and mistakes that were learned from the past is very powerful. However, dismissing new things by only noting the similarity to something already out there and not seeing the differences is just as bad.