Encroaching out of functional boundary...

 

Going out of one's functional boundary is not so uncommon. Will like to site an example which resulted in not so good outcome.

Different teams provide very useful functional inputs while backlog grooming. But many times they provide inputs close to release, which is fine given it follows the process.

I remember once multiple QA's huddled around me and were trying to arm twist me in changing a UI flow which 'they thought' was right. I didn't negate the suggestion, but requested them to check with Product Owner. To my surprise they wanted the change to happen then and their !!!! . Thankfully I held my position.

But many developers are not like that. In one of my earlier project, something similar happened, where QA reported a UI error message appearing in an unexpected flow. On analysis found that error message was not required at the first place.

Dug further and was surprised by the reason - A recent guideline was given to QAs to ensure unit test code coverage for the functional areas marked as critical. (Not sure how QAs can track unit test coverage ? )

Blindly following that policy they asked for the code coverage for a negative flow, which was not practically possible. And hence an error message was specifically added, to ensure what QA called a proper code coverage !!!! ahem... !!!

Obviously the developer should have stood her ground. But to make things worse even the team architect approved the approach. Result - A wrong UI error message.

Not sure if a single person can be blamed here, but overall teams should always take a firm stance when someone is trying to encroach out of their permissible limits. Not because of pride issues, but to ensure correct meaningful output.

Reinventing the fire...

I don’t have much insight if there are indeed other tools better than Maven. But one thing I know is Maven is very stable tool, with lot of plugins and community efforts to get any build related flow. And there are ways to increase the overall speed, by using multiple threads.

Recently, while discussing with a friend about technology and office culture, topic came up about his company in the process of shifting build tool from Maven to another new build tool.

Being in technology field long enough to see the pattern of re-engineering, when it’s not needed, first question I had was ‘why’.

“Better Speed” compared to maven to alleviate issues like build taking multiple hours, developers blocked for days just to check-in single line of code etc etc … , was the answer.

In further discussion realized that problem was not the tool, but a huge monolithic build which included 

400+ modules, some taking 12+ minutes to build, all of them build together even though no compile time dependencies even if 299th module build failed due to any reason, all modules were built again. any integration test failure lead to all 400+ modules getting built again.

If the situation feels similar to yours own, I feel sorry for you.

I don’t have much insight if there are indeed other tools better than Maven. But one thing I know is Maven is very stable tool, with lot of plugins and community efforts to get any build related flow. And there are ways to increase the overall speed, by using multiple threads.

Further, new tool came with its own set of limitations. Just for instance, firing unit test itself can be a pain. Involves writing separate build target for each unit test etc !!!!! Now there might be ways to get around it, but why to even get into such situation for wrong reasons?  

re-engineering, when it’s not needed

Simple, long term, more effective solution to the build woes could have been:

1. keep compile time inter-dependencies to minimal (use interfaces with solid contracts, a design paradigm which is more than decade old)
2. Break the build to smaller builds
3. Don’t recompile the modules on integration test or other unrelated failures.
4. Don’t hold the ‘code check-in’ for integration tests .

Somehow these things are not taken up for a task. But… Let’s use new build tool, let’s reinvent ...

Techies love their toys

Techies love their toys; they want to learn and try new stuff. But that should be a personal learning cycle, a PoC maybe, for a new project. Don’t try things in production releases, someone needs to put a break to such behavior… That’s where delivery focused technically involved managers comes in. To reason and guide the effort in right direction, not necessarily killing it.

PS: I know fire was not invented; but discovered :) . But just a catchy title ...