Are Business Apps Boring

Some here on wiki have characterized custom "business applications" as boring, repetitious slogging through endless CrudScreen applications, etc. These business applications include billing, tracking equipment, people, and projects, custom interactive reports, sales forecasting, billing anomaly warning systems, etc.

It seems many here prefer more "algorithmically entertaining" domains. Sure, business problems may have traveling salesman-type optimization problems every now and then, but for the most part it is about implementing domain-specific business rules as dictated to developers by users, managers, and marketeers.

In business applications, one is generally modeling managers' and marketers' (M&M) "rules of thumb" rather than intellectually challenging "puzzles" of the type seen in university courses in computer science. The M&Ms have difficulty expressing the rules of thumb. The software developer's job is to help them define and clarify such rules. Business knowledge is often implicitly understood, and it can be difficult for the domain experts to express that knowledge explicitly. This is one of the big challenges of business applications. Unlike university puzzles, the givens to the problems are generally not clear. There is often no easy way to tell if the machine is producing the intended results without having the end user try it for a while.

Sometimes software developers have sufficient expertise and influence to suggest changes in business processes to make them more logical or efficient. Presenting ideas to a business domain expert requires skilful sales technique. Otherwise, you risk coming across as arrogant or pushy. In the business world being liked is often more important than being right, but techies often see the reverse, creating a culture clash of sorts.

A truly repetitious domain can be automated, but that automation comes in frameworks that are often too complex, abstract, and/or open-ended for developers and/or management. In solving the general problem, they often fail to be specifically applicable without a great deal of rework or require detailed configuration (such as SAP), which makes them end up being "custom" anyhow in the end. Where the business would prefer their developers be swappable commodities, the expertise required to use the framework is a barrier.

Usually a business has many nitty-gritty rules and exceptions to rules that require spending significant time and effort to adapt the framework. The EightyTwentyRule is a rampant problem with most business domain abstractions. Exceptions to rules (abstractions) end up ruling the day. Copy-and-paste programming often seems easier than trying to make the Ultimate Generic tool/framework/library. Smaller scale abstractions, or micro-frameworks, can be more easily replaced without widespread impact.

While a well-designed general-purpose framework enables customization of rules and exceptions, the developers using it must be intimately familiar with it, interfering with the business management's desire to have interchangeable programmers of average or common skill. Specialization equals higher labor costs. Thus, there is a tendency to shun frameworks unless they become a certifiable commodity that HR can find in a jobs-board web search.

Good solutions to tough change management problems are difficult to discover. It is hard to find stable abstractions when the people who dictate requirements come and go in the organization or act seemingly capriciously. Applying abstractions from math and geometry is much easier because God does not change the rules. However, the Gods of Business flip all over the deck. Business culture is shaped by sales and/or politics, and selling and politics can generally be described as "intuitive" or "organic" disciplines. Thus, explicitness and "clean design" is often not expected and not honed by management. (Related: BusinessPatternIrregularity)

Business applications build up "cruft" over time. Business rules tend to keep collecting and collecting until the behavior of the system becomes unpredictable. Nobody wants to risk cleaning it because they are afraid something might break. Or, there may be a business rule in there that solves a problem that the current staff did not know existed. The knowledge of why specific code exists might be lost. Users expect the behavior to be there, and are surprised if it disappears. A programmer might remove something that looked like a bug, to later find out that it actually served an important but undocumented purpose.

Refactoring and other good maintenance techniques can reduce the rate at which entropy degrades a system. Good systems never degrade and actually get more powerful and more flexible over time. But, management can be resistant to refactoring and similar work toward these goals that is perceived as not directly or immediately having value.

More disciplined approaches like unit testing and more documentation perhaps would help, but these are often considered too expensive. It seems managers would rather live with the risks of leaky processes rather than pay for cleaner processes. Thus, one has to deal with a lot of stuff without much assistance. Some developers try to keep things clean to reduce future problems, but others just hack around until things work, not caring about future problems. As far as they are concerned, swampy cyber-land is job security, and it appears to pay off. In other words, the only reward for keeping things clean is a personal sense of satisfaction and comfort, not money.

Failure to keep the system clean is typical of poor programming practices. The benefits of keeping things clean are numerous, among them are easier programming, less code, more flexible system, and cheaper faster development. However, often there is no financial incentive for a given developer to keep things clean. They are judged from month-to-month rather than year-to-year. It may help the company, but the company will often not recognize the effort.

The challenge of programming in a business domain is mostly dealing with the interaction and expectations of humans as they relate to the machines. Whether one finds this boring or not probably depends on the person. Sometimes it is rewarding and sometimes it is boring, tedious, and frustrating as with most any jobs. Even rock stars get tired of drugs and sex at times.

Could not apply to HardCoreGeeks?, as everyone knows GeeksCantGetLaid? and thus would not properly balance the appropriate levels of boredom in said equation. Furthermore, I'd trade GeeykStardom? for bored rockstar any day. Sadly, my music has always been considered too much geeky and not enough mainstream. Go figure :)

Perhaps we should take this to TheAdjunct, but what does "geek music" sound like? Techno?

With many people working on many shallow apps, the idea of eliminating redundancy and creating a properly factored system is nothing more than a pipe dream. There are too many inexperienced programmers working on their own localized problems. We all see that refactoring would be beneficial, but the situation is too far degraded (FixBrokenWindows). Some of us tinker just enough to stop the whole stove-pipe system from collapsing under the weight of its own complexity. But until it does collapse, it it very difficult to argue we need a more mature capability - though it's getting easier as time goes by.

Part of the problem is that owners and managers cannot easily tell if people who claim to take the "clean, logical path" are for real or just yet another pie-in-the-sky snake oil sales group. They will consider that a cheap ball of twine with simple packaging is better than an expensive ball of twine with hard-to-verify claims on the packaging.

I have found business applications to be exciting in a way that is quite distinct from the computer research I had done before. In research I had the time to look for interesting problems. I felt productive when, in my best years, I averaged one interesting solution a month, a dozen a year. In commercial development I had to solve that many problems a day, and no, most were not interesting. The reason I say this is exciting is that there were occasional interesting problems. Using agile methods I could tackle the interesting problems as they arose and expect my solutions to be deployed. That deployed part wasn't guaranteed for research, but it was for applications. That made for a level of satisfaction that is hard to beat. Also, when I look back on my best years of commercial development I see that interesting problems (interesting to me anyway) came by every week or so. This is two to four times faster than my best rate in research. The trick to enjoying development is to be ready to work on the interesting problems when they do come along and to keep the code base clean enough that you can use the solutions when you come up with them. -- WardCunningham

From the man himself. While nowhere near as experienced as Ward, I find the same thing. I usually find a couple fun problems a week easily. When unavoidable redundancy creeps in due to languages' weaknesses, I automate that, which is fun in itself. In the meantime, I refactor and keep the code base clean and prepped for change. If you let your managers prevent you from refactoring, then I think you're telling them too much. Refactoring is simply a part of daily programming - it's not something they should even be aware of, let alone forbidding. If so, leave: greener pastures exist. All of these XP practices allow for rapid development, and as long as you're producing, managers don't care what you do.

Different places give one different amounts of leeway. I find that if something breaks that was not supposed to be changed to begin with, managers usually get upset. "If it ain't broke, don't fix it" is common in my experience. Over time one can build up trust, but that is about the time that you get a new manager and have to start over. As far as greener pastures, not much in this economy.

UnitTest and work in small increments. If you've got unit tests covering the code, then you'll know instantly if you've broken something. Then you can back out the code, if necessary, or fix it. The extra time spent unit testing (which is considerable in my experience - over 50%) pays off in being able to keep the code base clean and not having to track down bugs you just introduced. And if you end up going faster and creating more reliable code, who is your boss to complain?

Many places have boat-loads of existing code with no unit tests. One solution to this is to add tests a little at a time in order to support changes. Similar to CaptureBugsWithTests, when a change in untested code is requested, just write a test for the change. The new test will fail because the code doesn't support the change. Now the code is changed until the test passes.

If your software problems aren't interesting enough to you, you're not abstracting enough. (See also: BoredomIsaSmell) -- francis

I generally agree, but:

Managers often don't like too much abstraction for reasons given above
It is hard to abstract personalities, also described above. Even if you can temporarily, staff changes often toss prior rules in the trash.

It is true that being in a bad organization will prevent you from doing good work. It is not true that you're required to stay in an organization that would subject you to such treatment. Either ChangeYourOrganization or ChangeYourOrganization. -- francis

In my opinion, it is a losing battle. There is a certain "culture" to most businesses, and to find a good IT environment requires lots of searching and lots of luck. Plus, it spoils one. I have heard many stories of people working for great companies when suddenly there is a management overhaul, and it is back to the usual cruft and grind.

There tend to be two extremes of companies. The first type is "capricious sales-driven", and the other extreme is the lumbering bureaucracy. One is a mad-house of seemly random rapid change and the other is a mad-house of internal politics, red tape, and fiefdoms.

Yes, most companies suck. So what are you going to do about it? Are you going to take on the risks of looking for some sort of occupational happiness, or are you going to just let your working life be mediocre for the next few decades until you retire? -- francis

Past attempts at ChangeYourOrganization were not helpful to my career. Maybe bitter medicine will do them good, but just gives me grey hair and ulcers even if it eventually works. Life seems smoother if you go with the flow (WhenInRome). One may even change the company for the better, but still get booted out. I consider such beyond the scope of our duties. We can of course politely suggest changes, but it's not our role to become re-org zealots.

Speaking solely for myself here: I'm sure that writing "business" apps can be just as technically challenging and/or rewarding as other kinds of software, but I find that if I'm not interested in the problem domain, then writing software for it, no matter how interesting on its own merits, is about as exciting as doing housework. The software I work with touches real-time image and data acquisition and control, image processing, measurement and identification algorithms, as well as more generally-applicable elements like GUI, network and/or RS-232 communications, etc. I'm on a project right now to move some of the lower-level aspects of our products into an embedded module. I find that I need to "touch metal" at least occasionally in order to stay really interested. Other people, meanwhile, may really get a thrill out of UI programming, database-oriented stuff, etc. - the sorts of things that I perceive as being part of "business apps". More power to them; it takes all kinds. -- MikeSmith

Personally, I find that programming in general becomes boring after a while. I have done programming and management of programmers for 25+ years now, and I don't find a lot new. To keep the job interesting, however, I concentrate on learning new techniques for programming and on working with end users. Yes, the actual coding and debugging is an exercise in repetitive detail, but when the end users actually like the software when they receive it, that's what provides the lift. -- WayneMack

I used to do discrete-event simulation (in Smalltalk) of launch operations processes for the Titan IV launch vehicle. The production operations manager at Cape Canaveral was always concerned about the consequences of resource allocation decisions such as giving this launch pad to this mission, that transporter to that mission, etc. Due to constraints on resource allocation and random variables in the process, the possibility existed to blow the date of some future launch in a 25-mission manifest by making the wrong resource allocation decision somewhere along the line. That was fascinating work.

Then I got into a variety of things like customer care systems for cellular providers, hotel reservation systems, services procurement applications, etc. I didn't find the problem domains of those applications to be of much personal interest to me.

But in every case there were interesting challenges and tradeoffs in how to model the problem domain, how to optimize performance, how to persist data, how to architect the interface for usability, how to achieve reuse and consistency and team productivity, how to go about the development process, how to organize and manage the team, and more. Some of these are social in nature rather than technical.

I think boredom or interest is in the eye of the beholder. Even if a business application's domain is pedestrian, or its algorithmic complexity negligible, there are still complex problems to be solved in its development, not the least of which is getting a group of people with different backgrounds and personalities to work together effectively to achieve the goals deemed important to the development team (not to mention agreeing on those goals).

Kudos to whoever wrote the prologue on this page. I think it is pretty astute, and many points resonated with me.

-- RandyStafford

"...getting a group of people with different backgrounds and personalities to work together effectively...": Oh how boring. I don't want to be a manager (though it would be nice to be paid like one). I'm here to write code and develop applications. It's what I'm good at, it's what I'm paid for, it's what gives me a sense of satisfaction. If I'm managing the personnel, what are the managers doing?

The writer of the above may have been in a project management or semi-project-management role. Whether biz app development requires more interaction than other domains is hard to say.

Re: Personally, I find that programming in general becomes boring after a while.

I think anything becomes boring after a while. Rest and rotation would be nice. The problem is that HR wants gajillion years experience in the target occupation or specialty. That makes it difficult to rotate domains.

I've spent 80% of my career writing business apps. While the actual app itself may be boring (load data, display data, accept data, update data) the whole process of getting from "Senior manager has idea" to "customers booking holiday on website" is truly fascinating. Much of this process is completely independent of actual programming, but making that process work is a problem solving exercise requiring far more skills than mere programming. Of course, you also then get to program. The challenge of working with non-IT types in their world, and educating them (over many months) to understand how best to work with IT, while working within IT to change the IT organization, its structure, its processes and (most importantly) its working practices, all these things are (for some people) very enjoyable, and an interesting diversion to actually programming. They also make the relatively small 'coding' segment of a project much easier. So while business apps may lack the intellectual challenge of (e.g.) writing the software to guide a small probe into a Mars orbit, they do provide a combined intellectual and social challenge that continues long after the initial delivery. -- StuartScott

Whether you like the business domain or not, you may have to get used to it. The more a domain depends on the knowledge of physical processes such as physics and chemistry, the easier it is to offshore to a low-wage country. The laws of physics don't change across the Pacific. Being closer to the customer and decision makers means more business-oriented jobs will be available than "mother-nature" connected jobs.

Is this boring? Here are a couple of pieces of business apps I have written in the last year: (1) A logging system for a brokerage application that needed to be able to log new modules without additional coding - I needed to write a context-free grammar (in BackusNaurForm) for the log output, and to write code to generate and parse this output, which could involve deeply recursive structures. (We couldn't afford the overhead of XML.) (2) A small business rules engine that would have a very easy interface for our (very nontechnical) users - required an understanding of the problem domain, and the development of code (and parallel relational data structure) which accurately and compactly reflected the problem domain. Oh, yes, and it had to be done in a week.

Somebody brought up the topic of 3D animation compared to business apps. The 3D ani is harder to learn, and thus 3D software is allegedly "more complex". I happened to minor in 3D graphics in college and built a 3D graphics engine from scratch, so I do know something about it. I agree it takes longer to grok the domain of 3D animation than most business apps. However, the software itself is not simpler. Biz apps are indeed usually easier to get the general gist of; one does not have to take tons of courses to understand the basics of a given business process.

However, the devil is still in the details. In 3D software, the basic concepts are not that difficult once it clicks, but implementing them and tuning such software for speed gets into a lot of nitty gritty. The same is true of biz apps; when you get into the details is it similar kinds of nitty gritty. (Although CPU speed is usually less of a concern, performance over a network is still a bugaboo at times.) If somebody has knowledge of magic generic biz algorithms, patterns, or equations that simplify it all, they have not publicly documented how to do such, so I shall assume they would get bogged down in the nitty gritty details also. Often there are patterns to stuff to simplify some of it, but the EightyTwentyRule tends to step on such endeavors, or at least heavily taints the payoff. -- top

Excellent points. I think the major reason we don't see magic generic biz algorithms, patterns or equations that simplify it all is due to the move in recent years to patent business processes. As an architect/developer I was encouraged to submit such patent applications. I refused - being against software patents on principle. I saw many of my peers get patents for crazy things (I'm sure you've seen some of them in the news). What isn't patented is generally marked as proprietary - so disclosing these things is a definite career ending move. - AnonymousCoward

CategoryBusinessDomain