The Thing Stopping AI Agents at Your Company Isn't the Technology

Every week I talk to leaders who are frustrated with AI. They bought the tools. They paid for the subscriptions. They announced the initiative at the all-hands. Six months later, nothing moved.

Most of them have the same diagnosis: the technology isn't ready. The models need more work. The integrations are too complex.

My diagnosis is different. The technology is fine. The leadership isn't.

The Numbers Are Uncomfortable

The 2026 State of AI Agents Report lists the top three blockers to enterprise AI adoption:

1. Integration challenges: 46%
2. Data quality requirements: 42%
3. Change management needs: 39%

Read those again. All three are people problems.

Integration challenges aren't solved by better APIs. They're solved by leaders who get the right people in a room and make a decision about architecture. Data quality issues don't fix themselves. They require someone with authority to say "this is a priority and we're resourcing it." Change management? It's leadership, full stop.

MIT's State of AI in Business 2025 found 95% of enterprise AI pilots fail to deliver measurable business impact. Not because the technology broke. Because the organizations weren't ready to use it.

Only 11% of organizations are running agentic AI in production today. 38% are still piloting. The rest are stuck at "exploring." The gap between piloting and production is not a technical gap. It never was.

What Leadership Failure Looks Like in Practice

I've seen this pattern enough times to name it:

The CTO picks a vendor, signs a contract, and announces AI is coming. The team gets a demo. Someone spins up a trial account. A few early adopters use it with enthusiasm for two weeks. Then the energy fades and everyone returns to what they were doing before.

Why? Because nobody asked:

• What process are we changing?
• Who needs to work differently, and how?
• What does success look like in 90 days?
• Who is accountable for the result? One person, not a committee.

Brent Collins at Intel said it well: "Don't simply pave the cow path." Most companies deploy AI agents on top of broken processes. The agent automates the dysfunction. Then leaders wonder why the metrics are flat.

Harvard Business Review's research found 45% of executives reported AI ROI below expectations. Only 10% exceeded them. The barriers weren't technical. They were:

• Uncertainty: employees lack foundational knowledge, which creates two useless camps: people who think AI is magic and people who think it's worthless. Neither group uses it well.
• Fear of replacement: workers drag their feet on AI training when they suspect the tool is there to eliminate their jobs. Nobody explained the real purpose.
• Status loss: senior engineers hide their AI usage because it feels like admitting weakness. Experience-based authority gets threatened when a junior with the right tools outperforms a veteran.
• Resource hoarding: successful divisions keep their models and datasets locked down instead of sharing.

Not one of those is a technical problem. All of them are solvable with deliberate leadership.

The Change Management Trap

When most organizations hear "39% cite change management as a blocker," they translate it to "we need better communication." So they run a few lunch-and-learns and call it change management.

It isn't.

Real change management for AI adoption means:

Redesigning the workflow before the agent arrives. If you automate a bad process, you get a faster bad process. The ROI evaporates. Deloitte referenced Henry Ford on this point: many organizations are busy finding better ways of doing things they shouldn't be doing at all. AI amplifies this problem if you skip the design phase.

Making AI use visible and rewarded. When people hide their tool use out of shame or fear, the organization loses the feedback loop needed to improve. Celebrate what works. Name it. Share it.

Giving people permission to fail while learning. A team trying new things will make mistakes. Leaders who punish those mistakes get teams who stop trying. You will not get adoption without psychological safety around experimentation.

Connecting the initiative to outcomes employees care about. Not "the board wants AI ROI." Something like: "we want to eliminate 400 hours of data entry per month so you have time for work worth doing." The framing lands differently.

The Engineer's Role Here

If you're in an engineering leadership role, there's a specific trap worth naming: the tool-selection trap.

It's easy to spend your energy evaluating models, comparing APIs, and benchmarking latency. The work matters. But it's not the reason your AI initiative will fail or succeed.

I've worked through building AI agents with clients and partners. In roughly half the cases, the first thing a client wanted to automate was not the most valuable thing to automate. The technology was ready. The business thinking wasn't. The real work was a two-hour whiteboard session figuring out what the actual problem was... and whether an AI agent was the right solution for it at all.

It's a leadership conversation. Not an engineering one. Engineering leaders who learn to run it get far better results than those who go straight to implementation.

What the Teams Getting It Right Do Differently

The organizations getting real results from AI agents share a few things in common. None of these are difficult to understand:

They start with a problem, not a product. Not "let's use AI." Instead: "we spend 400 hours a month on X and it's costing us." Then they ask whether AI is the right solution for X.

They make the process legible before they automate it. If only one person fully understands how something works, an agent will fail inconsistently and nobody will know why. Document the process. Test it manually. Then automate.

They set specific targets. Not "use AI more." Something like: "By Q3, 80% of customer intake forms go through the agent without human review." A target you measure toward.

They assign a single owner. Not a committee. One person. Committees hold meetings. People ship.

Before You Buy Another Tool

Ask yourself one question: does your team know why you're doing this, who owns it, and what success looks like in 90 days?

If the answer involves a pitch deck and a Slack channel, you're not ready to scale. You're ready for more failed pilots.

Deloitte estimates over 40% of agentic AI projects will fail by 2027. The reason won't be the models or the APIs. It will be organizations automating the wrong things, with unprepared teams, no clear owner, and no shared definition of what winning looks like.

The technology is not your bottleneck.

If you're an engineering leader, this is your moment to step out of the tool-selection role and into the organizational design role. The teams winning with AI are the ones whose leaders asked hard questions before signing the contract.

What questions haven't you asked yet?

Agile was created to cut through bureaucracy. Somewhere along the way, it became the bureaucracy.

The Ritual Nobody Reads the Manual For

Monday morning. 9am. Your team logs into the standup. Someone goes first: "Yesterday I worked on the payment service. Today I'll continue on the payment service. No blockers." Thirteen minutes later it's over. Everyone goes back to their desks and does exactly what they were doing before.

You've run your Agile ceremony. You haven't done a single thing the people who wrote the Agile Manifesto intended.

What the Manifesto Says

In February 2001, seventeen software developers met at a ski lodge in Utah. They were fed up with heavyweight, document-heavy processes crushing engineering teams. They wrote four values:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Read those slowly. Now look at your sprint process.

How much of your ceremony is about processes and tools? How much of your definition-of-done is comprehensive documentation? How often do engineers wait for a refinement session instead of picking up the phone and talking to a customer?

The manifesto's twelve principles include: "Working software is the primary measure of progress." And: "Simplicity... the art of maximizing the amount of work not done... is essential."

Story points. Velocity charts. Capacity planning spreadsheets. Sprint burn-up graphs. None of those are in there.

How We Got Here

I've led engineering teams for years. I've watched the same pattern at every organisation claiming to have "adopted Agile."

Step one: hire a Scrum Master or Agile Coach. Step two: set up Jira. Step three: run two days of training. Step four: start doing two-week sprints with all the ceremonies. Within six months, the team has more meetings than they had before. The ceremonies multiply. A daily standup becomes a standup plus refinement plus sprint planning plus a demo plus a retrospective plus an ad-hoc sync because the planning went sideways.

A methodology created to cut through bureaucracy has become its own bureaucracy.

I spoke to a senior engineer recently who told me their team spends roughly one full working day per week in Scrum ceremonies. Twenty percent of engineering time before anyone writes a single line of code. Their deployment frequency? Once every six weeks. Their lead time from idea to production? Four months.

Not Agile. Scrum theatre.

The Stats Are Uncomfortable

A 2024 study of 600 software engineers in the UK and USA, reported by The Register, found software projects adopting Agile practices are 268% more likely to fail than those without it. The same research found 65% of Agile projects fail to deliver on time, within budget, and to an acceptable quality standard.

These numbers shock people. They shouldn't.

The problem isn't Agile. The problem is what passes for Agile in most organisations. Strip away the mindset, keep only the ceremonies, and you get all the overhead with none of the benefit.

The same research showed projects with clearly defined requirements before development started were 50% more likely to succeed. Requirements... documented in advance. The same thing the Agile world called waterfall thinking.

The lesson isn't "go back to waterfall." The lesson is: know what you're building, talk to the people who need it, and then move fast. Agile thinking, in other words. The sprint ceremony calendar is not.

What Real Agility Looks Like

I've been in teams with genuine agility. They looked nothing like the textbook.

They talked to customers constantly... not in formal quarterly reviews, but in Slack threads and five-minute calls when something was unclear. They shipped small changes often... not because they had a release train scheduled, but because they cared about getting feedback. They changed direction mid-sprint without drama... not because they ignored planning, but because they treated the plan as a starting point, not a contract.

The most effective team I ever worked with had a process describable in one sentence: build something small, show it to someone who'll use it, learn, repeat. No Jira. No velocity tracking. No Scrum Master. A Trello board with three columns. They shipped every week without fail.

Where to Start If Your Agile Has Gone Wrong

Cut the ceremony time in half. Your daily standup should take fifteen minutes maximum... and only when it's genuinely useful. If it's a status report to the manager, cancel it. The manifesto says face-to-face conversation is the most effective way to share information. A round-robin status update isn't a conversation.

Measure outcomes, not process compliance. How often do you deploy? How fast do you respond to a customer request? How long from idea to production? Those numbers matter. Velocity and story points are internal theatre.

Put engineers in direct contact with users. Not via a product manager acting as a translator. Direct contact. This one change does more for agility than any ceremony redesign.

Take "maximising the work not done" seriously. Your backlog isn't a commitment. It's a hypothesis list. Most of what's in there doesn't need building. The most productive decision your team makes in a sprint might be the feature they reject.

The Question Worth Sitting With

Before your next sprint planning, ask your team: are we practising Agile, or are we running Scrum ceremonies while calling it Agile?

The answer might be uncomfortable. Uncomfortable answers are where improvement starts.

Your team's agility isn't measured by how faithfully they follow the Scrum Guide. It's measured by how fast they learn, how quickly they respond to change, and how much working software lands in front of real users.

Everything else is overhead.

What does your team's Agile practice look like in reality? Are you building things... or running meetings about building things?

I've watched it happen a dozen times.

Your best engineer ships feature after feature. They debug problems nobody else sees coming. The team respects them. Leadership notices.

So you reward them. You make them a manager.

And within six months, you've lost your best engineer... and gained your worst manager.

The Peter Principle Is Thriving in Engineering

Laurence J. Peter named this phenomenon back in 1969. People get promoted based on their performance in their current role, not their ability to do the next one. They rise until they reach a role they're bad at. Then they stay there. The concept has its own Wikipedia page, and researchers who simulated it even won an Ig Nobel Prize for proving random promotions outperform merit-based ones in Peter Principle organisations.

In software engineering, this pattern is everywhere.

Gallup's research puts hard numbers on the problem. Only 1 in 10 people naturally possess the talent to manage others. Companies pick the wrong person for management roles 82% of the time.

82%.

Think about what this means. In a company with 50 managers, 41 of them should not be doing the job they're doing. Not because they're bad people. Because they were promoted for the wrong reasons.

Managers account for 70% of the variance in employee engagement. Half of all employees have left a job specifically to escape their manager. US companies spend $1.5 billion a year on engagement programmes, and average engagement levels haven't moved in 20 years.

My own research backs this up. In surveys I've run through Step It Up HR, 99.5% of respondents said they've had one or more types of bad boss. Not 50%. Not 80%. Ninety-nine point five percent.

The system is broken. And the engineering industry keeps feeding the broken system by turning great coders into reluctant managers.

The Double Loss

Here's what happens when you promote your best engineer into management.

Loss number one: You remove your strongest technical contributor from the work they do best. The person who spotted architectural flaws before they became production incidents. The person who mentored junior developers by sitting next to them and pairing on hard problems. The person whose code reviews taught the whole team something. Gone. Replaced by someone less skilled, or by nobody at all.

Loss number two: You install a manager who doesn't want to manage. They sit in meetings wishing they were coding. They struggle with conflict resolution because they've spent a decade solving problems with logic, not emotions. They avoid difficult conversations about performance. They micromanage the technical decisions they used to own, because it's the only part of the job they understand. Their team feels the tension. Morale drops. Your best people start looking elsewhere.

I've lived this. I've been the engineer who got promoted. The first time I became a CTO at a startup, I didn't want the title. They needed it for their fundraising deck. As the tech founder, you're the "CTO" with invisible quote marks. And the skills required to be a real CTO... strategic business leadership, managing managers, budgets, cross-department communication... none of those are the skills you got hired for.

The transition from engineer to engineering manager requires learning to let go of writing core code, negotiating with product managers, building cohesive teams, and handling conflict. Those are entirely different muscles. And the higher you go, the further you get from the work you loved. By the VP of Engineering level, coding is a crime. You have more important things to do.

Management as the Only Way "Up"

The root problem is simple. Most companies have one ladder. Write code, become a senior engineer, then... manage people. There's nowhere else to go.

If you want a raise, a better title, more influence... you take the management job. Even if every fibre of your being says you'd rather be designing systems.

Engineers are logical. They look at the incentive structure. Higher pay goes to managers. More decision-making authority goes to managers. The org chart points up through management. So they take the management role. Not because they want to manage. Because the system leaves them no other choice.

This is organisational design failure. Not a personal failing.

Build Real Career Tracks

The fix isn't complicated, but it does require organisations to rethink what they value.

Pat Kua's Trident Model describes three distinct career paths:

1. Management Track — 70-80% of time spent on people, organisation, and enabling others. This is for people who genuinely want to develop and support teams.

2. Technical Leadership Track — 70-80% of time on technical vision, risk management, architecture decisions, and growing team knowledge. Leadership without people management.

3. Individual Contributor Track — Deep specialist work. Execution, expertise, and impact through technical depth.

All three tracks should reach the same level of seniority, compensation, and respect. A Staff Engineer should earn as much as an Engineering Manager. A Principal Engineer should sit at the same table as a VP of Engineering.

The traditional dual-track model (IC vs Manager) is a step in the right direction, but it often fails. As Kua points out, the IC track tends to overemphasise individual contribution when most organisations need technical leadership. The Trident Model fills the gap by recognising the role of the person who shapes architecture, sets technical direction, and mentors... all without managing anyone's holiday requests.

What Good Looks Like

Before promoting anyone into management, ask these questions:

Do they want it? Not "would they accept it if offered?" Do they actively seek out people problems? Do they volunteer to run retrospectives, mentor others, and mediate disagreements? Or do they do those things reluctantly because nobody else will?

Do they already manage? The best managers are doing the work before they get the title. They're coaching peers. They're having tough conversations. They're thinking about the team's health, not their own output.

Would you trust them with a firing? Management isn't all team lunches and stand-ups. Sooner or later, a manager has to deliver bad news. Have a performance conversation. Let someone go. If you wouldn't trust this person with the hard parts, don't hand them the role.

What will you lose? Be honest about the cost. If promoting your best architect into management means your system design quality drops, the trade-off has to be worth it. Often, it isn't.

Stop Calling It a Promotion

Management is not a step up. It's a step sideways into a different profession.

An engineer who becomes a manager isn't doing the same job with more authority. They're doing a completely different job. The skills transfer is minimal. The daily experience changes entirely. The feedback loops are different. The satisfaction comes from different places.

The best thing you do for your strongest engineer might be to give them a raise, a Staff Engineer title, and the authority to shape your technical direction... while keeping them far away from one-on-ones and performance reviews.

Build three ladders. Pay them equally. Respect them equally. And stop assuming "up" means "managing people."

Your best engineer deserves better than a job they'll hate.

Lots of books, studies, talks, think groups, consultants and more have tried to figure out why software as a business is hard...but they seem all try to look at it from a single viewpoint.

I'm going to give you the secret to why writing software as a business is difficult.  Hard.  Nigh-on impossible.

Why?  Perspective.  Multiple points of view (PoV).

I've attempted to show you why in this chart.  Value from one's point of view tops out at 10 here.  The units are arbitrary.
​
The business folks start this chart on the left.  The absolute best thing they could get is an app that does everything their heart desires and get it /right now/. The longer the project drags on, the farther to the right and down the blue line goes. Why can't developers ever deliver anything?

Either the market opportunity will dry up because a competitor did release an imperfect but on-time project, the sales won't materialise, or the project will run out of money before delivering.

Note that the blue line continues below zero. A below zero value is a very real prospect...it means that the project is losing money for the business.

The developers enter this from the right.  There's almost zero value in giving something to the business on the first day.  We've not had time to scope, research, analyse, plan, divide into user stories, write tests for, fail, refactor, meet, discuss, and eventually deliver some software. Why do the business types always demand software before it's ready?

If the business demands it at the beginning it will have a near-zero value.  As time goes on, the value delivered (red line) slowly ascends.  At the far right, we've hit the perfect software: small, easy to maintain, well documented, maybe multi-platform and a joy to behold...and entirely too late.

By the time we've gotten that far our company has gone out of business.

The real value that a software project delivers is represented by the green line. The maximum value is the MINIMUM of either the red or blue lines.

The best we can hope for is to find the optimal mix: 'enough' software to scratch a business need, delivered fast enough to capitalise on the opportunity.

Admittedly not perfect software, and clearly not delivered on day 1.

There are ways to try to manage both lines to enlarge or prolong the sweet spot.  

You could throw more money at a project (whether that shows up as hardware, software, people, facilities, resources, campaigns, publicity, influencers, whatever...at the end of the day, it's all money) to give you a longer time period before the blue line starts to descend.  However, the farther to the right you go, the less effect throwing money at a project will have.

You can try reuse (internally with code or externally with libraries), or better tech, hardware or people to move the red line to the left.

No matter how passionately I argue that we *must* refactor code or that the project must deliver by Tuesday (even if the software isn't ready), I'm not going to be helping the business.

At the end of the day, we need to swap our points of view. 

If a dev looks at this from the pov of the biz guy, they'll be thinking how to move their bar to the left.  Descope, suggest alternatives, innovate to do things in quicker ways.

If a business guy uses the pov of a developer, he'll see that the quick win never really existed because it wasn't obtainable in the first place, and trying for it might have actually cost us the opportunity that really was obtainable, even if it were smaller.

This is the challenge that makes software difficult, and yet keeps things so painfully interesting.

---

---

Okay, enough's enough.  Why create yet another category?

Well, from time to time I'll have random musings about digital stuff that doesn't seem to fit in anywhere else.
​

---

Leaders always want the people on their teams to be more productive, more efficient, and perform better at their jobs.

In software, we're constantly trying to improve performance, with all sorts of metrics used to eke just a little more speed out of a team. Here's a few examples for the record in no particular order: agile, scrum, lean development, DevOps, Six Sigma, waterfall, extreme programming, kanban, CI/CD, lean Six Sigma, crystal, feature driven development, rapid application development, capability maturity model, lean startup, design thinking, ITIL, DevSecOps, Lean UX, Six Thinking Hats. (Links explaining these methodologies below.)

Seems lots of people, teams, companies have tried...but have they succeeded?

From the companies I've worked at, the answer seems to be a firm "no".  Companies are focusing on how "hard" people are working. That might be useful when doing a time/motion study on an assembly line, but it doesn't apply when doing creative work like software engineering.

I'd like to propose something radical...but before we talk about that, it's useful to know what an engineer needs to feel "engaged".  

By engaged I mean an engineer who is committed to the work.  They are passionate about the job and care about the success of the projects. More than half of the motivation must come from a desire to learn, grow and contribute to the engineering effort.  They take on new challenges, think creatively, and problem solve in innovative ways.  In short: that's the kind of engineer I want on my team!

To keep that going, an engaged engineer requires care and feeding: Meaningful work, professional development, positive environments, autonomy, work-life balance, recognition, and a diverse work place.  I won't go into those in this article, but they are all key.

Here's the radical bit though: they aren't enough.

An engineer needs to have a bit of breathing room...a bit of time to day-dream.  A bit of time, to...well...be bored.

Yes, that "are we there yet?" kind of boredom.  

I can hear the over-pressured organisations screaming now: "What!?!  We can't have expensive highly-paid engineers GOOFING OFF!?!"

Well, my shouty imaginary organisation...that's *exactly* what I'm proposing.  

Why?  Simple, really.

Boredom (as a tool used by engaged engineers):
1. can spark creativity
2. reduces stress
3. promotes self-discovery
4. encourages movement
5. helps with learning and memory
6. improves sleep
7. enhances mood
8. improves focus

I'm really smart...just take my word for it!  

(Not convinced?  Fair enough...I probably wouldn't be either.  If you want to learn more I mention the "why" for each of these below, and provide references for the studies to back each point up.)

Note that "engaged" part.  This is advanced engineering here.  If your organisation screams "FASTER!" at the teams on a regular basis, you'd probably get more bang for your buck by improving your company culture in the first place.  The engineers have to want to be productive.

Long->short: Make sure you've got the engineers engaged and then let them start to daydream.  Just a little.

Imagine what they'll be coming up with next!

=====================================
A bit of a deeper dive...

Again, I hear the more bellicose companies out there girding for war at the very thought.  Let's talk about each one of these in a little detail, and I'll provide references to studies where people smarter than I figured out each of these items.

Boredom can spark creativity: Research has shown that boredom can lead to creative thinking and problem-solving. A study(S1) published in the Academy of Management Discoveries found that employees who had more boredom in their jobs were more creative and generated more original ideas than those who had less boredom. Encouraging your engineers to take breaks and pursue hobbies or side projects can promote creative thinking and lead to new innovative ideas for your company.

Boredom reduces stress: Chronic stress can have a negative impact on employee well-being and productivity. A study(S2) published in the Journal of Occupational Health Psychology found that brief periods of boredom during the workday can help reduce job-related stress and fatigue. Allowing your engineers to take breaks and participate in activities that help them relax and de-stress can lead to improved job satisfaction, higher productivity, and overall better health.

Boredom promotes self-discovery: Giving your engineers the time and space to reflect on their personal and career goals can have a positive impact on job satisfaction and retention. A study(S3) published in the Journal of Vocational Behavior found that self-reflection can help employees better understand their values and goals, leading to higher job satisfaction and improved performance. Encouraging your engineers to take breaks and explore new interests and hobbies can lead to a more motivated and engaged workforce.

Boredom encourages movement and self-care: A sedentary work environment can have a negative impact on employee health and productivity. A study(S4) published in the American Journal of Preventive Medicine found that taking short breaks during the workday to engage in physical activity can lead to improved mood, reduced fatigue, and increased productivity. Encouraging your engineers to take breaks and engage in physical activity can lead to improved overall health and better productivity.

Boredom helps with learning and memory: Research has shown that boredom can lead to improved cognitive function and memory retention. A study(S5) published in Consciousness and Cognition found that participants who engaged in a boring activity for a short period of time performed better on a subsequent creative task than those who did not engage in the boring activity. Allowing your engineers to take breaks and engage in non-work-related activities that challenge their cognitive abilities can improve memory retention and lead to more efficient and effective problem-solving.

Boredom can improve sleep: Adequate sleep is essential for employee health and productivity. Research has shown that boredom can help promote relaxation and better sleep quality. A study(S6) published in BMC Public Health found that engaging in activities that promote relaxation, such as reading or listening to music, can lead to improved sleep quality. Encouraging your engineers to take breaks and engage in relaxing activities can lead to better sleep quality and improved productivity.

Boredom enhances mood: Positive mood is essential for employee motivation and productivity. Research has shown that boredom can help promote positive mood and reduce negative affect. A study(S7) published in the Journal of Personality and Social Psychology found that engaging in non-demanding activities can lead to improved mood and reduced negative affect. Encouraging your engineers to take breaks and engage in activities that promote positive mood can lead to a more motivated and engaged workforce.

Boredom improves focus: Multitasking and distractions can have a negative impact on employee productivity. Research has shown that boredom can help improve focus and concentration. A study(S8) published in Psychological Science found that exposure to natural environments, which can promote feelings of boredom, can lead to improved focus and cognitive function. Encouraging your engineers to take breaks and engage in activities that promote relaxation and focus, such as meditation or spending time in nature, can lead to better focus and higher-quality work.

=====================================
Methodology links (hover to see link first):
Agile Methodology 
Scrum 
Lean Development 
DevOps 
Six Sigma
Waterfall Methodology
Extreme Programming (XP)
Kanban
Continuous Integration/Continuous Delivery (CI/CD)
Lean Six Sigma
Crystal Methodology
Feature Driven Development (FDD)
Rapid Application Development (RAD)
Capability Maturity Model Integration (CMMI)
Lean Startup
Design Thinking
ITIL
DevSecOps
Lean UX
Six Thinking Hats

=====================================
S1 - "Bored at Work? Try These 3 Things" by Anne Fisher, Fortune, March 15, 2017 - This article discusses a study published in the Academy of Management Discoveries that found that employees who had more boredom in their jobs were more creative and generated more original ideas than those who had less boredom.

S2 - Trougakos, J. P., Hideg, I., Cheng, B. H., & Beal, D. J. (2014). Lunch breaks unpacked: The role of autonomy as a moderator of recovery during lunch. Journal of Occupational Health Psychology, 19(2), 91-103. - This study found that brief periods of boredom during the workday can help reduce job-related stress and fatigue.

S3 - Kooij, D., Jansen, P. G., Dikkers, J. S., & De Lange, A. H. (2014). The influence of age on the associations between self-reflection and work-related outcomes. Journal of Vocational Behavior, 84(2), 235-246. - This study found that self-reflection can help employees better understand their values and goals, leading to higher job satisfaction and improved performance.

S4 - Alkhajah, T. A., Reeves, M. M., Eakin, E. G., Winkler, E. A., & Owen, N. (2012). Sit-stand workstations: A pilot intervention to reduce office sitting time. American Journal of Preventive Medicine, 43(3), 298-303. - This study found that taking short breaks during the workday to engage in physical activity can lead to improved mood, reduced fatigue, and increased productivity.

S5 - Baird, B., Smallwood, J., & Schooler, J. W. (2011). Back to the future: Autobiographical planning and the functionality of mind-wandering. Consciousness and Cognition, 20(4), 1604-1611. - This study found that engaging in a boring activity for a short period of time can improve cognitive function and lead to more efficient and effective problem-solving.

S6 - Kang, J., & Chen, M. H. (2009). Effects of an irregular bedtime schedule on sleep quality, daytime sleepiness, and fatigue among university students in Taiwan. BMC Public Health, 9(1), 248. - This study found that engaging in activities that promote relaxation, such as reading or listening to music, can lead to improved sleep quality.

S7 - Weinstein, N., & Ryan, R. M. (2010). When helping helps: Autonomous motivation for prosocial behavior and its influence on well-being for the helper and recipient. Journal of Personality and Social Psychology, 98(2), 222-244. - This study found that engaging in non-demanding activities can lead to improved mood and reduced negative affect.

S8 - Berman, M. G., Jonides, J., & Kaplan, S. (2008). The cognitive benefits of interacting with nature. Psychological Science, 19(12), 1207-1212. - This study found that exposure to natural environments can lead to improved focus and cognitive function.

---

​Have you felt a pain in your company, but when you looked, you couldn't find a significant cause? Medicine has a concept called "referred pain" that might offer an insight.

Two weeks ago I had a laparoscopic cholecystectomy.  For those like me who don't know what that is, it's a gall bladder removal.  It turns out a Gall Bladder has similarities to an Appendix.  You can live without one just fine.

Not going for sympathy here; the staff at the hospital were absolutely great in all respects. Two weeks later my wife and I just went for a 7-mile hike, with me feeling better than I have in years. If you are ever in the market for such a procedure and live anywhere near Coventry in the UK, I can highly recommend the team that performed it on me.  Feeling such an improvement got me thinking…

I've had a dodgy back for a long time now.  Sometimes okay, but sometimes very not.  A few times, for up to a month.  I couldn't do anything significantly physical, sometimes I could hardly move and certainly couldn't get comfortable.  Exercises, yoga, pilates, diet changes, going alcohol-free for a year, nothing seemed to improve it. This surgery seems to have sorted it out to a great extent.

In discussing this with my surgeon, he mentioned something called "referred pain".  I'm not qualified to try to explain it, but here's one definition I found: 
"Referred pain is a fascinating phenomenon where pain is felt in one part of the body due to the convergence of nerve pathways, even when the source of pain is elsewhere. It highlights the complexity of our nervous system's pain processing."

Hrm…'fascinating'.  Not the word I'd have used, actually.

At any rate, I feel this has applicability in our day jobs as well.  How often have you had a problem and started looking for the cause?  When you found one, it didn't feel like the prime mover cause; it felt like a symptom.  You keep looking, and then you find a cause for that one. Hopefully, you can finally find the root cause of the issue and create a plan to stop it from reoccurring in the future.

The idea is not to treat the symptom but rather the cause.  Many people have heard of "The Five Whys" (or maybe the 5Ys).  According to MindTools: 
Sakichi Toyoda, the Japanese industrialist, inventor, and founder of Toyota Industries, developed the 5 Whys technique in the 1930s. It became popular in the 1970s, and Toyota still uses it to solve problems today.
Toyota has a "go and see" philosophy.
I expect most teams would benefit from this sort of "go and see" thinking.  I feel it applies to all teams such as Finance, HR, Customer Support, and any other department in the organisation.

In other words, don't react to symptoms; go and see what's really causing the problems and fix *those*.

---

So, I had a problem.

Like every mobile project before, this project was suffering.

The views (UIViewControllers on iOS or Activities on Android) lifecycles were wreaking havoc with the logic.  The views were like waves....they'd arrive causing my logic to start, and they'd go tearing down the logic sandcastles as they left.

The code invariably had train wrecks scattered throughout: object.attribute.field.method().  On Android it would all crash horribly in a nullPointerException fire.  On iOS, it would just quietly disappear like a mafia hit.

The code was so tightly integrated, you needed testing magic, mocking doubles, stubs, libraries, Robolectric or such to try to test the code.  These often came with limitations that were worse than the untested code.

So, we're back at manual testing bug whack-a-mole: knock one bug down, and another one rises.  Knock the second bug down, and the first one returns.  Squish both, and a yet-undiscovered bug pops up.

The UI state for each view was this flexible thing...when a button was clicked, the textfield was enabled.  Except when the 'Bad Password' screen was showing, because then the cursor would show through.  So we had to special-case that.  Of course, when the requirement came down to show a 'forgotten password' dialog, that had to be catered for as well, and...

​Enough!

I had to be missing something fundamental here.  

At a previous company, I was floundering towards a solution...   

I had a class called a 'Brain'.  This Brain was a wrapper for the logic states, while the views were the OS-specific visible part.  The brain could be in a different state, and the corresponding views would be shown.

Oh, this raised issues to be sure.  Both iOS and Android want their framework to be the center of your application.  After all, it makes an iOS app near-impossible to translate to Android, and vice-versa, unless you're using a multi-platform framework (Zen, PhoneGap, etc).  I had these states, but the interface was more than 3 methods (it had 5 per state) that people coming to learn it thought it was crazy.

Hrm...time for more research, I guess...  

I ran across this article(http://hannesdorfmann.com/android/model-view-intent) by Hannes Dorfmann.  Brilliant article, and it felt like I was on to something.  It's for Android, obviously, but I'm sure the concepts will translate with a bit of work.

Then I downloaded the code...and felt trapped back in the same box.  Not being completely up-to-speed on RXJava, it felt like there were things just out the corner of my eye that I didn't understand or couldn't even completely see.  I didn't see how it would handle the lifecycle issues I'd been facing.

So, then, I thought: why not rewrite it using the most boring, stupid java possible? 

That's when I arrived at 'Circus'.  (Think Piccadilly, not Big-Top)

Before I tell you what Circus is, let me ask you a question:  What /is/ your app?  

Is it the views?  Is it the database?  Is it the network?

I'd say it's the *logic* of your app that makes it special.  How you choose to do whatever it is your app does.

What are the features I'm looking to implement?
1) Eliminate lifecycle gyrations from my logic.
2) Isolate the storage, network, and all other library calls I'm not writing.
3) Provide an easy event-recording mechanism.
4) Ensure that all of my UI, my logic, and my plugins can be written using TDD /without/ having to use crazy testing frameworks.
5) On Android, ensure that my tests run in the JVM, so they're crazy fast, enabling real TDD again.
6) Split the UI, Logic, and Plugins into pieces so that multiple people can work on the same codebase in a *clean* way.

Sound too good to be true?
​Okay, so lots of lines.  How's this really a solution for anything?

Well, let's simplify the views...the views only ever do two things: they send an event to the back end, and they render new states.  They do *not* alter global state.  They could be killed, and reconstituted, and still be just as good as before, as they do not maintain their own state.

Okay, let's also simplify the back end things.  In fact, let's break the back-end things into component parts.  There's a 'network' plugin that provides the 20 or so network calls we'll make to the backend.  There's a 'database' call that handles all storage of temporary state.  And so on.  Any code that we aren't writing gets wrapped in a plugin.  All of it.

What's left?  Our logic, of course.  This is the thing that makes each view of our app a view of OUR app.

How do these all talk to each other?  In true Uncle-Bob fashion, though Interfaces (or your language-equivalent).  This means that there's one (and only one) way from a view to send an event to our logic.  There's only one way for our logic to send a new state to the front end for rendering.  There's only one way for our logic to kick off a network call, or for that network call to return its result.

This means that testing is a doddle, as we can simply write any old object that implements this interface, and all of a sudden, it's that kind of object.  We don't need Mockito, Robolectric or any other framework to test...it's all just Our Code!

Our tests can accept events, and send new states to the UI through the UI Interface.  Our tests can send events to the Back classes and see what states pop out.  The plugins can be tested using the Plugin Interface.

And threading?  The UI reports events through a single call.  It receives new states through a single call. When UI events are reported, they're simply put onto a background thread, and when a new state is sent to the views to be rendered, it's shifted to the foreground thread.  That means that our code *never* needs to bother with foreground/background, etc.  Our logic can simply block and wait, as we're by definition on a new background thread for each event, and always on the foreground thread for all UI changes.

Will this be a solution for all ills?  I don't know.

In my next few articles, I'm going to demonstrate these principles, and how I might implement all this and more.  What I'm aiming to deliver is a simple framework that we can use to get our jobs done in a way that allows for full (and easy) TDD in a mobile context.

My needs are a fairly simple Android application, so I'll be writing it in Java.  The concepts would hold on iOS as well with slight variations.

In fact, if I manage the abstractions cleanly enough, the logic won't care a bean what the UI is doing, nor will the UI care what the backend is...

So, enough for today.  Read my next article for first implementations...

-Ken

---

Sometimes the most important thing is to tilt your head and look at the problem differently.  

I usually end up feeling foolish when this happens.  The only thing to do is to own it and move on, lesson learned.

I work on a big app in my day job.  As delivered, it's currently 45MB.

As you can imagine, some size could be sliced off if we could use /this/ technique, or /that/ procedure. Sadly real life doesn't seem to work that way.  Apps, like people, seem to be the sum total of all the events (and corresponding scars) made over their lifetimes.  There are /reasons/ why we can't use app bundling, or other methods to slim down like some other apps might.

So, when I was tasked with creating a carousel effect, though my first thought was to use the 'Android-CoverFlow' library from https://github.com/crosswall/Android-Coverflow, I balked because of the size.

I don't have anything against the code or the library, we just needed the lightest implementation possible.

So I started trying to build the coverflow effect by hand.

I found that the ViewPager is distinctly odd in the Android world.  If you luck into the right point of view, it's a no brainer.

If you, like me, make invalid assumptions, it's a nightmare of code smells: machine-specific code, hooking into the global layout of the widget, strange unexplained offsets being required, etc.

So, instead of being very long winded, I'm going to show you a git repo.  

One branch, "BadCoverflow", is the original code.  It works okay-ish on one size phone (I used the emulator's Nexus s here), but good luck getting it to work across phone sizes (try it on a Nexus 5x for example), or being able to control scrolling, or resizing elements. I couldn't get the scrolling to be reliably 1 page wide on all phones, and strangely the magnification of the transformer wasn't centered and also varied between phones.

I had a simple idea that a 'ViewPager' would fit the full width of the diplay, and it would just somehow 'know' to center the current item, etc.

I am embarrassed to say I lost 3 days to this mess.  To find what was causing the issues for me, I had to completely comment out all the code and uncomment it, bit by bit, to explain to myself what is going on.

In the other branch, "BetterCoverflow", is the simplified code.  Slightly smaller in size, platform-independent, and with fewer code smells.

Note that there's not much difference code-wide between these examples.  The biggest change came in my shifting point of view.

The viewPager is not expected to go the full width of the display and yet manage only a subset.  It's not expected to manage centering etc.  That's the job of the enclosing View.

Many of the smells have been removed (addOnGlobalLayoutListener? Trying to 'kick' the ViewPager as the transformer wasn't, somehow, being used when first laid out...
though I'm sure not all...no tests?  I mean really...).

As with most libraries we automatically reach for, Android-CoverFlow wasn't actually needed in the end, just a better understanding of how ViewPagers work.

I hope this article helps some other poor, lost soul struggling with a ViewPager-based coverflow implementation.

---

Don't be an Idiot (like me...)

Oh boy.

I don't feel particularly intelligent this evening.

For the last several work days, I've been fighting a bug.  A pernicious bug based around security...which I couldn't find.

I'd go forwards over my code, and then backwards.  Up and down.  I'd check web headers, recompile and run all my tests, etc...  No joy, still couldn't see the bug.

What was it?

Picture that you've got a class like this:

​Later on, in another object I instantiated one of these bad boys:

​What would you expect to see in the console?  Obviously:

​What I'd meant is for the output to be:

​Can you see where I went wrong?



The getName method should have been "protected"", at least, or maybe even "public", with a friendly and handy @Override annotation to indicate that we're overriding a method in the ancestor.


I said to myself, "Self," I says, "you done stepped on your crank."


This is an obvious bit of code, right?
​
But what if you had this:

​Now, the output is:

​How can you tell if that's any different to 
    c2l4OGMzMTk3NmItNWE4MC00YzVlLWE4NmYtOTU3MTJkMjY5OGFk
...or...
    c2V2ZW44NjQzMGI0Zi02MmMwLTQ1NDctOTk2MC1iOWQ2MTY2NGRiMmE=

The fun thing is that there was a third party library handling encryption (that has caused us issues before), as well as a web API that is (by design) rather uncommunicative.

All it would say in this instance is "Bad signature."  Exactly accurate, but not terribly helpful.

All the web request headers, as well as the other 6 arguments as well as those of the other 8 involved web calls were all correct.

The biggest cause (of my stupidity, I'll admit) is that everywhere else in the code, I did this:

​You'll notice that I refer back to a common definition of what getRealName is supposed to do.  There were three different encryption methods (each of which overrode getRealName()), and lots of other variables involved...but this was the cause.

Instead of using the common name manufacturing functions, I'd reimplemented them marking them private, for some reason.  Private methods aren't, of course, overridden.  Why would they be?

To make matters worse, I'd done it in a place where I was almost guaranteed to not find the issue.

Damn, another few grey hairs.

Don't be an Idiot (like me)...invent your own way.  This one's mine.

---

I gave a talk to our department at work a week or two ago, and thought that I'd make the talk available here.

The talk is purposefully abstract and simplistic, as I feel that the Circus architecture is simple and applicable to other platforms as well as Android.  I simply didn't want people to get too hung up on the platform-flavour for the talk.

If you have any questions, comments or suggestions, feel free to contact me at [email protected].

---