I hadn't realized that your approach was intentional, either. That explains the instability during the redesign, which I found befuddling.
Actually, the instability during the redesign (which happened from 5/03 to 9/04 so I can be sure we're on the same page) wasn't my fly-by-the-seat-of-my-pants MO. It was the worsening of a system that was truly on its last legs. My development work happened on a completely separate platform (2 Windoze machines to replace 9 Solaris ones). With my getting side-tracked frequently to keep the old one breathing. Or revive it. I groan every time I think about the time and money I spent just keeping that one on life support long enough to get the new version complete enough for rollout. <groan>
Bear in mind, though, that my "maverick" style of programming applies to additions to the site, not to larger applications. Part of why the redesign took so long was finding and fixing problems. We all were very nervous about the rollout of the new version, but when it happened, it actually took more time to get the old system down than to bring the new one up. We literally had to call the ISP and tell them to yank all the power cords. Yeah, it'd crash at the drop of a hat, but if we told it to shut down, fuhgedaboudit.
And the new system came up running much faster and much more trouble-free than the old one. Right out of the gate. Most programmers don't get to sleep the night of a big rollout like that. I slept like a log. <g>
Most things actually get somewhat beat to death before they go into production. Those in which a mistake could pose a security or data corruption risk or could make any of our 3 main functions (reading, writing, search) non-functional.
I used to write accounting systems and inventory management systems and later managed teams of programmers who wrote them. Those got beat to death in development and testing because you could reach a point where the system was done. And because they were extremely important applications that could do far worse than inconvenience users.
Message boards don't work that way. Especially ones like this where the average user is a lot more tech-savvy than so many other forums. The kind where you can say "Okay, here's this basic functionality, but you've got to use it this way and don't make mistakes because I'm not trapping them. And there's still this and that to be done to it before we can call it finished." Message boards (good ones, anyway) are never done, and it's okay to roll something out that only has basic functionality but isn't 100% done. As long as the only people inconvenienced by it not being finished are those who chose to use the new functionality.
The embedded charts definitely aren't finished. They're functional enough for production (by message-board and my standards), but they're not finished, and even if I waited until they were finished, I've seen things mentioned after implementation that I want to incorporate, but wouldn't have thought of before rollout.
If you thought the programming team here was a bunch of guys and gals in cubicles wearing business attire, reporting to a bunch of suits who tell them what to do and how to do it, and have their work QA'd by another team of cubicle-dwellers, hate to disappoint you. It's just me in my shorts and sandals, smoking at my desk, and banging out code in the rare instances I get free of other work so I can do so, with Dave pitching in frequently to help (he's turned out to be better at complex SQL queries than I am).
By all rights I should've had the charts thing a lot further developed by now, but other hands are on my time. Including our fighting with getting a new iHub webserver into production. You'd probably be proud of us if you saw the amount of work and testing that's going into it. But it's had about a dozen false starts now where we had to take it back out and put the old one back in. Frustrating. But we're getting close. Very unlike the new version of SI which literally took minutes to bring up, without a false start, and worked amazingly well considering how huge a project it was and how little manpower was thrown at it (me and eventually Dave).
On the iHub webserver, it's really tough to test it before putting it into production. We can't accurately emulate the kind of work it's dealing with without just flipping the switch and letting it deal with thousands of user sessions.
You know, or maybe you don't, "us" old-school professional programmers are accustomed to a standard where you don't go live until it's bug free and where you are paid to anticipate "fools," where, if you haven't gotten the few little kinks out of even a major effort within maybe an hour of going live, you've failed miserably.
As the above copious verbage indicates, been there, done that, don't roll like that no mo'. However, I want to point out (yet again, I suppose) that SI's new version was a MAJOR effort taking nearly a year and a half to complete, and when we rolled it out, we didn't have any little kinks to get out of it. It worked perfectly right out of the gate and I immediately got to work adding features to it.
Yes, it's unfortunate that most professional programmers (past and present) don't have the luxury of working in my business model. It's really extremely rewarding and makes programming more than a way to get paychecks. I think it's a big part of the reason that programmers my age (47) are a comparative rarity. I was getting burned out in my late 30's and if it weren't for SI (and later iHub), I'd have gotten out of programming long ago because I find the cubicle-dweller model to be extremely unrewarding.
I haven't tried this new feature. I don't anticipate a use for it. But I expect to use the imbedded image feature when it becomes available. I think that will be very useful. Thanks.
Ummmm.... I thought we were talking about the embedded image feature. I was. What're you talking about? |
