 |
|||||||||||||||||||||||||||||||||||||||||||||||||||
Monday, August 15, 2005Saved by QA QA's having a rough time on this release. Code freeze for next month was Wednesday, but apparently that slipped a week late last week. Yeah! So now we can develop work-arounds for bugs we've found in our 3rd-party back end systems, and provide a solid release in 7 working days instead of 2. Simple pleasures... And from a slashdot reference, the copyright office wants to know if you'll be inconvenienced if the only browser they implement in their first release of the on-line patent preregistration software is Internet Explorer 5.1 or greater. Sheesh. Friday, August 12, 2005Uh... what are databases for, anyway? This bit of foolishness yesterday: as a matter of policy, we don't provide user interfaces that allow end-users to make changes in data stored in databases. Huh? Changes in database data are to be done by one of two methods. 1. An automated feed from another database. 2. A manual change via SQL typed by a DBA in response to a change order. I didn't ask if the policy applies to configuration files stored on a hard disk. What are these people thinking? Why are we paying Oracle for licenses on a powerful, flexible, transactional system that we can't use for transactions? Why are we using $100/hr programmers to take spreadsheet data entered by $35/hr clerks and slavishly copy it into databases that cost $60k/year to license and $20k/year to run? This is the sort of thing people in "big cubicles" do to people in "small cubicles" for reasons that probably made sense in one small situation. There is no mechanism for me to fix that situation, because in large companies, "policy" is made by people who have thousands of reports -- and bucking policy isn't something that gets you promoted, so most of those thousands just live with it. Until complaints about the policy come from more than one location, it won't be reexamined. I don't care if I'm ever promoted. I guess that means I'm going to be the lightning rod. Oh, sorry. I'll just sit here quietly for a minute until my blood pressure returns to normal. Thursday, August 11, 2005The Big Chill Yesterday, we spent the whole day waiting. Oh, we were busy, but all we really did was wait for other teams (and one other company) to fix their problems. How much cheaper would our product be if we could figure out how to make dependencies between each group and each other group clear? When I make a software change, I often have no way to find out who else besides my team uses that software... let alone what their requirements are. I've seen this over and over, everywhere I've worked: technical problems are often just "Oh, I didn't know you needed that!". Companies which sell software with exposed APIs have the same problem; which APIs do customers actually use? How much does it really cost if you change them? Wednesday, August 10, 2005Back in Big Industry My career has been pretty checkered: I started out as a field engineer working in power plants, then became a "consultant" working at a desk. Then I went to shift-work, still in the power industry. When I realized that engineers don't actually get to build anything new in the power business, I switched to software. After the obligatory sweat-shop job, I became a contract developer -- a hired gun -- and built a lot of interesting things for other people. I joined a dot-com, made a lot of money in about a year, then lost more than I made in the following year. After the bust, I returned to contracting, and wrote some interesting and some not so interesting software. Now, for the first time since 1994, I'm working for a "big company" again. I have a smallish cubicle in a large cubicle farm, and once again I'm a small cog in a big machine, after being the hired codeslinger (and designer, and architect) for years and years. Why am I doing this? Well, stability, for one. It's nice to relax and know that you're likely to be working with the same people next week as this. You can build a team that outlasts the current project. You can try to create real processes. Etcetera. And there's stability: my college-age daughter needs to know how to visit the doctor. The "insurance card of the month" game is hard on her, and on my wife. And then there's big iron. I'm working on a user-facing application that's deployed on specialized hardware all over the world. The user-facing client talks, via XML RPC, to its server, and the server talks, via JDBC, to a couple of databases, and via JINI, to another server, and that server talks, via a raw socket, to yet another server, which runs a very, very fast transaction processing system. Some of the end-user hardware isn't available to me, so I can't test code on it directly. User responses must happen in less than 3 seconds. Users routinely just walk away from the terminals -- and we don't want the next user to use, or even see, the previous user's information. Imagine the possibilities! How do you make software smart enough to do the right thing in that kind of environment? |
Last modified: Friday, October 31, 2008 at 9:19 PM.
Tech resources |
||||||||||||||||||||||||||||||||||||||||||||||||||
