Arguing Data

People have a lot of different reasons for posting blog entries. These reasons vary from financial, to personal, to professional, to I'm afraid to know more. For me, one reason I take the time when I could be doing something else is that I like to put my ideas out there to be tested. I don't really care if a majority of people agree with me so much as I want to see what other people have to say for or against certain things. The downside to this is that I'll sometimes find that an idea isn't as good as I had originally thought it was. The upside is the opportunity to refine something to be better or to discard an idea that turns out simply to be bad.

Which is why I'm glad to see Karl Seguin's response to a post I had made about DataSets. Karl's a bright guy and he has a good background in the problem domain associated with DataSet objects. He displays class, too, even when he feels I've been a bit rough in a point or two.

The School of Hard Knocks

I empathize with his experience where DataSet misuse caused much pain and suffering. I've been in similar situations and it's no fun. In a full-blown business transaction environment, DataSets have some liabilities that make them ill-suited for business-layer usage. The thing is, the opposite problem exists as well, and it's one that is more serious than people want to give it credit for: a layer of specialized, hand-crafted business objects that don't actually do anything.

I'm currently working at a place that has an extreme case of this problem. We have four entirely separate ASP.Net applications for our internal invoice processing. All four of these applications have their own set of substantially similar custom objects that are completely unique for that application. Each object doesn't do anything more than contain a group of properties that are populated from a database and write changes back to it.

I shudder to think how many hours were wasted on this travesty. It's over-complex, can't leverage any type of automated binding, doesn't track row state, and testing and debugging changes is an unmitigated pain. It's like someone attended an n-tier lecture somewhere and never bothered understanding what the point of having one actually was. Frankly, I'd prefer if the previous developers had simply put all the data access right in each individual page--at least that'd be easier to fix when something blew up.

Learning Your Craft

The thing is, my experience no more proves custom business objects wrong than Karl's experience proves DataSets wrong. That's the trouble with anecdotal experience: it feels more important than it is (it doesn't help that pain is such an efficient teacher).

The trick of learning a craft is in gaining experience that is both specific and broad. This can be tricky in a field that is as immense as software development. You really have no choice but to specialize at some point. Even narrowing it down to ".Net Framework" isn't nearly enough to constitute adequate focus for competence.

Unfortunately, Karl's point that there are a lot of lazy programmers out there is true. Anyone who has had to hire or manage programmers will confirm this. Too many developers don't bother learning enough of their craft to be considered actually competent. Faced with the need to specialize carefully, many simply give up and learn only enough to get by (and sometimes not even that much). They're content to learn the bare minimum needed to get hired. They'll learn enough of the "how" to create a program without ever bothering to learn any of the "why".

Teaching Others

I have a minor problem with Karl's explanation, though. He says, "I advocate against the use of DataSets as a counterbalance to people who blindly use them." While I understand this position, I'm not sure I can be said to appreciate it. It smacks a little of the "for your own good" school of learning; which works well enough in a parent-child or even teacher-student relationship. I'm not sure it works so well in public or general discourse.

It is hard to correct bad habits, particularly habits as widespread as DataSet misuse seems to be. As one who often has the bad habits to be corrected, though, I think that I'd prefer having the problem explained and given the context so I can understand the trade-offs being made. That would give me the opportunity to know why something is wrong, not just that something is wrong.

That'd require discussing DataSets in specific instead of general terms. I'm not sure if Karl would really want to do that, though. I mean, his specialty at CodeBetter is really ASP.Net. Expecting him to tackle ADO.Net is not just unrealistic, it could have the effect of diluting his blog posts and alienating his regular readers or getting him embroiled in things he's less interested in.

I would like to see someone respectable and wider-read than I am take on Strongly-typed DataSets in a more complete fashion, though.

Professor Microsoft

Which is why I have to agree with Karl that the blame for DataSet misuse lies squarely in Microsoft's court. I stopped counting how many official articles and examples from Microsoft included egregious misuse or abuse of DataSets. And I have yet to see any that describe how to do it right or what kinds of things to look for in determining the trade-offs between a Strongly-typed DataSet and a more formal OR/M solution, let alone ameliorating factors for each. The only articles about DataSets that I can remember that don't actually teach bad habits are articles about how bad they are. Which isn't helpful. It'd be nice to have something, somewhere that talks about using them wisely and what their strengths actually are. Maybe that should be a future blog post here...

26. February 2007 18:33 by Jacob | Comments (0) | Permalink

Are We There Yet?

"So when will you be done with this development project?"

I don't know about you, but I hate this question. There simply is no good answer for it. It seems like such a simple question with a simple DateTime valued answer. One of these days I swear I'll answer with, "Oh, I'll be done next Tuesday at 2:34pm." just to see what happens.

And seriously, businesses hate that we have such difficulty answering the question. It seems perfectly reasonable for them to want to know when they can plan to have the new processes that they know they desperately need. Developers demand high salaries and are ostensibly professionals, they should be able to give a professional answer, right?

The Road is Well Paved

The thing is, software development is a lot harder than people expect it to be--and this includes software professionals. Even simple software projects can run afoul of hidden complexities that can destroy well meaning estimates and make everyone unhappy. And no matter how you hedge your answers, people simply don't remember all your caveats, maybes, and what ifs that you use to indicate uncertainty.

The end result is that developers seldom make their ship-by dates and companies become disillusioned and impatient with all software development. That's not helpful for anybody, but it's pretty much the rule anymore.

And the fact of the matter is that the vast majority of developers (and development managers) never learn how to answer the estimate question. They'll move from company to company, repeating the cycle of hope, suspicion, and disappointment over and over again. Which works well enough for the developers in the boom times when the demand for development is so high that mildly talented house plants can get hired as developers.

So a lot of people are making the same mistakes over and over. Businesses can be excused for assuming that this is simply the way things are and feel confident in their distrust of software professionals. They've been there, done that, bought the t-shirt.

Paying the Toll

This environment causes developers who care about these kinds of things a lot of heartburn. Everyone pays for the ongoing cycle of disillusionment. I believe that this is what really prompts posts like the recent ones from Ted Neward talking about professional ethics. And I've been known to throw my own hat into the ring as well.

We get tired of paying for the sins of those who have gone before. And I'm not referring to the messed up legacy code we stumble into, either. Frankly, messed up code is the least of your problems coming into a situation with a client who has been burned by previous developer promises. Companies that have had deadline after deadline missed have a degree of mistrust that is very hard to overcome.

We pay for this distrust in a hundred different ways. The thing is, trust is a paying commodity in business. Working with partners you trust means a whole lot of overhead you can simply skip. An analogy: if I trust a plumber to fix my sink quickly and professionally, I can go get a burger and leave him to it. It's only when I don't have that trust that I have to pay the additional overhead of having someone I do trust watching to make sure he's not napping under the sink.

Want to see a business manager go into a dreamy fantasy? Ask them what it'd be like to be able to trust their software developers (in house or not). The more experience they've had with developers the more intense the fantasy.

The Rubber Meets the Road

We have a couple of areas of friction in businesses that exacerbate this situation. The main disconnect with business managers is that we have borrowed terminology and tools from other disciplines without understanding that our processes are fundamentally different. It's tricky because the temptation to use manufacturing terminology is immense. After all, we are creating a product of sorts. This makes so much sense on an intuitive level that it's hard to realize that the comparison is misleading and potentially dangerous.

I wish we could retrain everyone to make analogies to other business specialties. Scientific research or law come to mind as potentially useful analogies because both are similarly plagued by the impact of unique situations, changing ground rules, and unforeseen complexities. It would be interesting to investigate how managing software development like a patent application or drug research would change how we look at the problems involved. We might have stumbled onto iterative cycles and responding to altered requirements a whole lot sooner, for example.

Paying Attention

The real problem, though, is that most developers (and even most development managers) don't take the time to learn about common friction points. Nor do they take the time to build relations with their business counterparts so that you have some political capital (aka trust) to use when it is needed. It's easy to forget that much of the progress in software development practices are pretty recent in terms of business processes. After all, business managers don't move at the speed of light and changes tend to take time to penetrate those layers.

Which means that a whole lot of industry advances aren't even theory yet in the board room.

And the fact of the matter is that you cannot expect a business manager to understand what makes Agile practices work. Or the reason that strong unit testing saves time over the long run even though it takes more time up front. Learning to communicate at a level that is sufficiently detailed for smart business decisions without getting bogged down into the jargon inherent in any specialty is an invaluable skill, and one best learned earlier than later. That means thoroughly understanding those theories yourself--not just on the surface or in buzzword compliance. It also means learning to communicate that understanding from orbit, 30,000 ft, 5,000 ft, and right on the ground. This is hard to do. It takes practice. It also takes exposure to business manager types. I'm not sure which is harder...

Something to think about, though: not learning this skill leaves you at the mercy of those who do learn it.

My point, though, is that it takes both. You have to learn your profession so thoroughly that you can deconstruct its "best practices" ("design patterns", whatever) and rebuild them from basic principles on the fly. AND you have to learn to communicate that understanding comfortably to people of varying familiarity with software development in a business environment.

That's what it takes to be a true professional. It's easy to let those two skills fall out of balance. Individuals who understand both are invaluable to a company. Also rare. Companies who discover someone capable of both are often surprised at how much smoother things run with that person placed where they can do the most good--a point Jeff Atwood's latest on becoming a better programmer drives home.

So I don't have a formula for quick and accurate estimates. Just a lot of hard work. Still, here's a tip for free: anyone asking for a firm delivery date is inherently assuming BDUF. Once you know that, you know where to start your answer.

29. January 2007 18:19 by Jacob | Comments (4) | Permalink

Trackbacks Are Dead

 

Jeff Atwood has a recent post on why he finally gave up and disabled Trackbacks on his blog. My blog is the tiniest fraction of his and I had to disable trackbacks just for sheer spam volume back in October (inspiring an anti-spam rant of my own).

Jeff lays the blame for Trackbacks' demise on Six Apart--the outfit that created the standard in 2002. Ah, those heady glory days when you still had to explain to people what a blog was. Trackbacks were a great idea. They still are a great idea. But Jeff is right, the simplicity of the standard has left it wide open to abuse and that abuse has killed them dead.

So my question is (to Jeff or anyone else), how would you alter the design to make the standard more robust?

My initial take on it was to alter the standard to incorporate a public key exchange and a signature. But then I realized that, hey, spammers can create asymmetric keys as well as anyone else can. In other words, the problem isn't being able to authenticate the link--it's being able to evaluate the linked post.

Jeff's current stop-gap of finding links to his posts through Technorati seems like a reasonable short-term solution. Introducing a third party is problematic, though, because it leads to inevitable issues in finding a trustworthy third party that will carry the authentication burden for you (as well as traffic and processing costs as people ping them for link verification). Indeed, Akismet (a popular stab at trackback filtering) has those same third-party screening issues and isn't substantively different from Jeff's use of Technorati.

I suspect that the problem might not even be in bad design by Six Apart, however. The thing that makes Trackbacks so popular and led them to be so widely adopted is that it allows the creation of inter-post linkages from unaffiliated sources with very little effort. I'm afraid that any solution to the trackback problem is going to necessarily involve increasing the effort of unaffiliated linking to a point where it becomes much less attractive.

A Stab in the Dark

That said, here's two thoughts about potentially rewarding avenues for solving the problem picked up from spam solutions in other realms.

First from email spam, and recognizing that I'm pretty thoroughly ignorant of the underlying mechanisms involved in Bayesian content analysis, I wonder if there might be some useful application for content analysis here. Spammers are increasingly sophisticated in overcoming content analysis, though. Trackbacks may be easier to analyze, though, because they have an easily available comparison text (the originating post). It may be easier to compare your post with that of the linker and come up with a tougher analysis than you can in, say, a lone email. I don't know about that.

Second, the key to the success of spamming is that they have such a very low cost per "signal" (email, comment, trackback, what have you). Their only incremental cost is bandwidth to find blog posts and to send trackback signals. Raising those costs can have a significant effect on spam. This is essentially the key to Captcha's success in curbing comment spam. If a trackback request prompted a user-interactive Captcha-like query, that alone may well be enough to stem the vast majority of trackback spam. Perhaps a design amendment that included a short interaction on a trackback ping would be successful in cutting spam back to manageable levels.

In looking at those two ideas, it occurs to me that the main problem with a Bayesian solution is that it places the burden (both in implementing the Bayesian algorithms and in processing the incoming links) squarely on the target of the spam. This can lead to an unwanted side-effect by leaving your blog much more open to another Internet dirty trick--denial of service attacks. Frankly, you don't even have to deny service to affect a lot of private bloggers--attacks that increase their bandwidth usage would be as unwelcome to many as a full-on denial might be. After all, it doesn't cost you extra hosting fees when your blog goes down.

So maybe that means I only really have one thought/solution/suggestion. Bayesian analysis would be cool for the AI geeks, but not terribly practical in the constrained environment confronting most bloggers. I wonder what it'd take to create a Captcha mechanism in trackback notification?

21. December 2006 11:59 by Jacob | Comments (2) | Permalink

Two Things I Regret

Have you ever been in an interview and gotten some variation on the question "What do you regret most about your last position?" Everyone hates questions like that. They're a huge risk with little upside for you. You're caught between the Scylla of honesty and the Charybdis of revealing unflattering things about yourself.

Still, such questions can be very valuable if used personally for analysis and improvement. In that light, I'll share with you two things I regret about my stay at XanGo. Since I've ripped on the environment there in the past, it's only fair if I elaborate on things that were under my control at the time--things I could have done better.

Neglecting the User

Tim was the Senior IT Manager (the position that became IT Director once XanGo had grown up a bit). He was the best boss I ever had. His tech skills were top-notch (if somewhat "old school"). In addition, he knew his executives and how to communicate with them on a level they understood. It was a refreshing experience to have someone good at both technology and management (and since he's no longer my boss, you can take that to the bank :)).

After a little break-in time as the new Software Development Manager, Tim and I discussed what we needed to do for the organization. Tim's advice was to establish a pattern of delivering one new "toy" for our Distributors each month. He said that the executive board are very attached to the Distributors and that keeping things fresh and delivering new functionality and tools to them each month would make sure that we had enough of the right kind of visibility. Goodwill in the bank, so to speak.

This sounded like a great idea, and frankly, "toy" was loosely defined enough that it shouldn't have been a hard thing to do. It turned out to be a lot harder than expected, however. In my defense, I'll point out that we were experiencing between 15% and 20% growth per month and that we had done so since the company had started a year and a half before. That growth continued my entire tenure there. Now, if you've never experienced that kind of growth, let me point out some of what that means.

First off, using the Rule of 72 (the coolest numeric rule I know) will tell you that we were doubling every 4 to 5 months (in every significant measure--sales, revenue, Distributors, traffic, shipping, everything).

In case you've never experienced that kind of growth, it feels like ice-skating with a jet engine fired up on your back. Even good architecture will strain with that kind of relentless growth. When this happens, you become hyper-vigilant for signs of strain. This vigilance has sufficient reality to be important to maintain. Unfortunately, it also makes it easy to forget your users.

Developers like to live in a pristine world of logic and procedure. Unfortunately, life, and users, aren't like that. If they were, there'd be less need for developers. Users don't see all the bullets you dodged. They take for granted the fact that a system originally designed for a small start up is now pulling off enterprise-level stunts. They don't see it, so it doesn't exist. It is very easy to get caught up in the technology and forget that often it is the little touches that make your product meaningful. Sometimes the new report you spent an hour hacking together means more than the three weeks of sweating out communication with a new bank transaction processor. And by means more, I mean "is more valuable than".

Not that you can afford to neglect your architecture or needed improvements to sustain the needs of the company and prepare for foreseeable events. If you ignore that little glitch in the payments processing this month, you have really no excuse when it decides to spew chunks spectacularly next month.

What I'm saying here is that you have to balance functionality with perceived value. You have to know your users and their expectations because if you aren't meeting those expectations, no amount of technical expertise or developer-fu is going to help you when things get rough. In the case of XanGo, I could have afforded to ease up on the architecture enough to kick out monthly toys for the users. Yeah, some things would have been a touch rockier, but looking back there was room for a better balance.

Premature Deprecation

When I arrived at XanGo, our original product (a customized vertical market app written in VB6 on MS SQL Server) was serving way beyond its original specifications. We'd made some customizations, many of them penetrating deep into the core of the product. Our primary concern, however, was the Internet application used by our Distributors in managing their sales. We spent a month or two moving it from ASP to ASP.NET and ironing out bugs brought on by the number of concurrent users we had to maintain. We also removed the dependence on a couple of VB6 modules that were spitting out raw HTML (yeah, I know. All I can say is that I didn't design the monster).

Anyway, after that was well enough in hand, we gave a serious look to that VB6 vertical market app. Since VB6 wasn't all that hot at concurrent data access and couldn't handle some of the functionality we were delivering over the new web app, we decided that it should be phased out. Adding to this decision was the fact that we had lost control of the customizations to that app and what we had wouldn't compile in its present state.

Now developers (and for any management-fu I may have acquired, I remain a developer at heart) tend to be optimistic souls, so we figured "no big", we'll be replacing this app anyway. And we set to work. Bad choice. In a high growth environment, the inability to fix bugs now takes on a magnified importance. Replacing an application always takes longer than you expect if only because it's so easy to take the current functionality for granted. Any replacement has to be at least as good as the current application, and should preferably provide significant, visible improvements.

The result of this decision was that we limped along for quite some time before we finally came to the conclusion that we absolutely must have the ability to fix the current app. We paid a lot of political capital for that lack. In the end, it took a top developer out of circulation for a while but once it was done, it was astonishing how much pressure was lifted from Development.

It's the Users, Stupid

No, I did not mean to say "It's the stupid users." When it comes right down to it, software exists to serve users, not the other way around. As developers, it is easy to acquire a casual (or even vehement) dislike of our users. They are never satisfied, they do crazy stuff that makes no sense, and they're always asking for more. It's tempting to think that things would be so much better without them.*

I got into computers because I like making computers do cool stuff. Whatever gets developers into computers, though, it's a good idea to poke your head up periodically and see what your users are doing. Get to know who they are. Find out what they think about what you've provided for them. Losing that focus can cost you. Sometimes dearly.

*I think one of the draws of Open Source is that the developer is the user. It's also the primary drawback. But that's a post for another day.

 

17. November 2006 20:10 by Jacob | Comments (0) | Permalink

(Lack of) Progress Bars

More griping. I know! You'd think I were a negative person. I'm not really. I don't think.

Anyway, this one is short. I've noticed a trend lately (okay, in two products that I sort of like) where developers are using a progress bar to indicate that the program is busy and will get back to you shortly. Now, to me, there's a reason that ye ole progress bar has a Minimum, a Maximum and a Value. You know, it has a task that starts at some value, that value "progresses" until it hits some ending where it can then stop.

No doubt I'm being over-sensitive. Still, it isn't like actual busy gifs are hard to find. I mean, some sites will even generate them to order.

 

Technorati tags: , ,
14. November 2006 20:44 by Jacob | Comments (0) | Permalink

More Arrogant Software

I don't mean for this to be a "gripe" blog. Not that gripe blogs aren't entertaining--I mean, I kind of like Mr. Angry, the Daily WTF, and others. That said, sometimes you just have to share in the hopes that you aren't alone in this whole frustration thing.

I named names in a previous post about Arrogant Software, so I guess this is mostly adding to the list. Today's highlight is SpySweeper from WebRoot. Now, like all the software on my Arrogant list, I found SpySweeper useful. I even bought two subscriptions so that both our computers would be covered. Unfortunately, the whole subscription thing means that eventually you have to re-up.

On the plus side, SpySweeper notified me immediately when my subscription ran out. Being the wrong time of the month (no, not that wrong time of the month), I deferred for a bit figuring I'd just have to make do with old definitions for a little while. That's when the software went all arrogant on me. SpySweeper began asking me every single day if I wanted to renew my subscription. Now, software subscriptions are a little squirrelly to begin with, but this was beyond my level of tolerance. I couldn't select "Don't ask again for xx" and I couldn't select "Leave me alone forever already", no. That'd make too much sense.

The end result is that SpySweeper got the axe. The boot. The ole heave ho. I don't have to put up with that crap, so I went and found an alternative. Since Microsoft is entering that space, I thought I'd give them a look-see. Not to be too much of a shill or anything, but the combination of a 90-day free trial and the eventual subscription covering 3 PCs has me more than a little intrigued. We'll see if it's as cool as MS thinks it is--or at least, cool enough that it's an adequate replacement for SpySweeper.

 

Technorati tags: , , , ,
13. November 2006 20:57 by Jacob | Comments (0) | Permalink

Arrogant Software

Ever notice that software seems to have a personality? Some programs are desperate for approval, some eager to please, some like to show-off all their cool features, some calmly wait for their opportunity to be useful.

And some programs are simply arrogant jerks. There are a couple of utilities that are useful enough that, like in real-life, you simply put up with their crappy attitude and count the days until a competitor comes along that will offer a viable alternative. I end up tallying my annoyances every time they crop up, keeping score for the day I can wipe them from my machine. They have a trait in common that I'll get to in the end (so skip down if you want), but first lets name some names--here are my top offenders in no particular order.

Apple iTunes

This jerk seems unable to put together something as simple as a patch. Every time an upgrade is available, you have to download the whole setup file. It saves your playlists and music and such but that doesn't mean it keeps all your selections and preferences. I like a cluttered "Desktop", but iTunes seems unable to distinguish between "Desktop" and "Quick Launch". To get one, you have to have another. Which means that after every upgrade, I have to delete the shortcut form my Quick Launch. Jerk.

Also, you can't install iTunes without Quick Time. I hate that sorry program. It doesn't play nice with others, and it wants to hog all your media associations. Also, every time it installs, it figures you want it to load and sit in your system tray. Seriously, why on Earth would I want a media player resident in memory all the time?!? It's like that Melvin kid in elementary school who latches onto you and pesters you constantly. Go away please. Stay away. If I set a preference that I don't want to see you, that preference should persist through an upgrade. Jerk.

Adobe Reader

The Adobe Reader is a must-have utility if you deal with electronic documents at all. Everything from product manuals to pre-print artwork can be exchanged online and maintain all the formatting and presentation options marketers insist are important. So I can't really give them the kiss-off I long to give. Tell me, please, why a document viewer requires three restarts in order to install a point upgrade? Why should I restart even once? I can't imagine why a document reader needs to be so tied into the system kernel that it can't unload and reload without turning the OS off. I don't care how clumsy the OS is, get over yourself already and learn to adopt a lighter touch. Jerk.

Real

Real is another media company with their own proprietary format for video and sound. Real also installs itself into your Quick Launch without asking. Did I mention how much I hate that? Real also has possibly the most annoying registration process. You literally cannot start up their software until you complete the registration. It is obvious that Real sees their customers as uniquely their very own and anyone not willing to give them all their personal information must be pirates anyway so screw the freeloading scum. The real (heh) pain comes when you try to uninstall, though. I'm not sure if this is deliberate or incompetence, but even if you successfully complete an uninstall (hardly a given), Real can leave little bits of itself embedded in your system. Pieces that load on startup, even--taking up valuable system resources. Jerk.

Sometimes, someone will release content that uses Real's formats. When that happens, I generally blow it off. If the author is going to use jerky software to get their content out, I'm generally not interested. Every now and then, someone will bury content I actually really want with a proprietary Real format. Fortunately, it turns out that Real isn't too hard to duplicate (lending towards the incompetent judgement mentioned earlier), so alternatives exist. At this point, I don't care if the program is illegally using patented processes or formats, I'm just glad it's available. It wouldn't surprise me to hear of some lawsuit brought by Real someday because some hacker is releasing software that is more stable, more user friendly, and has a smaller footprint than they can manage. Jerks.

The Common Factor

I'm not sure why media software companies tend to be jerks, but it seems to me that these at least have one trait in common: they make important decisions without your input or permission. Anyone who puts their trashy icon in my Quick Launch or System Tray without my permission is automatically a jerk in my book. If you want to set up residence there, you had better ask me first. I don't want my barber camping on my front porch, and I don't want Real in my Quick Launch. How hard is that to understand?

Also, I don't care if it is sloppy programming or deliberate obtuseness but when I tell you to go, you go.  Completely. I can understand that it can be tempting for companies with a strong market to lock customers into certain options and choices. The effect on me, and I'll bet that I'm not alone here, is that it makes me yearn for alternatives. A company with a must-have product is in an enviable position. Stay unobtrusive and I'll stick with you for a while, even when competitors show up. Drag yourself to my attention with petty "look at me" stupidity, though, and I'll be begging for a replacement. Seriously, you have my business, don't make me regret it. You may be irreplaceable now, but you're one motivated guy in a garage away from extinction.

 

Technorati tags: , , , , ,
5. October 2006 19:45 by Jacob | Comments (0) | Permalink

Blogging Software Update

Well, I still haven't chosen what blog software I want to use in a new home. So many to chose from and none are a perfect fit. The comments left by Scott Hanselman, Phil Haack, and Dave Burke were good ones and point out the connectedness of the blogosphere (is that word accepted enough to forgo the quotes now?)

Since I gave DasBlog such short shrift in my original post, I spent some quality time with it. DasBlog has some really strong points in its favor. For one, it has a very active developer community, though that isn't as apparent as it is with Subtext. DasBlog 1.9 was released today and I'm even mentioned in the release announcement (it's always nice to see your name in print--even virtual print).

I am leaning towards DasBlog now. Two bonuses of using it: no tricky database settings (it uses XML files stored in the web file system), and a really flexible plug-in system (they call them macros, but they're actually compiled .NET assemblies with a standard interface and config-file usage).

Not that I've decided to use it. Or not. I'm not generally this indecisive. I think...

 

Technorati tags: , , , ,
22. September 2006 18:38 by Jacob | Comments (0) | Permalink

Blogging Software

It's always the little things that chafe, you know? I mean, for the most part I'm happy with Windows Live Spaces, but there are little things that bug me from time to time so I find myself getting antsy. On the plus side, I like the modules and the freedom to place them where I want them. I like the book list (but I'd like it better if I could a) put it in the order I want and b) could rate the books listed there). I like my links.

But I find that I keep wanting things I get with more of a hosting service. I want more control. I'm a tinkerer, what can I say? So I've been looking at blogging software a bit. Since I have an account at Go Daddy, I'd like to find something that I can use there, and I'd like very much for it to be created in ASP.NET. It'd be nice if it was open source as well, if only so I can tweak and explore at my own capricious whim. Also, as long as I'm putting together a wish-list, how about if it could be programmed in ASP.NET 2.0? I mean, master pages and application themes with skinning support is, uh, lacking an appropriate white-guy expression, "da shiz".

The front-runners in the .NET space for blogging software appear to be SubText and DasBlog--both are branches from their progenitor .Text which appears to be defunct. Unfortunately, since .Text was originally ASP.NET 1.1, both SubText and DasBlog are rooted in that technology. They both support custom themes, but they had to hack ASP.NET 1.1 to do so--mostly with custom controls.

DasBlog

I was originally drawn more to DasBlog because I've become a fan of Scott Hanselman--first from his podcasts, Hanselminutes, but later to his blog (which actually uses DasBlog, kudos for eating the dinner you've made). He's one of those over-producers who seems to have his hand in on fifteen million things at a time and is able to simultaneously talk about it all.

However, DasBlog's main website is frequently down, and there doesn't appear to be a lot of action in the form of improvements, releases, news, or updates. Which makes me wonder if it isn't a dying product, suffering from Scott's hyper interests.

SubText

SubText is developed by another blogger I like, Phil Haack. Phil also lives in the house he built so you'll hear his experiences with SubText on his blog sometimes. I was intrigued to see him announce that SubText 1.9 has been released recently. SubText 1.9 is a project conversion to ASP.NET 2.0 so I was reasonably excited to see its release.

So excited that I went ahead with an install. It was a painful experience. Not because SubText isn't a pretty good product, but an install on a cheap Go Daddy account is a step or three down from the expected configuration. The main blockage is that while Go Daddy gives you dbo (owner) privileges on your database, you have highly restricted rights on the master database. Unfortunately, the install assumes that you can use a select on a master location to see if a table already exists and that select blew chunks.

One advantage of open source, though, is that someone reasonably competent (or simply lucky as is more likely my case) can dig through the install process and see what needs to happen. Since I could see that the table didn't exist, I ran the script manually. Unfortunately, since the install tracks installation stage in memory instead of checking the database, I ended up having to do the entire install manually instead of just that first step. Ouch.

So it was a hack, but it appears to have succeeded. I'm not entirely happy with the implementation, though, because while SubText is now ASP.NET 2.0, it doesn't actually use the new  master page and theme features. Those may be implemented in future, but since that's a relatively fundamental alteration, it would break a lot of things--particularly a lot of user-created theme files. Creating work for yourself is one thing, but making your users go back and re-do all the custom themes they so generously contributed to your project is going to be a hard sell when there isn't a well established benefit. Indeed, the roadmap implies that if it happens, it's at least two releases away (and frankly, 2.1 looks a little daunting to me and should probably be cut down some if they want to take less than a year with it).

SUB

One of Phil's more endearing traits is a kind of perverse generosity that led him to advertise for a competitor (while throwing down the gauntlet of course). Since I'm not entirely happy with SubText, I thought that I'd give SUB (Single-User Blog) a look-see.

Frankly, I like SUB. It's pretty simple and since it's done from scratch in ASP.NET 2.0, it has all the goodies I've been looking for and some I had thought of but didn't figure I could get.

Unfortunately, SUB has two draw-backs that make me hesitate. The first is that it is, as its title clearly states, single-user. One thing I came to like about SubText is that you can support more than one blog from an installation. Indeed, I was able to point both domains I had registered with Go Daddy to the same location, have them run the exact same files, and yet have each site perfectly individualized (it does this by checking the incoming URL address to know which blog settings to use).

The second draw-back has to do with my personal tastes in programming, so I'm going to leave that for another post.

So what?

I've no idea what I'll end up doing with my blog(s). Since one of them is a new one for Cawti, I'll have to make some relatively irrevocable choices really soon here. I'm feeling all Frankensteiny, thought, so I may just mash pieces of lots of different things together so I can terrorize intolerant villagers. Yeah, that sounds fun...

 

7. September 2006 03:44 by Jacob | Comments (0) | Permalink

Professional Integrity

Lidor Wyssocky has some good thoughts on why it is that developers don't implement changes that they know would be helpful.

The problem is that although we know exactly what doesn’t work right and how it should be fixed, most of us will never say anything. We don’t say anything because there’s a very good chance the minute we do we will be marked as uncooperative, pessimistic, or simply detached from the business reality. (emphasis in original)

He concludes with his call to action.

If more of us say what we know in our hearts to be true, the rest won’t be able to ignore it anymore. Hopefully.

And I agree with him. What he is talking about is an aspect of professional integrity. If you are a professional that a business relies on for good decision making, then you need to act the part and provide reasonable suggestions wherever they may do good.

But there exists both a flip-side and a problem with Lidor's points that are inherent in professional integrity that need to be explored.

The Flip-side

While you avoid negative attention by remaining silent about needed process change, you can gain positive attention by supporting whatever has caught the eye of your executives. This is a major contributing factor to "The Silver Bullet Syndrome". At XanGo for example, we had one company convince management that they could cut development costs to 10% of their current level. Not 10% off, mind, that's 10% of current levels.

Despite all logic to the contrary (I mean, think about it--if a product could actually deliver cost savings of 90%, every company on the planet would be using it--they'd be incompetent not to), XanGo ended up spending millions of dollars and wasted a full year of development on this silver bullet. What was most fascinating to me were those who were willing to endorse this silver bullet. Those people were promoted to team leaders and project managers. Any who would oppose the new development project were either removed before its introduction or told (in at least one case explicitly) that negative feedback would put their jobs in jeopardy.

In this way, technical people who should have known better ended up perpetrating the problem not by staying silent but by actively promoting bad solutions. They were rewarded for doing so. Here's the thing: in most cases, there really is no price to pay for backing a losing silver-bullet solution. Oh, those in front of the board have negative exposure when it all blows up. Some of the higher management tiers are at risk as well. But for most of IT, there simply is no bill to pay for being in the pack.

The Problem

Here's the thing: having Professional Integrity carries not-insignificant risks.

  1. Having integrity makes you predictable. Those with an agenda can plan their actions confident of what you will do. That means that if things get nasty, you end up following Marquess of Queensberry rules in a bar fight.
  2. Your compensation is in the hands of ignorant people. They don't know what you know. Many of them may be smarter than you. Even if they aren't, though, they are still the ones signing the paychecks.
  3. There is seldom a single, obvious best answer. Honest and rational people can arrive at differing conclusions based on the same information (because they weight aspects of the problem domain differently). This can easily split the message received by management and open the door for bad solutions. This also leaves you vulnerable to the manipulative because they can confuse the issue at need.
  4. Costs of bad solutions are often deferred while the costs of changing minds is immediate. Whether opposing a bad proposal or proposing a better process you are asking for change and that makes people uncomfortable. If you make people uncomfortable they will often hold you responsible for their discomfort.
  5. Sometimes having professional integrity means looking for a new job. Whether you are fired or are forced to resign, some positions are simply incompatible with maintaining professional integrity. These situations are rare, but they can happen.
  6. People aren't rational. As a result businesses often make choices that seem irrational. Sometimes those choices are right even though they are irrational. Professional Integrity in such a situation is problematic at best.

As I see it, Lidor's call to arms makes sense but is unlikely without more support. The thing is that the problem is bigger than he has acknowledged. He is asking us to take actions that are overtly risky and he hasn't given us enough of a reason to do so. I mean, the emperor may not have any clothes, but there's no telling how he'll react to you pointing that out.

The Solution Domain

"Because it's the right thing to do" resonates with most of us, I think. But it is important to acknowledge that, at heart, Lidor's plea is a moral and not a technical one. As such, it needs to be approached from a social, not a technical standpoint. The thing is, we are equipped to make this happen, but we need to explore it in the right context if we hope to make progress.

Societies have a lot of experience coercing correct behavior. There are a lot of tools available, some better than others. My preferences tend to flow from my LDS background. As such, I'd advocate proselytizing correct procedures. We should explain as clearly as we can the benefits of acting correctly. While the payoffs of acting correctly are long-term, they exist nevertheless and are provable and measurable. Professional Integrity in IT has similar long-term value (above and beyond correct practices) to businesses and those who learn to identify and value it will gain the benefits it brings. A company that hires professionals with integrity will do better than companies that hire similarly talented people who lack that dedication.

As long as we're borrowing from religious tradition, lets hit up the Catholics and/or Jews (leaving no stereotype unturned) and apply some well-earned shame. I know who sold us out at XanGo. My reaction to them in the future can (and should) be informed by their actions there. I think we do ourselves a disservice if we know compromised IT professionals and we don't tell them our opinion of their actions or make those opinions public. Repentance (more religious terminology, but applicable) should be possible, certainly--people can change and reformation should be encouraged. That said, it's important that forgiveness be contingent on honest efforts towards reparation and change.

On a more general level, ostracizing those who behave badly is one of society's greatest tools to restrain bad behavior. The next time I review resumes to evaluate new hire candidates, I'll have an eye out for those I know who, while they may be bright and talented developers, ended up endorsing those things that were bad for the business. More generally, I'll try to craft questions that explore a candidate's professional integrity in addition to their technical expertise. Reputations in IT should be more than merely technical. Professional Integrity is important not just to businesses but to the perception of IT as a whole. The IT crash in 2001 contained a lot of payback for abuses in IT during the build-up of the bubble. While we were on top many of us made unreasonable and expensive demands on companies (some personal, some technological) and those abuses weakened us as a group.

Collective bargaining is one route that I'm sure will come up--a union or standards body that enforces "correctness". Personally, I'm not a fan of that option. Bureaucracies are inefficient and tend to be in opposition to business interests. We do not need more antagonism from the executive suite. Unions also have a tendency to groupthink that I consider inimical to technology innovation.

I'm sure there are others that I am overlooking. I'd love to hear further thoughts in the comments. Please leave 'em if ya got 'em. Don't make me beg.

I acknowledge that my thoughts here will be hard to implement. They require conscious short-term effort with no promise of reward. It's certainly beyond the scope for a single individual to affect. Still, I believe it's possible to make things better than they are right now and that the potential for reward is both real and achievable. Plus, Paladins are made for exactly this kind of idealistic fight for what's right...

 

28. August 2006 21:23 by Jacob | Comments (0) | Permalink

Calendar

<<  March 2017  >>
MoTuWeThFrSaSu
272812345
6789101112
13141516171819
20212223242526
272829303112
3456789

View posts in large calendar