Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Happy Flow Overfocus

DZone 's Guide to

Happy Flow Overfocus

A description of Happy Flow Overfocus and how to use its powers for good.

· Agile Zone ·
Free Resource

You Found a Rocket and It's Mighty Fast

I guess we all experienced it once: you have this hot, cool new framework. You just start coding, and in a couple of hours, you have something that not only runs, it really does something useful, but it also looks good and feels good.

In just two days you pounded a nearly finished product together, and demo it. Your co-workers say "ooh" and "wow". Your manager gives you a pat on the back, you saw the dollar signs dancing in the eyes of Marketing. You are glowing with pride.

Why the hell were you wasting your time all these years, with all these stupid old junk frameworks you used so far?
It is so much work, so old-fashioned, so clumsy, compared to this.

When asked an estimate for a production version, you said: "This took me just two days, I expected four. So give me the rest of the week to tie things up and we'll be fine." You get to work.

Then... the Rocket Fizzled Out

Suddenly, things don't go so fast anymore. It seems as if the thing just resists change. Each little thing you want to improve, breaks. You need to rewrite entire blocks of code in a different way, very verbose, zero elegance, or ram some rusty nails through it, which you know will stick out on the backside and hurt you later. Code fragments get scattered everywhere. It becomes a jungle and despite the framework's cleverly ordered structure, you keep forgetting what you put where.

After two weeks, planning comes asking how it's going. You know, we promised the customer...After a month, you are still working on it. For each to-do solved, you get two new ones. It wears you down. By now that proud manager comes wondering whether it was such a good idea to use this cool new framework of yours. Finally, after two months, you demo the results to the customer. Everyone is relieved it's done, but you can just feel their looks.

What is wrong with this framework?

Maybe the better question is: what is wrong with your expectations of technology? What we are dealing with here, is a case of... (drum roll)

Happy Flow Overfocus

Writing the part of the code that describes the normal behavior of the software, the happy flow, is 20% of the work. That is the part where life is still simple. There are many excellent frameworks that make you do that spectacularly fast. The real work is in the dull 80%. Error handling, exceptions, validation, performance, optimizations, security, configurability, setup, breakdown, robustness, edge cases, testability, customizability.

Overall, halving the happy flow work is a modest gain on the total project, but people remember it well because it was fun to do, it felt like racing from zero to demo in a hackathon rocket.

More often than not, rapidly-built happy flow code is full of hard assumptions and doesn't bear change very well, causing the dull part not to be 80%, but rather around 160%.

Figure 1: Happy flow overfocus. Initially, the project appears to go twice as fast with the new framework.

Happy flow overfocus. Initially, the project appears to go twice as fast with the new framework.

Worse, it gets full of duct tape, quick-and-dirty tricks, nasty hacks, and entanglement to prevent messing up that touch-sensitive happy-flow code too much. Which you admit is not OK, but you're really going to clean it up, someday, promise. When that day comes, refactoring the happy flow and untangling this dull 160%, it seems that each piece of tape you removed, kept a can of worms shut that is now crawling all over the place.

When searching for a framework to increase developer productivity, happy flow overfocus is a huge risk. When you search a framework for rewriting something from scratch, happy flow overfocus is practically inevitable.

This overfocus is so persistent because developers can clearly imagine what the happy flow is going to look like. Imagining the dull part is a lot harder, and just... dull. Therefore, as a developer you push it out of your "awareness zone" and into the "do later zone" so that you can focus.

How to Deal With Happy Flow Overfocus?

It basically comes down to being realistic about what a coding technology can do for you. Whether you use rapid frameworks or not, the dull stuff is the same, because it's work that the frameworks do not cover.

For Developers:

As a developer, you should be aware that frameworks that are good at rapid prototyping, do so by making many trade-offs that make your code rigid.

You should consider a framework where the happy flow takes a bit more work but gives you much finer-grained control. Then, writing the dull part gets a lot easier, and this is most of the work. Overall, you will be done quicker.

And no corner cutting. Please. You only make it worse.

Corner cutting impresses noobs, but burdens everyone else.

For Architects:

As an architect, raise awareness in developer teams when, how and why happy flow overfocus is happening, at the cost of maintainability.

Developers start working on the dull part with their mind still on the pride and excitement of high-velocity coding and not having to think too deeply about coding decisions. They apply hacks and corner-cutting, often without realizing how much harm is done.

When such hacks backfire, developers work around them. Rewriting feels slow and wrong in a "rapid" environment.

Completing the project becomes much harder than necessary.

For Business:

If you think the demo looks finished, believe the developer who says it's still a lot of work.

Happy Flow as a Marketing Tool

Happy flow is not just a part of the functionality; it's also how it feels to write it. Marketing cleverly tries to induce happy flow to overfocus, to lure developers into adopting a framework.

Did you remember the framework's home page? Did it have flashy cartoons of developers in speedy situations, such as skateboards, naked bikes, slingshots and rockets with flames? Did the "get started" demos look stunningly simple and elegant? Compare this what your code looks like now. See my point?

Realistic Planning to Prevent Happy Flow Overfocus

For a robust, production-ready version, you can't deliver without the dull part. How to plan?

Finished happy flow in...

Expect dull part to be...

expected time

4 x happy flow time

half the time

8 x happy flow time

half the time with corner-cutting

16 x happy flow time

Observe the treachery. The faster the happy flow is programmed, the higher everyone's expectations for the rest, and the bigger the disappointment about how long it really takes to finish.

You would be far better off with a framework that adds productivity to the dull part, than a framework that speeds up the happy flow.

Conclusion

Whenever there are frameworks, there also is happy flow overfocus. The faster the happy flow was built, the more time you should plan for the dull part.

Topics:
frameworks ,time saving ,happy flow overfocus ,agile

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}