Bangalore builds more software than almost any city on earth, and its engineers complain about the same nine things in every caf\u00e9 from Indiranagar to Jayanagar: slow builds, jammed reviews, endless queues, weeks lost to setup. The fixes are less mysterious than the complaints. A working method called DevExOps treats developer experience as something a team measures and improves on schedule, the way fleet operators treat fuel and downtime. Below are the nine habits that make up the method, written for anyone who runs a team, writes about one, or just lives with an engineer who vents at dinner.<\/p>\n
The nine at a glance, before we take them one at a time:<\/p>\n
The reflex is to purchase: a faster build machine, another plugin, a bigger licence. Resist it until the friction has been named. Slow builds, CI queues, review delays, and baffling tools are all measurable, and the cheapest instrument is a question asked out loud. Gather the team, list every place the day leaks, and only then decide which leaks deserve money. Half of them will turn out to need an owner, not a purchase \u2014 a rota adjustment, a retiree’s script finally rewritten, a capacity setting nobody had revisited since the team doubled in size.<\/p>\n
Averages flatter broken systems. A pipeline that finishes in four minutes half the time can still hostage a change for fifty minutes at the slow end, and the person stuck there gains nothing from the median’s tidy appearance. Report the middle and the slow end together for build answers, queue waits, and first review response. As that spread grows, the system is growing a tail \u2014 and tails, not averages, are what people complain about at dinner.<\/p>\n
The whole method compresses into four moves: find the friction, measure it two ways, hand it to a named owner, verify the fix against a bar set in advance. Run that sequence every quarter and write the results where the team can see them. The term is young \u2014 the DevExOps page in the Ops Atlas<\/a> is where most teams get the working definition \u2014 but the loop itself is as old as good maintenance: diagnose, repair, test, sign off.<\/p>\n Two instruments keep each other honest. System timers record what happened: how long the queue held a change, how long the build took. A short, stable survey records how it felt: which tool fights its users, which wait ruins the afternoon. When the two disagree, investigate the disagreement itself \u2014 often the pain hides in the slow tail that the averages buried. Keep the survey identical from round to round, run it every three to six months, and report the share of favourable answers along with the response rate so nobody mistakes a quiet room for a happy one.<\/p>\n Nothing exposes a messy engineering culture faster than a new joiner’s calendar. Pick one number \u2014 days from start date to first merged change \u2014 and track it like uptime. Weeks spent assembling a development environment from stale notes is friction with a start date attached, and it is fixable with a script and a corrected guide. Teams that measure this number tend to fix it fast, because the number embarrasses the setup, never the newcomer. A sensible ambition is a first merged change inside week one; if the calendar says otherwise, audit the setup guide before you audit the person.<\/p>\n This habit is the difference between measurement and surveillance. Results aggregate to teams and personas; individuals stay unnamed; groups smaller than about five people are suppressed from every report; and the data never, ever feeds a performance review. Write those three rules into a one-page policy before collecting anything. Break them once and the surveys will return polite fiction forever afterwards.<\/p>\n Shipping a change is not the finish line; it is the start of the verification. Before any fix begins, write down the number that will count as success and the measure that will prove it. Afterwards, compare honestly \u2014 including the awkward outcomes. On small teams the intervals are wide (an apparent 18 percent improvement might plausibly be anywhere from 6 to 44), so ask the direction to hold across two cycles, or pool adjacent teams, or stage the rollout so half the groups go first. A fix that survives that gauntlet is real. One that does not was a coincidence with good timing.<\/p>\n A developer’s day has a tight cycle \u2014 write, run, correct, repeat \u2014 and a longer relay of pull requests, automated checks, human review, and deployment. Typing is rarely the problem; the gaps between steps are. Track each gap separately, because they answer to different people: build durations belong to the toolchain, queue durations to capacity settings, review waits to team habits and rotas. For readers who want the deeper operational backdrop, the site’s guide to site reliability engineering fundamentals<\/a> explains the production side of the same story, and the beginner’s path through AIOps training and careers<\/a> shows how automation now watches those waits for you.<\/p>\n Empty ritual is a real cost. If the group is tiny enough that a single frank retrospective reaches everything, keep the retrospective and drop the formal loop. If no decision-maker will spend money or attention on what you find, measuring just writes the neglect down. If trust has collapsed, repair that first or the surveys will flatter you. And whatever you do, resist the single grand “experience score” \u2014 one aggregate number invites gaming, hides more than it shows, and gives leadership a target nobody on the ground believes in.<\/p>\n Underneath all nine sits one behaviour: treating engineers’ time as worth measuring. Teams that adopt these habits stop arguing from memory and start arguing from clocks, and the arguments get shorter. When several teams share tooling, when a big investment needs a baseline, or when the complaints stop matching each other, the loop above is the tool that settles it. Enterprises that want outside help installing the habit often begin with a consulting engagement built around faster delivery<\/a>, and that is fine \u2014 just insist the engagement leaves behind the nine habits, not just the report. Measurement is not bureaucracy. Done this way, it is simply the city’s favourite virtue \u2014 plain, practical, no-nonsense \u2014 pointed at the people who build the software everyone else lives on.<\/p>\n","protected":false},"excerpt":{"rendered":" Nine practical habits from the DevExOps method: find the waits, watch the slow tail, verify fixes against a bar, and skip the empty ceremony.<\/p>\n","protected":false},"author":9,"featured_media":6356,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4894],"tags":[],"class_list":["post-6355","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technology"],"_links":{"self":[{"href":"https:\/\/www.bangaloreorbit.com\/blog\/wp-json\/wp\/v2\/posts\/6355","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.bangaloreorbit.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.bangaloreorbit.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.bangaloreorbit.com\/blog\/wp-json\/wp\/v2\/users\/9"}],"replies":[{"embeddable":true,"href":"https:\/\/www.bangaloreorbit.com\/blog\/wp-json\/wp\/v2\/comments?post=6355"}],"version-history":[{"count":1,"href":"https:\/\/www.bangaloreorbit.com\/blog\/wp-json\/wp\/v2\/posts\/6355\/revisions"}],"predecessor-version":[{"id":6362,"href":"https:\/\/www.bangaloreorbit.com\/blog\/wp-json\/wp\/v2\/posts\/6355\/revisions\/6362"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.bangaloreorbit.com\/blog\/wp-json\/wp\/v2\/media\/6356"}],"wp:attachment":[{"href":"https:\/\/www.bangaloreorbit.com\/blog\/wp-json\/wp\/v2\/media?parent=6355"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.bangaloreorbit.com\/blog\/wp-json\/wp\/v2\/categories?post=6355"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.bangaloreorbit.com\/blog\/wp-json\/wp\/v2\/tags?post=6355"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}4. Pair the Survey With the Stopwatch<\/h2>\n
5. Count Onboarding in Days, Not Vibes<\/h2>\n
6. Report Teams, Never Individuals<\/h2>\n
7. Let DevExOps Verify the Fix<\/h2>\n
8. Know the Two Loops and Where They Stick<\/h2>\n
9. Skip the Ceremony When It Adds Nothing<\/h2>\n
The Habit That Ties the Nine Together<\/h2>\n