Once again, it's Pi Day. The kids celebrated in their schools on Friday, but it was fun to remind ourselves on this Daylight Savings Time day as well, that there is more to today than just the time change.
Happy Pi Day!
This morning a trader came up to me and pointed out that with the latest release of this ground-breaking, seminal, enterprise VB app that's the core of the business at The Shop, one of the key features was removed because Ralph, my manager, wanted to look like we were accomplishing something useful. You see, this VB app really isn't great, it's everything but that, yet it's proving to be very hard to retire primarily because (in my opinion) the strategy to retire it is horribly planned, poorly managed, and completely ineffectual.
So Ralph decided that it'd be a great idea to have as our group's plans to help retire this app. Well... this is a dodgey goal in the first place as there's no way we can do it alone, but still, doing even little things should yield impressive brownie points with the upper management. So he's all about shutting parts of this app down.
He shut one down early. Too early.
With this latest release, he had them remove an important component to this one trader. My code wasn't through Q/A yet - and probably not into production for another few days. When it does arrive, it has all the features he needs, but today, it looked like I took away the one useful component of this old VB app without giving him a replacement.
Nice.
He was kind about it, but still... I could tell... he wasn't happy. I wouldn't be. He's stuck and can't see his positions, and it's something I (seemingly) took away from him for no good reason whatsoever.
The truth of the matter is that Ralph took this away, all for the pathetic, useless, brownie points that we now have more than burned up because of this horrible miscalculation. I advised that we should have waited until everything was done and ready and then tell the VB app group to shut off this component, but Ralph wouldn't hear of it.
"Nope", he said "That'll put us back at least a month."
How incredibly short-sighted.
Thank goodness it's Friday - I'm leaving early because I just can't stand to be here. It's one thing to make me a piece of meat - I had a hand in that by being too efficient and not demanding enough. But to make these ridiculous decisions all for the sake of some lame belief that it's a Holy Mission to retire this app, and in so doing, inflicting this kind of collateral damage... well... that's just too much for me.
I'm not a stupid cow.
This morning I was reading Daring Fireball and John pointed out an alternative to the Google Finance widget - the Google Visualization AnnotatedTimeLine. The HumbleFinance widget is a nice looking alternative to the AnnotatedTimeLine, but in it's current state it's too limited to really replace the AnnotatedTimeLine in my work.
First, it allows only two datasets. Normally, this is probably just fine as in a lot of finance you may just want to see an instrument price, or one instrument against an index - but for my graphs, well... I've had to limit the data in some pages to 64 datasets. It's just a different use-case when you're looking at risk across an entire firm.
Second, there are no annotations, and that's one of the most useful pieces of my web app. I'm able to overlay external events and trade events on the data to allow the users to see why the data is behaving as it is.
I'll certainly keep an eye on this as it gets better, it might get to the point that it can unseat the AnnotatedTimeLine. Then again, with Google dropping Gears in favor of HTML5 features, maybe it won't be too long and the AnnotatedTimeLine will be in HTML5 and we can get rid of Flash for the web app.
This morning I noticed that Apple had released Safari 4.0.5 on Software Updates. It requires a reboot, which is still annoying in my book, but so it goes. In the same update we get updated HP Printer Drivers, and those don't require a reboot. Drivers? No, Browser? Yes.
Go figure.
This morning I noticed that Google Chrome dev 5.0.342.3 is out and it seems to have fixed a few of my concerns about getting connected to servers, but maybe that's just my faster home connection versus the connection at The Shop. In any case, it's an improvement in something, so let's stay up to date and see if it's improved enough to be my secondary web browser.
I haven't used this guy in a while, but it's still the first graphics app I used on a Mac all those years ago and this morning GraphicConverter 6.7 was out. It's solid, has a great feature set, and reads some of the most odd-ball graphics formats I've ever heard of.
Since I was doing some simulations yesterday, I decided to have a look-see at the state of gfortran at the HPC on Mac OS X web site. Sure enough, they had an update. I have been running the September 2009 version, and they are up to the January 2010 release. Good enough reason to get busy installing!
I then ran through all my FORTRAN code again, and it even caught a few 'column 72' errors that had slipped by. Interestingly enough, MacVim pointed these out with a yellow background highlight! Very neat. I did the easy fix and the warnings went away.
I do so enjoy FORTRAN. It's just plain fun to work with.
Well... it's taken me what... about 25 years?, but in the end, I finally finished the first 10 psec of the simulation that I started in my PhD, and was never able to finish. These are the two big results I was waiting for with the Gould NP1 but never managed to be able to get the results out of the box as it just took too bloody long. Well... fast forward to now, and I was able to run the simulations for all 10 psec on my iMac at home without any problem at all.
In fact, the total runtime for the entire 10 psec simulation was 4:34:54 - about four and a half hours! Had I told myself back then that someday I'd run this code on a desktop Mac and it'd finish in less than half a day, I'd have laughed. And then wondered when that day would come. How exciting!
The first test is the Si pulse. Here, we're looking for a nice, representative pulse widening and drifting down the channel. I was able to get a few psec of this simulation done for my thesis, and it proved that at least in Si, the physics was behaving as you'd expect.
The second test was the similar conditions in a GaAs channel where we're biased in the negative differential mobility zone, and so we'd expect the oscillations predicted by the 1D simulations to start to appear. What I'm seeing here isn't anything like that.
This pulse seems to be nearly stagnant in the channel - hardly drifting at all - but spreading out much faster than the Si device. While this might make sense, if you think of the higher mobility in GaAs over Si, the problem is, the mobility in the bias conditions we're looking at should be shrinking the packet and starting to make oscillations on the top part of the pulse.
So I'm wondering if I've got something wrong in the code, or if I just have it misconfigured. It sure looks like it's configured correctly. But then again, I don't have anything to compare it to. Hmmm... very odd.
Well, if I get more time I might dig into this, now that the runs can be done in a reasonable time. I just wonder if there's something I'm missing as the other tests all checked out. It's something to think about.
I saw this article on Daring Fireball this morning, and decided to give it a read. Daniel J. had tweeted about it yesterday, and was in the middle of something so I didn't take the time to dig into the article. Well... this morning, I'm glad I did. The follow-up is equally interesting and as worthy of a read as the original.
There's just so much in this article to talk about. First, he's completely right about the state of typical development these days:
I want to make things, not just glue things together. When people ask me what I like about my job, I always say the same thing: that its the thrill of starting with nothing and making something. That, for me, is the essence of programming, and it hurts that there isn’t as much of it about as there used to be.
He's right on the money about the state of anything called Frameworks:
Here’s a rule of thumb (which, like all such rules, is often broken and should not be taken too seriously): beware of anything that calls itself a Framework. Anything that, instead of providing stuff that you can call, takes over the wheel and tells you what code to provide for it to call. Not always, but often, that marks the line where this stops being fun.
and:
You know the real problem with frameworks? They demo too well. Someone shows you their favourite framework and demonstrates how you can build 50% of your application in half an hour! Great! That other 50% can’t be hard, can it? But it turns out that what looked like 50% is actually 5%, and filling in the other 95% gets exponentially more difficult as you approach the 100% mark. Frameworks are great for building toys, and that fools us — again and again — into assuming they’re good for building products.
and whatever has Enterprise in it's name:
Especially, I have learned that anything that has “Enterprise” in its name is so incredibly boring that the people who use it had to shove the name of the Star Trek ship into its title just to keep themselves awake. (I am convinced that this is the case.)
I'm sitting here thinking these same things, and realize that there's an element that's missing here - it's the user community, or business users. They are the drivers of this change, not developers. It's not something the author touches on in his writing, but it's something I've come to realize in the past few weeks, and it's bothersome.
No good developer says I want to glue crap together! or Please let me use this Enterprise Java System! Nope. Bad programmers say that, and that's because they probably shouldn't have the job in the first place, and gluing things is at the limit of their skill set.
No, real programmers want to create things. Then why don't they? The answer is in those Framework Demos, and the press releases on the libraries and toolkits that the business users read and think that the act of creation takes exactly 3 hours, 15 minutes, and then there's no need for that documentation because they can use the frameworks to add in the features like so many Excel Macros.
It is we, the developers, that are to blame.
Like Prometheus, or even Pandora, we brought this on ourselves by doing too good a job for those that had no understanding of the complexity and difficulty in the creative process. These people would never have thought to walk up to Picasso and say Hey, Pablo - Babe! Draw me a tree, will ya? And get it on my desk today, or tomorrow morning if you need more time. Yet in my experience, they think two days is too much for a complete new feature set.
When we create something out of nothing, and do it faster and batter than they expected, they'll simply shift their expectations for the next time. No problem there... in fact, that's an exercise they like having to do. Next time, they'll expect more, and more, and then when you have to do something a little more difficult, they'll try to compare this to something done six months ago, and how you did it fast then, so why can't you do this fast now?
This makes an individual tired.
Then some CTO who may never have even been a good programmer, decides that the entire organization is going to use some Framework, or Enterprise Widgets, and then you're a Glue Monkey.
At each turn we do something that those requesting it have no understanding of so they can't possibly understand the cost of requesting it. Many of the bad programmers see this as nothing more than a digital assembly line, and for them, it takes no more thought than assembling a toaster or DVD player. But for the good developer, the act of creation is mentally, emotionally, even physically draining. That's why it's so rewarding.
But to the non-programmer, it seems like you sat down in front of a glorified TV set, and a few hours, or days later you came up with exactly what they asked for - no matter how crazy, difficult, or near impossible it was. To these people, there is no cost of that request. Nothing could be further from the truth.
I've been thinking of solutions to this problem, and realizing that anything involving the changing of other people is arrogant in the extreme, so I have to focus on myself and what I can do to change this for me. I've come up with a few ideas. None is trivial, but I believe one of these is the solution for me.
This seems obvious, and it is, but it's not trivial, and it's not a direct solution. You may land in a better place, or you may land in a worse place - it's impossible to tell, and in this day and age, I've run into employers that are not above decorating the truths about their organization in order to attract the top talent. Certainly in the financial sector which I'm most familiar with.
Yet, if you can find a place that matches your ideals and goals in software development, you're in business. Maybe there aren't that many places in the world like that, but I believe there are some. Maybe they're no more real than Santa and the Easter Bunny, but I really believe they are there, and as long as I believe they are there, I'll try to find one. Just one is all I need.
But lately, I've been thinking maybe the better approach is to settle a little on the job, and just change the environment.
I worked at home for 2.5 years while at First Chicago. I got more done there than I have ever gotten done in any office environment I've ever worked in. Why? Lack of distractions. It's simple, really. I have an office at home, with good internet connectivity. Just move the necessary machines to my office, start working there. For me the benefits are obvious:
All these reasons make a so-so job a "good" job because you approach it every day with a sense of happiness. You don't mind going to work, because it's a comfortable, warm environment that you don't have to travel 90 mins to get to. It makes all the difference in the world.
This is the most interesting to me, but it's also the path most fraught with danger and uncertainty. I've done the small consulting shop thing but what I'm thinking of is just taking some of my ideas for simulation tools and putting them on the Mac. I know it's not a career path that a lot of people would see as going in the right direction, but it's the extreme case of my second point of working at home. In this case, I work at home, but I also have to generate my own revenue.
But the path to this goal is clear: get some apps, start to generate some revenue, and then replace the day job. Not easy, and not guaranteed, but it's something I could do, and something that I want to do.
Well... today is one year at The Shop, and it's been an eventful year. I expected to be behind the curve on the existing systems for a while, and I was, and then I expected to get some traction and make some really good progress, and that happened too. I'm a little surprised that after just a year I'm entertaining the idea of leaving. It's not that people here are bad, it's that they seem to very reliably make the tactical decision - always favoring the give it to me now! answer as opposed to thinking that putting in an extra 10% would yield a vastly superior product.
I understand the logic - and given that they have been operating in this mode for years, it's logical that they don't see the need or value in doing it another way. But I'm not used to this. I find it really quite short-sighted and while I understand that sometimes you have to do the immediate fix, it's not what you should always go to, and here, it's more the rule to do that than the exception.
So it's been a year. Yippee!
But it's been a heck of a year.