Standard Tool Dependancy

Based on NodeJsAndHofDiscussion

• Shouldn't one add one's comments to the correctly spelled page at StandardToolDependency??

• Probably, but this one got all the discussion momentum and the misspelling makes it friendly and familiar, like an old sweater that's all comfortable and cozy despite (or, maybe, because of) the holes.

There seems to be a general pattern in these discussions. I generally believe that our typical supporting tools in CBA take care of a lot of issues that SystemsSoftware-oriented people think about more heavily. For example, the RDBMS takes care of a lot of parallelism, concurrency, and persistence issues. Web servers similarly. And (good) GUI systems make the most commonly-needed GUI activity either declarative or simple to code such that we don't have to write grunt code to micromanage a lot of that.

However, this kind of fell apart with the HtmlStack such that we are forced to deal closer to the bare metal and/or antiquated standards, taking us out of our comfort zone. I'm arguing the industry should "fix" the fucked-up client to give us back our friendlier and safer tools that we are used to having, while you seem to be saying that one should live with or embrace the need to deal with the guts and low-level issues, and get/use more powerful and/or more "meta" languages to help us roll-our-own SystemsSoftware-like services and tools.

We CBA'ers want to glue powerful services together to deliver custom apps easier by focusing on the biz logic instead of infrastructure; but you are saying it's better to be closer to the guts of such tools and services both to gain incremental performance advantages and to better handle the occasional case that the industry messes up the tools (like the fucking HtmlStack) or when new trends come along before the standardized services/tools are ready.

It also allows some who are very adept at the guts to get fine-tuned performance and control over both resources (CPU & network)and control GUI subtleties. Whereas the standardization approach levels the playing field with "adequate" services, protecting the dullards by handling most of the hard or risky parts for them, but not allowing the cream of the crop to raise to the top because they are saddled with B-minus standards weighted down with safety padding to encourage consistency and prevent driving outside the lines.

It's almost like a conservative versus progressive viewpoint. The progressive wants the "government" (standardized tools) to create a safety net and provide commonly-needed services to society so that we can focus more on living rather than on not dying.

But the conservative believes that battling in the fast-changing, rough-and-tumble, dog-eat-dog world of capitalism makes one wiser and hardier. It's not "reinventing the wheel", it's "competition".

Each side views the world and human-nature differently such that there may likely never be agreement.

--top

Yes, you like databases, and think they can replace a lot of other stuff, we get it already.

It's not just databases, it's web servers, file systems, GUI engines, and perhaps other new "common" services down the road, such as content indexers. -t

[Management and users always want something faster, flashier, smoother, more distributed, more decentralised, more mobile, more social-network-ified, more whatever than previous applications. This is because faster, flashier, smoother, more distributed and so on are seen to deliver competitive advantage. (Obviously, it doesn't matter whether they actually do or not.) Inevitably, that means straightforward integration of mainstream, off-the-shelf, don't-do-anything-fancy databases, web servers, file systems, GUI engines, etc., simply isn't enough to differentiate your application from the average, let alone be considered a "market leader" or "state of the art" or "cutting edge" or whatever management demands. Therefore, for many custom business application developers, systems programming and custom business application development are now indistinguishable.]

I have to mostly disagree. Maybe naive management will chase something flashy, but experience will eventually tell them that chasing the latest and greatest is not the economical way to set up in-house apps. Now maybe something that is public-facing may need to be snazzed up to keep up with fads, especially if you sell to the youth crowd, but that depends on the organization. And still they may rent or hire specialists in Snazz-Foo Whackadoodle 5000 to achieve it. My background is mostly in "back-room" apps that track and report on internal processes and objects, and thus I am not currently at the cutting edge of UI's. I will agree that the cutting edge may closer resemble SystemsSoftware because you have to deal more with the guts of hardware and/or flaky new technology that has yet to mature and yet to be packaged into something standardized and more easily digestible. The cutting edge indeed tends to require more low-level control and machine-centric fiddling. I remember in the mid 90's web apps had to create their own HTTP headers and user session tracking, among other things. Now it's built in to the "web languages" and/or IIS/Apache. I generally prefer dealing at the biz logic level than tweaking servers to squeeze out a 15% improvement in performance or make the dancing avatar dance 15% smoother, especially if only 7 people will notice. Lack of features is usually the biggest complaint for in-house apps, not speed (if you plan the DB side right up front). I follow what the "customer" is concerned with and focus my thinking efforts there, not what I personally think is "cool". (I admit to adding occasional MentalMasturbation to apps, but don't pretend I am doing anything important or critical.) -t

[IT is multifarious, no doubt about it. There are developers who write COBOL for GreenScreen monitors. A friend of mine hand-optimised x86 assembly language used to scroll and zoom multi-terabyte image files. Both are custom business application developers. "Custom business apps" is a broad church.]

The assembly thing sounds like a technology company hiring a graphics programming specialist. I don't see a reason why a typical company would ask for such unless it's part of their line-of-business (primary domain). If it's part of their line-of-business, then it's a graphics application first. I believe my working definition would cover that situation from another angle, but I'll have to find it again. I could be wrong, but it sounds like there's more to the picture than the description (no pun intended).

It's difficult for a typical programmer to master low-level graphics guts and assembler, and then abandon it for a few years to do CRUD stuff in C-sharp and Java, and then go back into assembler etc. It's a long time to be away from such details. There are some who can pull that off, but I don't encounter many. Developers tend to either be "bit heads" or "domain heads" and prefer one or the other. The so-called bit-heads like the feel of being close to the hardware or OS. However, they tend not to relate to business and business people because they think technology first and domain second out of nature. You ask them a question about design and options and they rattle on about possible technical solutions too early in the game or at the inappropriate time. They just naturally gravitate toward the lower-level layers of abstractions (which is not necessarily the same as lower abstraction). They tend to work in the embedded world. -t

[The majority of business people do not distinguish one developer from another. The average business manager only knows she needs a system to keep track of these purchase records, or needs a tool to help identify suitable helicopter landing places in those image files, and she needs a programmer to build it. Certainly some programmers are generalists and some focus on particular specialisms, and some are highly technical and others are less technical, but "custom business application" developers are identified by only one common characteristic -- the ability to relate to business and business people. "Custom business applications" are identified by only one common characteristic -- a specific business need that isn't met by a pre-existing application.]

It's rare to need assembler-level graphics for run-of-the-mill business needs. I'm still skeptical of that anecdote, at least as a common or likely occurrence. My working definition implies interchangeability of CBA developers to some extent. You couldn't pull a random CBA developer from elsewhere in the org and have them work on assembler graphics. You can create your own working definition of CBA, and I'll stick with mine. Viva La Difference (pardon my french).

[Sure, assembler-level graphics is certainly rarer than, say, custom inventory systems. But it's probably not as uncommon as you think. For example, I recently helped submit a bid to develop a custom business application for a warehouse that would use augmented reality on mobile devices to highlight inventory items on a shelf and then use videogame-like interaction to select them. Gamification (http://en.wikipedia.org/wiki/Gamification) is on the rise, and will continue to push technologies into custom business application development that haven't been seen there before. Beware of narrowing your definition of CBA to exclude what it actually is, and only include what you know, what you do, what you are comfortable doing, or what you think is common.]

Until those things become "mainstream", generally a contractor or implementer is hired/rented who specializes in such. Now granted, it may interact with an internal/local system such that internal developers may also be involved to say help hook it into the existing inventory system, but they are not going to be soldering chips into visors or fiddling with its embedded code.

[Contractors have always been hired when a necessary skillset isn't available in-house, and I'm sure that won't change in the future. I remember when contractors were hired to wrangle that newfangled "SQL" -- which was surely a passing fad -- when any real custom business application developer either used VAX Rdb/RMS or dBase III and (of course!) it would be that way forever.]

One thing that is fairly common is somebody who "moonlights" as a CBA developer but has another specialty that they go in and out of. For example, he/she may be a game developer or trying to get into game development, but do CBA to pay the bills in the meantime. It's comparable to other fields such as fashion where everybody and their dog wants to be a fashion designer, but because the competition for that position is stiff, one may become a fashion pattern maker, garment materials procurement manager, etc. to keep a foot in the industry.

In another case I've seen, a developer pulled some GoldPlating to install an AI system when AI was over-kill for the actual needs. It was pretty cool, until they left and nobody was around to maintain it.

[Yeah, that happens. It's still true that "custom business applications" are most accurately defined as "applications" for "business" that are "custom". Any other arbitrary constraints on the definition are inevitably inaccurate.]

See: ArgumentsForRefactoringThatMakesSense -- DonaldNoyes.DoingStuff.20130117

And CustomBusinessApplicationDefinition. -- top