Archive for the ‘management’ Category

Software Design Tip: Minimize Number of Languages

Tuesday, April 1st, 2008

I was recently asked about taking over support for an existing application. I’ll leave out what it does – suffice it to say it is web based, has a simple 3-5 page UI for the public to buy something, and about a 15-20 page set of back end interfaces for trained customer service and admin people to use. So less than 30 screens overall mKay?

The application was said to be written in Java. I know Java – I don’t like it, but I know it. If its small, I could be persuaded to pick up the maintenance.

However, I got a source drop and I was totally appalled. First, it suffers from the usual Java framework-itus.

Its J2EE – so we got Jetty container. They used Hibernate – so we have generated Java code based on some XML schema files. There’s also a mysql database – which duplicates the information in the Hibernate XML schema files. It uses cocoon – cocoon make use of xml and xsl to define navigation and transformations. There is also reporting that uses xsl. Workflows use flow – more xml only they used the Javascript extension so the workflows are actually defined using server side javascript.

Got all that? We have Spring, Coccon, Flow for Javascript (flowscript), Hibernate, Jetty, Javascript, Html, CSS, SQL, XSL and god knows how many dozens of distinct flavors of XML. For a 25 page web app. Wait, did you notice I didn’t mention Java? There is Java – the Hibernate generated classes are used – but indirectly – they may as well not exist at all since all the application code is some fractured XML or Javascript fragment stashed who knows where.

It seems we’ve lost track of something here. “Locality of Reference” In general, all the stuff that deals with the product selection page ought to be visible by looking into the file representing that page, then maybe drilling into components. The problem here is that, everytime I have to drill down, I have to switch languages. And context switches are bad for programmer productivity – mKay?

I’ve turned down the job. I don’t have time to learn all that junk for this little app. The client needs a new installation – for 25 pages that do mostly CRUD to mysql. If I do it, I’m thinking plain old PHP with an ORM. If I can find an ORM for PHP.

So far I’ve looked at Doctrine (not yet ready for production but it looks cool), Propel – and some others. The really off-putting bit is their slavish insistence on creating the xml mapping file – just like Hibernate. Of course, I have an existing database. The XML file they want is in the db. It just isn’t XML. Still, all the information is available for query – so why are they bothering me with this junk? Read the damn schema and make me some classes. I’ll eliminate the many to many mappings by hand. Sheesh. No wonder there’s a software crisis.

Hey framework people, stop making me write monkey code – figure out how to eliminate extra work – not make it. One meta model is enough.

Looking for work again

Monday, March 3rd, 2008

I’ve been doing a lot of PHP lately – shopping cart integration, web service clients, lots of ecommerce stuff. But I’m coming to the end of these projects and am looking for new challenges. Got a project or position that I can do remotely? Drop me a line.

Downriver

Monday, November 27th, 2006

For the past 2 and a half years I worked at Amazon.com. It was fun for the first year – so many old assumptions and prejudices shattered. But Amazon is a special case. For most normal sized systems, my old design sense was pretty solid.

Still, it was a horizon broadening experience and I enjoyed that. I managed teams of people and we built software and I liked that as a change from the endless parade of crummy short term java contracts I was getting.

But I left last month. I joined as something of a new manager. My pay grade was commensurate with my lack of experience in that area. But eventually I grew weary of it and was itching to get back to doing nifty code if I could find a way to do it on my terms. Which means dynamic expressive languages and I get creative control of the technology. No “You’re the architect – so you’ll use this language and that vendor’s solution”. Huh, I thought I was the architect.

The other main driver to leave is no work/life balance. This isn’t Amazon specific. This is US company specfific. In the US, if you work for an established company, this is just how it is. You get 2, maybe 3 weeks of vacation and a few holidays here and there. You are expected to put in 50 hours a week. With ever rising property values and congested highways, you have to live about an hour away from work, meaning you lose 2 unbillable hours a day just travelling to work. You’re working your butt off, but you can’t enjoy the fruits of your labor.

I lived in France for about half a year. I’ve seen how Europeans live. They take 5-6 weeks of paid vacation. They can take long leaves of absence. They are able to travel the world. In the US, you can’t get enough days off to drive across the country, much less travel abroad. No wonder we are such an ignorant xenophobic lot.

I have a boat. I’d like to take the boat in the summer and explore Puget Sound, where I live. I’ll need about 4 contiguous weeks to do it. I couldn’t get the time off. Why have a boat if I can’t take the time to enjoy it?

I have friends abroad. I can never get the time to go see them. I have the money. Just not the time. Again, this is lame. So I walked. I give up on work camp America. US companies say they can’t find qualified workers. We’re around. But your terms stink. Improve them or go pound sand.

I left the big company to work for myself. I build software using tools I like. Unconventional, but productive and low-cost tools like Squeak and Seaside. I use other things too, depending on requirements. I work when I want to, from anywhere I like.

I think this is the future as more and more of my colleagues are opting for this kind of situation. The big company life holds no attraction for the seasoned employee.

Employers think workers are stupid

Tuesday, July 18th, 2006

About once a week some recruiter emails me with a “great opportunity”. Only the opportunities are usually worse than I have now.

In a keyword search your resume came up as being possibly qualified for the following position I have open
with a very successful IP Network Security software development company I am currently working with in the
Sunnyvale area:

Please review the following requirements and reply with a copy of your resume if you would be interested:

Sunnyvale. I quickly do a web search for median home price of Sunnyvale and find its about double my current home value. So I email the guy and tell him my salary requirements to consider a move. His reponse?

Sorry, that’s a CEO salary.

Ignoring for a second that I have yet to meet a CEO worth anywhere near what he gets paid, I tell him to go ahead and outsource the job somewhere with sane real estate prices. I mean, since when are knowlege workers supposed to be stupid enough to take a real pay cut?

No wonder they can’t find qualified workers, they are totally oblivious to the market forces talent has to deal with. My salary expectation is (median home price)/4. No matter where you are. If you can’t pay that, move or plan on outsourcing to some location where people can afford to live on what you are willing to pay. That doesn’t necessarily mean India or China or Russia or some other country. Lots of folks in the US live in sanely priced areas as well who can do the job just as well or better for the money you’re willing to pay as long as you don’t expect them to relocate.

Workers have costs too. Respect that.

Losing email switching jobs

Friday, July 14th, 2006

Scoble talks about switching jobs and leaving lots of email behind. The solution to this problem is to move all knowledge hidden in emails to a team wiki available to all others in your organization.

Great Book on Managing People

Monday, May 1st, 2006

I picked up the book Harvard Business Review on Managing People in the Seattle airport on Friday and read most of it over the weekend. It backed up a lot of things I knew intuitively about managing people from experience. Only it provides data and case studies to explain why. Lots of light bulbs going on for me.

Perhaps the most gratifiying thing for me was its vindication of my management approach and condemnation of my manager’s approach. Since we are diametrically opposed, this book makes me the right one. Its a shallow victory given that, while I have the satisfaction of being right, he still wins and will keep on winning because bad employees are completely unassailable from below at work. I’ll probably post more articles on the specific revelations I’m having.

If you manage people, you really ought to buy this book.