The blog of Robert Herbig

Speaking: When is a Regular Expression Better Than Artificial Intelligence?

2025-08-06T00:00:00+00:00

Given at

dev up Conference 2025: Slides
KCDC 2024: Slides
CodeMash 2023
Indy.Code() 2022

Abstract

Natural language processing is a technique for taking human understandable text and wresting machinable information from it through a variety of techniques. When we think about NLP, we typically think about tasks like assessing the tone of a passage of text, answering questions stated in natural language, or summarizing a large amount of text. We recently helped a client build a system for scoring pre-interview screening assessments using AI & ML.

Typically, we spend a great deal of effort trying to convince our clients that there are AI techniques relevant to their problems, and that those approaches are mature enough for prime-time use. Here, I had the opposite problem: the client knew AI was appropriate for their problems, and they were absolutely convinced it was ready for deployment. However, they wanted to use AI to solve all of their automated scoring problems. Over the course of building the system, I found several situations where simpler non-AI techniques could provide comparable or better performance than state of the art AI.

In this talk, we’ll discuss:

Why automating scoring was a fundamental business need for our client
What their technical approach to automated scoring was
How we improved their existing AI models
How we identified situations where AI wasn’t the best approach

By the end of the talk, the audience will:

Have been introduced to several models for AI-based natural language and code understanding
See a 10,000 foot view of how to automate scoring rubrics for assignments that include both programming and human communication
Have some rules of thumb for deciding when AI is necessary or when a simpler technique is likely to exist or be more desirable.

Description of target audience

The target audience are people in positions of technical leadership on a project. Specifically, both those that are trying to sell the adoption of newer technologies within an organization, and those that are trying to push back on the over-adoption of a new technology.

Our talk will also go (briefly) into the gory details of a system that uses AI as part of its process. This will likely interest developers that are interested in AI for its own sake as well as product owners looking to see what they can expect when incorporating AI into their products.

Speaking: What Are AI Agents, Anyway?

2025-08-06T00:00:00+00:00

Abstract

Terms like ‘AI agent’, ‘agent-based systems,’ and ‘agentic AI’ are trending, building on the momentum of Generative AI. This approach promises systems capable of autonomously executing complex tasks while adapting to changes with minimal human intervention.

It’s one thing to promise, and another entirely to deliver. As the hype around “AI agents” grows, so does the confusion: What exactly are they? How do they differ from traditional AI models? Why do so many implementations fall short of their promises?

In this talk, we’ll go over what AI agents really are: how they work, where they succeed, and where they fail. We’ll look at some agentic AI design patterns and how they are analogous to traditional software tools, databases, networks, and peer-to-peer systems.

Description of target audience

Course: Building‍ Security into AI

2025-06-02T00:00:00+00:00

Abstract

This course demystifies AI development and shows you how to build security in from the start. Learn how AI differs from traditional apps, create a threat model, and analyze real-world breaches. Perfect for security pros ready to tackle the risks of AI-powered systems - before attackers do.

Description of target audience

Speaking: Can We Learn to Manage Uncertainty? Probably!

2025-05-02T00:00:00+00:00

Abstract

When we’re asked when something will be done, it’s tempting to answer the question. “It’ll be done on March 32nd,” “It’ll take 182.5 days,” or “We need 15 sprints”. Whether that answer is the best-case, average, or worst-case scenario doesn’t matter.

The answer is fundamentally wrong because using a single value hides the fact that we really meant a distribution of possible dates, durations, or outcomes. The exact value is uncertain. Development may be faster or slower than we thought. What if the tech lead wins the lottery and retires? What if a global pandemic forces us to change the way we work?

Description of target audience

Vibe Coding Is the Purest Form of Agile (And That's the Problem)

2025-04-23T00:00:00+00:00

Vibe coding absolutely nails the values of Agile, and quietly violates the mechanisms that make Agile work.

Vibe coding might be the purest form of Agile we’ve ever seen. No standups, no tickets, no backlog grooming, just chaos and bliss. It nails the Agile values: working software, responding to change, and individuals over process. The loop is immediate. The feedback is constant. The friction is near zero. It feels like Agile distilled: velocity, autonomy, and iteration, without the weight of process.

Admittedly, vibe coding is an informal, emergent practice, not a process like Agile. But by turning certain Agile values up to maximum and stripping away everything else, vibe coding stress-tests which parts of Agile actually matter.

And that’s where things get interesting. Because while vibe coding looks like Agile - maybe even more Agile than Agile has ever dared to be - it quietly violates the deeper structures that make Agile work over time. Shared understanding fades. Feedback loops turn inward. Coherence breaks down. It’s not just fast, it’s fragile.

If you think vibe coding is the future, ask how many of your experiments survived a second week. If you think Agile already solved all this, ask why vibe coding feels so much faster. Neither view is wrong, they’re both incomplete.

Vibe Coding Appears Deeply Aligned with Agile

Working software over comprehensive documentation. Vibe coding delivers code that runs, immediately. There’s no spec to write, no ticket to close - just a tight loop of writing, testing, and refining. You see the result as you build. It’s software first, everything else second.

Responding to change over following a plan. Plans barely exist in vibe coding. Every output is provisional. You revise prompts, rework logic, pivot direction on the fly. Change isn’t a reaction - it’s the baseline. Nothing gets locked in, and that’s the point.

Individuals and interactions over processes and tools. Vibe coding is centered on the developer’s direct engagement with the AI model. There’s no ceremony, no defined roles. The interaction is immediate, continuous, and entirely individual-driven.

Customer collaboration over contract negotiation. There’s always some input guiding the work: a user’s need, a stakeholder’s goal, or the developer’s evolving sense of what’s useful. The collaboration isn’t formalized, but it’s embedded in the loop. Build, observe, adjust: it happens in real time.

Bonus content (because changing the pattern mid-stream feels on-brand): simplicity is the art of maximizing the amount of work not done. Okay, this one’s from the Agile principles, not the Manifesto itself - but vibe coding nails it anyway. There’s no overhead, no filler, no wasted motion. It’s just raw intent turned into running code, as directly as possible.

But Vibe Coding Quietly Violates Agile’s Deeper Principles

The most efficient and effective method of conveying information is face-to-face conversation. Vibe coding narrows the loop to a single person and their machine. Context lives in prompts, short-term memory, and intuition, not shared conversation. There’s no mechanism for building a shared understanding across a team, because there’s no team in the loop.

Business people and developers must work together daily throughout the project. Collaboration in vibe coding is optional at best. The loop loses the richness of diverse perspectives. Designers, testers, domain experts - they’re all out of the loop. Feedback tends to be internal, based on feel, not validation. The result isn’t just fragile software, it’s narrow software: software that reflects local judgments, not shared goals. Vibe coding works best when the person writing the prompts already knows where the bodies are buried. They understand the context, the constraints, and the trade-offs without needing to ask. But that kind of tacit knowledge doesn’t scale and it doesn’t transfer. The fewer people involved, the more brittle the outcome becomes.

Agile processes promote sustainable development. Vibe coding burns hot. Without intentional pacing, prioritization, or checkpoints, developers tend to sprint until the architecture collapses or they spot the next shiny thing. Refactoring is often reactive, if it happens at all. More often, entropy wins. It’s fast but not steady.

Continuous attention to technical excellence enhances agility. That attention rarely happens in vibe coding. The focus is on “Does it work right now?” not “Will it still work next week?” Quality, consistency, and structure tend to degrade unless intentionally reintroduced, but by then entropy has already taken hold.

Working software is the primary measure of progress. In vibe coding, “working” can mean “generates output” rather than “solves the right problem.” Without external validation or shared definitions of done, progress becomes subjective and fragile.

And maybe the resemblance was never real to begin with. The Agile Manifesto doesn’t reject the values on the right, it just prioritizes the ones on the left. Vibe coding often ignores the right entirely. It doesn’t de-emphasize documentation, planning, validation, or collaboration - it ignores them. That’s not an extreme form of Agile. It’s something else pretending to be Agile because it happens to move fast.

Bridging the Gap Between Vibe and Viability

Vibe coding feels like the purest form of Agile, but that purity turns out to be brittle. It strips away ceremony, friction, and delay, delivering working software with minimal overhead. But in doing so, it also strips away the mechanisms that make software sustainable: shared understanding, external validation, and coherence over time. And when you look closely, it’s not just Agile pushed to its limits, it’s something else entirely. It mimics the values but discards the balance. What looks like Agility becomes erosion by another name: frAgile.

The solution isn’t to abandon vibe coding or to force traditional process back onto it. It’s to recognize where it falters and build lightweight practices that provide missing structure without killing the flow. Practices that preserve context, capture intent, and invite meaningful feedback, without getting in the way.

Vibe coding isn’t broken. It’s unfinished. It gives us speed, iteration, and flow, but not longevity, clarity, or shared direction. Vibe coding thrives in zero-overhead environments. But Agile assumes motivated individuals aren’t left alone - they’re supported, aligned, and operating in a shared context. Vibe coding removes the need for that support until it has to scale, share, or hand off. Then the missing scaffolding shows. What works beautifully in a solo loop collapses when we need to scale beyond more than one person - not because the tools are wrong, but because the patterns are missing. The challenge now is to shape practices that keep the momentum without sacrificing meaning. If vibe coding feels like the purest form of Agile, the next step is to ask: what does it take to make that purity scale?

Why Vibe Coding Fails - and How Signal Coding Fixes It

2025-04-02T00:00:00+00:00

AI is an amplifier for whatever signal we humans provide. Garbage in, garbage out. Signal in, software out.

– Robert Herbig, in the thing you’re currently reading

If you haven’t heard of vibe coding, it’s an interesting concept: you prompt an AI agent to do all the coding and focus on fast iterations. Minimize time from thought to working application. Don’t worry about the code itself, only the application produced. I had to try it, just to see what the fuss was about. At first, it was incredible: the AI gave me working UIs, full features, even decent front-end styling. No scaffolding, no boilerplate, just results. An application that matched my vision with minimal effort.

The code was a mess: no structure, no reuse, no best practices. But who cares? The app worked.

Then I tried to change something and everything fell apart. The AI got stuck in what I call an entropy loop. Vibe coding stopped producing results and making progress. Each fix introduced new bugs or broke something else. I was knee-deep in brittle, incoherent code I didn’t write and didn’t want to debug.

Vibe coding got me velocity, but not stability or sustainability.

Once I cleaned up the code (introduced structure, patterns, tests), the AI agent came alive again. Suddenly it could extend features, fix bugs, even refactor, all with minimal direction. That’s when it clicked: these agents thrive on clean code, just like human developers.

If I could keep the speed and inject intent, architecture, and quality, I could get the best of both worlds. That’s Signal Coding.

Vibe Coding and the Drift Into Entropy Loops

Vibe coding is optimized for speed. We describe what we want, and the AI builds it. Minimal time spent on setup or planning, the AI will figure it out. It’s pure iteration - we keep prompting until we get what we’re after.

This works well for early exploration: discovery, prototyping, validating an idea, generating UI scaffolds, or creating quick backends. We’re not worried about code quality or structure and are entirely focused on visible results. And for short bursts, that tradeoff makes sense.

Self-reinforcing Entropy Loops

In practice, this approach doesn’t scale. What makes vibe coding powerful in the first few prompts is exactly what makes it fragile over time. The more we build this way, the faster the system drifts into self-reinforcing entropy loops. These AI systems fundamentally rely on clarity and structure to function effectively, yet the code produced through vibe coding inherently lacks both. Each round of changes increases the confusion, making it progressively harder for the AI to navigate its own creation.

There are two broad reasons vibe coding breaks down:

The AI can’t see enough of the system. Its context is narrow and stateless. It works locally, not holistically. This causes breakdowns that may improve with longer context windows, better memory, or improved agent-based tools.
The AI isn’t capable of creating code it can reason about over the long-term. Even if it writes working code, it doesn’t lay foundations it can build on. There’s no continuity, no internal consistency, no long-term structure. The result is a codebase that slowly becomes unworkable, even to the agent that created it.

I’ll explain these in more detail later.

What Is Signal Coding (Really)?

Signal Coding is how we make vibe coding work past the first few prompts. Where vibe coding prioritizes output, Signal Coding prioritizes continuity. It’s a collection of practices that help the AI produce systems it can still reason about later. We’re not asking the AI to write perfect code, we’re just giving it the conditions it needs to succeed over time.

That means helping the AI build within a structure, keeping naming and abstractions consistent, prompting in smaller units, and resetting context between tasks. These aren’t heavyweight processes. They’re ways of injecting just enough signal to prevent drift. If vibe coding is about speed, Signal Coding is how we keep that speed from turning into churn.

Core Practices of Signal Coding

Signal Coding isn’t about slowing down or reintroducing heavyweight processes. It’s about adding just enough structure to keep the AI grounded. These practices aren’t theoretical, they’re practical ways to make sure the code we generate remains usable, extendable, and comprehensible, even as we move fast.

Plan and Structure First

We don’t start with code. We start with a plan. Before we prompt, we discuss options with the AI, decide on an approach, and document those decisions. A simple PLAN.md file becomes the anchor for our design choices: naming, responsibilities, system boundaries, feature order, notes, etc. These plans don’t have to be just text. Visuals, especially Mermaid diagrams, can be a powerful addition. Humans benefit from seeing structure laid out visually, and AIs understand that format unusually well. It’s one of the rare cases where the same artifact works equally well for both.

Most crucially, we must keep it up to date as we go, which is easily done by telling the AI to update it after each change or commit. This file also serves as an efficient way for the AI to restore its context and “remind itself” where we left off.

This planning can be fractal. We do it at the feature level, but also within smaller scopes such as new components, tricky functions, or design pivots. At each level, a bit of structure makes the next step easier to express, for both us and the AI. The AI will easily understand nested PLAN.md files.

Prompt Intentionally

We prompt for small, focused changes - roughly the size of a clean commit. Each step should be easy to understand, easy to review, and easy to course-correct. This incremental flow helps us shape the system without stepping out of our architectural mindset. We stay high enough to guide design and behavior, but close enough to see what’s actually changing.

When we describe a change, we don’t just say what we want, we also say how we want it structured. We describe boundaries, layers, and intent. The AI will still generate the code, but it’s doing so inside a frame we’ve chosen. This can often be simplified or omitted if we’ve discussed the plan and design ahead of time with the AI (such as the aforementioned PLAN.md file).

Treat each new feature or task as a fresh context. Just like we mentally reset when we move on to a new task, we need to reset the AI’s context. A new session helps avoid context drift and prevents unrelated decisions or code from earlier prompts from interfering with the current task.

Inject Durable Signal

Define names with intent. That doesn’t mean naming every variable ourselves - it means introducing meaningful project-specific concepts and domain-specific terms to the AI early in the process, so it has clear anchors to build on. When the model sees those concepts used with clarity and consistency, it’s more likely to reuse them correctly across files and features. This reinforces structure without requiring us to manage every detail.

Encourage the AI to use abstraction early. If we see the AI repeating logic, we must nudge it to extract helpers or reusable components. Even light scaffolding helps prevent drift later.

Use types and tests as constraints. These don’t just validate behavior - they reinforce expectations. They’re part of the prompt history, and they shape how the AI reasons about the system.

Comments and documentation matter, too. We must not overdo them, but include enough to explain why things exist and how they’re meant to be used. Inline docstrings, file headers, and light README.md notes all help stabilize the AI’s understanding of the system.

Stabilize and Refactor

We don’t wait for the code to break before cleaning it up. Refactoring is how we reinforce the patterns we want the AI to follow. If a function name is ambiguous or overloaded, tell the AI to clarify it. If logic is scattered or duplicated, tell the AI to consolidate it. These aren’t just maintenance tasks, they’re opportunities to clarify our signal. We can even discuss refactoring options with the AI, exploring tradeoffs before committing to a change. That dialogue helps align the model with our intent and keeps us in control of the system’s shape.

Manage the code’s surface area. We collapse one-off experiments once we’ve chosen a direction, clean up abandoned files, and remove unused code. The more we reduce noise, the more clearly the AI can hear our intent.

Why Vibe Coding Fails Over Time

Failures Driven by Limited Context

Some problems with vibe coding are caused by the AI’s limited context. These are failure modes we can expect to improve as models gain broader memory, better tool use, and long-term reasoning capabilities.

The first is a bias toward fix-it-where-you-see-it. The AI makes changes where the problem appears, not where it originates. It applies local fixes instead of systemic ones. It rarely steps back to consider architectural implications or broader effects. This is a direct result of narrow and mostly stateless context. Each prompt is a short-term reaction, not a holistic adjustment.

The second is inconsistent use of abstractions and reuse. Sometimes the AI writes good helpers or modular components. Other times it reimplements logic that already exists, slightly differently, in another file. Whether it reuses existing code often depends on whether that code is visible in the current context window. When it’s not, the AI reinvents: often inconsistently and failing to keep duplicated code in sync.

These issues are real, but they’re not fundamental. With broader memory, better indexing tools, or agentic workflows, we can reasonably expect these limitations to diminish. But even if they’re solved, they won’t be enough on their own.

Failures Intrinsic to Vibe Coding

Other failures aren’t just about limited context, they’re simply baked into the approach. Vibe coding optimizes for fast, one-shot results. That mindset, by default, produces systems that break down under pressure.

The biggest issue: the AI will make the code work - at any cost:

patches over problems instead of solving them
hardcodes values to make tests pass
mocks things that shouldn’t be mocked
builds fragile layers of workaround logic, because that’s the fastest way to produce a passing output.

These decisions aren’t bugs, rather they’re a side effect of asking the AI to prioritize results over reasoning or long-term stability.

AI doesn’t know anything. It simulates understanding. What is actually wants is approval.

– Jesse James Garrett

Vibe coding also promotes a kind of structural drift. It lacks the perspective of a software architect, and without a persistent design philosophy, there’s no plan, no intentional layering, no shared metaphors across modules. Even if the AI generated each part successfully, the system as a whole becomes harder to reason about. Every change increases the odds of breakage or contradiction.

And crucially: these problems don’t go away with more context. You can give a model the entire codebase and it will still optimize for the shortest path to a working result. That’s what we’re asking it to do. Without guardrails or architectural signal, it will solve local problems and accumulate global debt.

This is why entropy loops form and why they’re inevitable without a change in our workflow.

Symptoms of the Entropy Loop

As we go deeper into a vibe-coded system, certain failure modes may start to appear. These are signs that the system is beginning to resist change—that the AI is struggling to navigate the very code it created:

The AI starts to misunderstand its own output. It misinterprets variable and function names, revisits or undoes changes it already made, and cycles through attempts that never quite resolve the issue. We see it get stuck, changing things just to change them, with no meaningful progress. This kind of churn burns dollars and time that could be better spent if we avoided this pitfall.
It begins to duplicate logic instead of reusing it. Even when equivalent code already exists, the AI reimplements it in slightly different ways. This usually happens when relevant logic is outside the current context, but even when it isn’t, the model can fail to use its own prior work. The result is subtle violations of DRY that fragment the codebase and make future changes harder to coordinate.
Even once we recognize that we’re in an entropy loop, it’s often easier to delete the code than to fix it. The AI struggles to clean up its own mess. It can’t refactor the broken logic it produced earlier, because it no longer understands how the pieces fit together. We can prompt it to fix things, but the result is usually more churn. At that point, starting over is often the best path forward.
Prompting becomes an exercise in micromanagement. We spend more time crafting fragile, overly specific prompts than building features. Instead of working with the AI, we’re fighting it - trying to nudge it toward something coherent without breaking everything else. This completely breaks the feedback loop that makes vibe coding powerful. Instead of staying focused on high-level strategy and iteration, we’re forced back into low-level debugging and reactive cleanup.

These symptoms don’t always arrive all at once, but when they start to cluster, we’re in an entropy loop. The code is no longer helping the AI think, it’s getting in the way.

Signal Coding: Breaking the Entropy Loop

Vibe coding unlocks speed, but without structure, that speed turns into churn. We start fast, but we stall. Signal Coding is how we keep moving.

This isn’t about slowing down. It’s about avoiding entropy loops. Staying strategic. Staying architectural. With a few lightweight practices we give the AI what it needs to keep helping us. We keep our systems navigable, testable, and extendable, even as we move fast.

You don’t need to adopt all of these practices at once. Start small: document your next feature in a PLAN.md, prompt for a single focused change, code review the result, refactor, and reset the AI context when switching tasks. Even just these habits will make vibe coding far more stable, predictable, and scalable.

Once you feel that loop open up again - fast, clear, focused - you’ll never want to go back.

If you give it a try, I’d love to hear what works for you and what doesn’t!

Speaking: Escaping the Trap of Self-Sabotaging Meetings

2025-01-15T00:00:00+00:00

Escaping the Trap of Self-Sabotaging Meetings

Given at

CodeMash 2026

Abstract

Meetings are so notorious for draining productivity that historic sabotage manuals listed them as a tactic of choice. The trouble is, modern meetings often fall into the same traps by accident: too many people invited, vague agendas, and decisions that never stay decided. The result isn’t just a wasted hour, but a feedback loop: too many meetings leave no time to prepare, which makes meetings run longer, which forces multitasking, which makes them even less effective.

In this talk, we show how to break those feedback loops before they start. Using lessons lifted from the old sabotage playbook, we’ll contrast common anti-patterns with practical counter-moves: picking the right type of meeting, deciding who actually needs to be there, shaping the environment and logistics, and closing with action and accountability. The aim is simple: meetings that respect time and deliver outcomes. Or, to misquote Arleen Lorrance, be the meeting you want to see happen.

Learning outcomes

Spot and break meeting feedback loops
Apply countermeasures to sabotage anti-patterns
Choose the right meeting type and environment
Use deliberate prep to respect time and attention

Meeting Facilitation Don’t Lose Before You Start

Given at

KCDC 2023

Abstract

Meetings can be so hazardous to the productivity of an organization that the CIA’s precursor, the OSS, included them in their sabotage field manual. While we may not be called upon to thwart direct enemy action, as meeting facilitators we should run the kinds of meetings we would want to attend. There are many reasons meetings are ineffective, most of which can only be mitigated before the meeting happens. This talk will give you things to consider and do to prepare for a meeting.

Attendees will leave with some techniques they can use today to make the most of their precious time. This is primarily aimed at anyone running a meeting. Facilitators, scrum masters, team leads, and managers most often do this, but anyone attending a meeting could benefit. To misquote Arleen Lorrance, “be the meeting you want to see happen.”

Description of target audience

Speaking: Avoiding False Starts with Artificial Intelligence

2024-10-18T00:00:00+00:00

Abstract

Artificial Intelligence (AI) is no longer science fiction; it’s here today, and it’s here to stay. It is in the products you use every day: home automation, digital assistants, or credit card fraud detection, just to name a few.

All businesses will be affected by AI in the coming years, and the impact will be significant. The only remaining question is, how will you influence its effect on your company?

Getting started with AI is a daunting task, but necessary for businesses who want to stay competitive. During this session, we’ll discuss:

How to determine if, where, and how to use AI effectively within your organization
When and how to build an AI team
Common early mistakes and pitfalls when getting started with AI
Typical misconceptions around AI and its application
What to look for in an AI partner or potential hire

Learning objectives

AI and humans have complementary capabilities
AI understands only what we tell it
Automation is better with a human-in-the-loop
Algorithms are as prejudiced as their data
AI means “thinking” differently

Description of target audience

Folks who provide technical leadership
Those who make technical steering decisions within a company
Developers interested in seeing how AI fails via malicious compliance

Speaking: What Does Security Look Like When Building AI?

2024-10-16T00:00:00+00:00

Given at

Momentum Developer Conference 2024: Slides
StirTrek 2024: Recording, Slides
CodeMash 2024: Slides

Abstract

Anyone who is working with AI or considering doing so should care about security. When considering building an AI-powered system or product, the traditional attack surfaces and mitigations still apply. However, new attack surfaces can be present depending on the specific AI approaches used. In addition, due to the typically higher level of automation in AI systems, they can do more harm if they are compromised.

In this talk, we’ll discuss how AI has the same attack vectors as traditional software, and what those attacks look like. We’ll also discuss new attacks that are specific to generative AI (e.g. LLMs like ChatGPT), machine learning & computer vision systems, and optimization techniques. For each type of attack, we’ll point out how they can be thwarted, or at least mitigated.

Previous experience with AI and security are not required to benefit from the session. Attendees will see tools & techniques to help write more secure software, AI-enabled or not. They will walk away with a better understanding of AI-specific attack vectors and their mitigations. They will be equipped to find security education resources in the future.

Description of target audience

Speaking: GenAI Adoption: Balancing Compliance, Innovation, and Action

2024-06-05T00:00:00+00:00

Abstract

Are tensions between your Legal, Compliance, and Engineering departments’ needs slowing down your adoption of Generative AI? You’re not alone.

Leveraging generative-AI-based technologies is not just a concern for delivery teams; it can introduce new tensions between departments.

The fundamental issue is that you want to take advantage of your data while keeping it secure. Thankfully there are effective ways to address this issue while respecting each department’s constraints, allowing your company to benefit from successful GenAI adoption.

In this talk we will cover:

Responsible Implementation: methods for introducing GenAI within a company in a responsible manner that considers all stakeholders
Technology Management: strategies for maintaining control over data while still being proactive in leveraging GenAI for your business
Interdepartmental Coordination: ways to meet the diverse requirements of legal, regulatory, compliance, and engineering departments to ensure a unified approach to GenAI adoption
Case Study: SEP’s own experiences with adopting GenAI will be used as a practical example of responsibly navigating risks and opportunities

This event is ideal for those in leadership positions, from senior executives to engineers and product managers. Get valuable takeaways and strategies for managing GenAI.

Description of target audience

Speaking: AI is More Than Just ChatGPT - How AI Can Help You Today

2023-12-13T00:00:00+00:00

Abstract

AI has captured the attention of the world—for better or worse. Hype, noise, and fear are dominating the headlines, with a huge focus on ChatGPT and its competitors.

Lost in the noise is the big picture: AI has been around for decades and already impacts our everyday lives.

In this session, we’ll re-center the AI discussion for business:

demystify ChatGPT functions and limitations, along with the rest of the AI landscape
outline business needs addressed by AI and provide real-life examples
discuss the current state of AI, what’s working well, and what to look out for

Description of target audience

Guest: AI and UX: Managing Expectations and Implications

2023-11-06T00:00:00+00:00

Abstract

The recent advances in Generative AI (e.g. ChatGPT) have caused many people to ask how AI will impact their work. There will be changes to how we work, for better or worse. There is a lot of excitement around the “better” and a lot of fear around the “worse,” and often both are exaggerated.

Jordan and Robert are two expert AI practitioners working at a software product design consultancy. Come join the conversation with them about what’s happening, what’s possible, what’s real, and what’s not… where UX and AI intersect.

Description of target audience

Speaking: Making Machine Learning More Effective By Applying Agile Practices via MLOps

2023-01-09T00:00:00+00:00

Given at

CodeMash 2023
Nebraska.Code() 2022

Abstract

You’ve decided Machine Learning (ML) can help your customers? Great! ML is very accessible these days. But taking those ML solutions into production in a way that is repeatable, maintainable, and scalable can be challenging. MLOps draws from DevOps and Agile practices to reduce these risks and improve outcomes.

This talk is an introduction to MLOps, including: what it is, how it is similar & different from other * Ops practices, and then we’ll apply these MLOps concepts to three case studies during the session. This talk will teach attendees to recognize anti-patterns for machine learning & its deployment; and use Agile approaches to avoid these anti-patterns.

Description of target audience

Speaking: Solving AI Problems the Easy Way With Off the Shelf Tools

2021-09-16T00:00:00+00:00

Abstract

Hearing about artificial intelligence is unavoidable these days if you’re watching the news or staying abreast of the technical sector. We frequently hear about the power of AI-enabled tools, and are shown soundbytes of experts extolling the virtues of their approach.

While these stories inform and entertain, they also create the perception that AI i s extremely difficult and exclusively the realm of experts, which simply isn’t true! These days we do not need to be an AI expert to reap the benefits of the research community. Off-the-shelf open source tools exist which are powerful enough to solve many industrial problems. In this talk we will map business problems to tools and show how to translate a problem domain into the expected input of the tool. Using these tools will help us identify development opportunities that we might have otherwise missed and save time by not re-implementing common solving techniques.

In this talk, we’ll cover:

Three common problems that can be solved with AI
- Routing vehicles around a map
- Solving sudoku puzzles
- Building controllers for autonomous vehicles
Three off-the-shelf tools that can solve these problems
- Fastdownward
- Minisat
- OpenAI Gym
The formalisms that allow us to translate the real world problems into ones these solvers recognize
- Heuristic search
- Boolean Algebra
- Markov Decision Processes

Description of target audience

One Lead's Journey to Successfully Improving My Software Forecasting With Monte Carlo Simulation

2021-05-25T00:00:00+00:00

What is this?

Forecasting is not a skill I use frequently, which means it takes me time to remember each of the steps and the small details I’ve forgotten. There’s a lot of great information out there, but reading it and refreshing my memory takes longer than I’d like it to. My goal here is to describe the process I use to make this easier in the future (i.e. not the why, but the how). And if someone suggests improvements to my process, all the better!

Don’t worry if you aren’t familiar with some of these terms and tools - I’ll link to explanations as each is used.

One final note before we get started: risk management and recording assumptions are a crucial part of delivery forecasting. That should be done in parallel with these steps.

Step 1 - create the backlog

Everyone has their own way to do this part. My preferred method is Story Mapping(Jeff Patton on User Story Mapping, Hate Estimating? Try doing a User Story Map instead) using Miro.

Step 2a (optional) - sample the backlog

A key component of a forecast is the size of the backlog. Ideally we would estimate the size of every backlog item.

When that’s not feasible, we can use sampling to reduce the backlog-to-be-sized to a manageable amount (Sampling, an Introduction and Sampling, probability and certainty, Sampling, probability and certainty) with a minimal impact on forecast quality. More samples means higher confidence that the samples are representative of the whole, but also takes more time to size.

Samples	Probability the next sample falls within the previously seen range
2	33.3%
3	50.0%
4	60.0%
5	66.7%
6	71.4%
7	75.0%
…	…
11	83.3%
…	…
20	90.5%
…	…
30	93.5%

When possible I use 20 samples (90.5%), but 7 samples (75.0%) or 11 samples (83.3%) will still get good results.

Step 2b - estimate the size of the sampled backlog items

In my experience, the best results come from splitting the backlog items “as small as possible and no smaller” - it’s easier to estimate small stories. If we can take that one step further and make them all “close enough” to the same size, we can simply use story count - no size estimation necessary.

When that’s not feasible, relative sizing works well. I like to use a simple small/medium/large scale. In the following steps we’ll need numbers, however, so I use a simple scale: small (2), medium (4), large (8). You may be wondering “a small story is 2 what? hours? days?” - and the answer is that it doesn’t matter. The important part is that they express the relationship between the size of stories. As long as we’re careful to use the same units later on, the math works out.

You may be wondering “aren’t these story points?”. I avoided that phrase because there’s so much baggage around it in the Agile world. There’s no need for anything complicated here.

Troy Magennis has a Worksheet with more guidance on methodology and an entire chapter in his book for even more depth. He also discusses the tradeoff between story points and item count.

Step 3 - forecast the size of the backlog

Download a copy of the Story Count Forecaster. This tool takes as an input the sampled backlog items and their sizes, performs a Monte Carlo analysis, and forecasts the total backlog size.

On tab 2 (Enter Features or Epics Here): enter the list of sampled backlog items along with their size

On tab 3 (Forecast Story Count or Points):

How many total features do you want to forecast?: the total number of backlog items we want to forecast
What rate do you expect work to split?: enter 1.0 for both the low and high - we will account for split rate in step 4

The key here is to keep our units consistent. If the samples were sized with story points, then the output here will be in story points. If we use story count, then the output will be a number of stories. The output value is always pre-split units of work (see step 4 for split rate).

Choose confidence levels that match your client’s risk tolerance. Lower confidence sets the lower bound for total backlog size, similarly with higher confidence. I usually use 75% and 95%.

Step 4a - estimate split rate (growth)

Experientially, I’ve found these to be good starting range for split rate:

0.75 - 1.5 for a well-oiled team, low complexity product
1.5 - 2.5 for a new team, low complexity product
2.5 - 3.5 for a new team, high complexity product

From that starting point, adjust up or down based on factors such as:

Is there a reason to expect a higher-than-normal amount of rework, defects/bugs, etc.?
Do we expect risks to be realized with less lead time or warning than usual?
Is the feedback or release cadence going to be longer or shorter than usual?
How many external dependencies does the team have?

Troy Magennis has a Worksheet with more guidance and an entire chapter in his book for even more depth.

Step 4b - estimate velocity (throughput) (pace)

Velocity, throughput, and pace are closely related, but distinct, concepts which are often conflated. Each has their use and what is important is that the units are consistent with steps 2 and 3. I’ll use velocity for now, but mentally substitute the other terms as it makes sense for your context. I think velocity has the largest impact on the accuracy of forecasts, so it’s worth taking some time to get reasonable values here.

It’s best to use historical data when possible, if that historical data is recent. If that isn’t available, this is a guess based on experience. Either way it must be in the same units as backlog size. For time I usually use one week to simplify communication with the client. This is just for expectation setting, and the actual development effort can be done in weeks, sprints, etc.

Once we have a baseline velocity, adjust up or down based on factors such as:

Will all of the team be starting on day 1, or is there a ramp up period of time?
Will the team members be working solo, in pairs, a mob, or some other style?
Are there any constrained or only partially available team members?
How many external dependencies does the team have?
Is there any known time off (holidays, vacations, etc.)?

Speaking of external dependencies, identifying and understanding them is a prerequisite for forecasting. If that wasn’t done as part of step 1, spend some time on that before proceeding.

Troy Magennis has a Worksheet with more guidance.

Step 4c - forecasting the delivery

Download a copy of the Throughput Forecaster. This tool takes as an input the backlog size, split rate, and velocity, performs a Monte Carlo analysis, and forecasts the duration with varying levels of confidence (answering the question “how long will it take to build this backlog?”). If the client instead wants to know “what scope can I get with a fixed budget?”, use the Multiple Feature Cut Line Forecaster.

On tab 2 (Forecast):

Start Date: use what makes sense - what really matters to most clients is cost, which is driven by duration
How many stories are remaining to be completed?: the total backlog size range from step 3
Stories are often split before and whilst being worked on. Estimate the split rate low and high bounds.: the split rate range from step 4a
Throughput. How many completed stories per week or sprint do you estimate low and high bounds?: the velocity range from step 4b
Throughput/velocity data or estimate is for: use the same units for time

The output is a range of durations based on confidence/likelihood.

Step 5 - delivering the forecast

At this point, we have a forecast of duration (i.e. a range of durations along with their likelihood), therefore we can forecast cost. If we have a likely start date, we can also forecast the delivery date. However, none of this is useful unless we can communicate it to the client.

The most straightforward deliverables would be:

A representation of the backlog that was used in the forecast (e.g. a story map with “in this release” and “out of this release” clearly delineated)
The forecast - duration, cost, date
- Assumptions that are integral to forecasting - consistent team size, uniform distribution of split rate and velocity, etc.
- Assumptions and risks are specific to this forecast - e.g. does the team need hardware or an environment to start working on a feature?
How forecasting works and what confidence means (i.e. how to interpret the likelihood of the forecast range)

If the client is already familiar with forecasting, we could even give them the tools (e.g. spreadsheets, estimates, etc.) used above.

However, my team has been experimenting with some other ways to communicate the results, which I’ll cover in a future blog post.

Avoiding False Starts with Artificial Intelligence

2020-06-29T00:00:00+00:00

Avoiding False Starts with Artificial Intelligence

Artificial Intelligence (AI) is no longer science fiction; it’s here today, and it’s here to stay. It is in the products you use every day: home automation, digital assistants, and credit card fraud detection, to name a few.

AI will affect all businesses in the near future, and the impact will be significant. The only remaining question is: how do I get started?

There can be a steep learning curve when first using AI. There are three reasons for this:

Many of our natural assumptions around AI are wrong.
Expectations around the development process don’t match reality.
Explainability is rarely considered when developing an AI.

Yet, by carefully considering these ideas, everyone can succeed in using artificial intelligence.

Five Faulty Assumptions

When we first start working with artificial intelligence, it’s easy to make assumptions about how it works. Here are five common, but faulty, assumptions we should avoid.

1. AI has general human capabilities

We expect an artificial intelligence to be able to do the same things a human can do. Said another way, what’s easy for humans should be easy for a machine. A human can see an object on the ground and pick it up. However, this is a very challenging task for a machine. It must see the object, understand what it’s seeing, determine how the object will react when it is manipulated (will it deform, is it rigid, etc.), and then decide how it’s going to act. You can see this process in action with this video of a towel folding robot. Keep in mind it’s sped up 50x, so the robot takes close to an hour to fold two towels.

Amazon had to deal with this same assumption when building its warehouses. Machines do what they are good at (heavy lifting, transporting shelves around the warehouse quickly); humans do what they are good at (verifying the items brought to them, making in-the-moment decisions). The key is to recognize a machine’s strengths and a human’s strengths to build a system that complements both.

2. AI understands the context in which it’s being used

An AI only understands the context (inputs), it is given and nothing more. One such example is IBM’s Watson. Watson was specifically built to compete on Jeopardy. However, it wasn’t told the category for each clue, which sometimes caused it to answer wrong. Watson was missing that critical piece of context.

Another example is when a research team built an app to determine whether an image was of a wolf or a dog. While It seemed to work, it was actually detecting snow versus grass. Because most of the input images of wolves were in the snow and of dogs were in a park, it had learned the wrong concept. While humans intuitively know that we want to differentiate the animal in the picture, and not the background, the AI did not since it was not told the context of the problem. In the end it was a snow detector rather than a wolf detector. The solution was to remove the background of every photo; thereby the AI learned what was important (the wolf or the dog).

3. Automation is an all or nothing proposition

It is natural to think that if we’re automating a process, we need to automate the entire process; otherwise, it’s not worth the time or effort. But that’s not always an efficient use of humans or machines. As we saw in Faulty Assumption #1, supplementing a machine’s capabilities with the human’s abilities is the best of both worlds.

In the medical field where accuracy is essential, it’s been found that a combination of doctors plus AIs have a better rate than either have by themselves:

Our study found that AI detected pixel-level changes in tissue invisible to the human eye, while humans used forms of reasoning not available to AI. The ultimate goal of our work is to augment, not replace, human radiologists.

– Krzysztof Geras, assistant professor in the radiology department at New York University’s Grossman School of Medicine, AI boosts breast cancer detection accuracy

And of course, a cancer diagnosis (or non-diagnosis) is better delivered by a human who can empathize with the patient.

4. AI Systems are unbiased.

AI in their pure mathematical status should be unbiased, but that is untrue. As we saw in Faulty Assumption #2, the wolf detector had biased input data, so it was answering the wrong question.

Another example comes from the UK passport system. The system was set up to recognize specific criteria and approve the passport photo only when all criteria were met. Pretty straightforward, in theory. But the system rejected some acceptable passport photos because of a fault in its input data. Human faces come in all shapes, sizes, and colors and the system simply didn’t have enough examples in its database to correctly identify acceptable passport photos every time.

When humans are involved, it is easy for their biases to be present in the input data they gather. Algorithms themselves do not have bias; however data does. So, if the input data has biases, then the AI will have biases. We must be careful to guard against this by training the AI on data which is representative of everyone who could use the system.

5. AI means intelligence as humans understand it

We tend to believe the “intelligence” in “artificial intelligence” is the same as in “human intelligence”; that an AI goes through the same thought process as a human to get to the solution. But AI approaches problems differently than humans. It is made up of a pile of algorithms and it follows those to a conclusion. It might be the same conclusion that a human would make, but how it arrived at that conclusion is very different. This distinction can be a great advantage. Computers can be unconstrained from past knowledge and strategy, and therefore really challenge how humans think.

For example, the game of Go is a strategy board game, much more complex than Chess. It has been around for thousands of years and in that time, humans have established strategies for play. Google’s AlphaGo changed the way humans look at the game when it won a match against Lee Sedol, one of the world’s top players, by making a completely unexpected move. AlphaGo never would have made this move if it had stuck to conventional human strategies, but it was unencumbered by the past and came up with a new way of ‘thinking’ about the game.

An iterative and experimental process

Along with the assumptions, it’s important to approach the development of artificial intelligence in an iterative fashion, with an experimental mindset.

First, let’s define two terms:

Utility is the reason we’re interested in building AI: higher accuracy, less processing time, faster development time, or any of the myriad reasons we have.
Investment is whatever you spend to achieve a goal: headcount, budget, time, etc.

We have found that development typically follows an S-curve with 3 distinct phases.

First, the feasibility phase (highlighted in blue). The goal of this phase is to determine if it can be done at all. Can we build Data from Star Trek? No - and we can find that out quickly. If this problem inherently can’t be solved, the curve will remain flat. If it can be done, the S-curve will start to form.

Second, the initial development phase (highlighted in purple). The goal of this phase is to determine if we can afford to build it. If the curve starts to rise sharply, we’re on the right track. This probably involves trying several different techniques and approaches to see what tradeoffs each have on this specific problem (see the next section for more on that).

Lastly, the polish phase (highlighted in orange). The goal of this phase is to determine if it’s ready to release. In this phase, the major development is finished; it’s just finishing those last bits of fine tuning and putting the finishing touches to ensure the product is ready to be used. While seemingly simple, it unfortunately takes a lot of time, leading to the level off of the curve. As a result, it’s up to you to choose when the product is ready for release. There’s no right or wrong answer, rather the question of: is this good enough for my purpose? If so, then it’s ready to go!

Admittedly, there is one more phase after the polish phase that is rarely considered: maintenance. Maintaining the system: knowing when to retrain, when to update the algorithm, what data to keep or throw away, also requires time and effort. Just like in the polish phase, these questions have no right answer. It’ll be your choice when to do further maintenance and when it’s enough for your purposes.

Tradeoff: utility versus explainability

There’s one more term to define: explainability. Explainable artificial intelligence is when the AI system produces a solution understandable by a human expert (and ideally even a layperson). Furthermore, how the AI arrived at that solution can be understood. Contrast that with the concept of “black box” AI where even the system’s designers cannot explain why the AI arrived at a specific decision.

Why does explainability matter?

Understanding why a decision is made helps detect bias earlier, like the passport photo verification system we saw in Faulty Assumption #4. People can evaluate whether there are any issues in the system early on and adjust accordingly.
Understanding how a decision is made helps with determining accountability. For example, if someone is misdiagnosed in the situation we saw in Faulty Assumptions #3, breast cancer diagnosis, accountability becomes a big question. AI algorithms themselves can’t really be sued, but depending on the situation, related parties can. While explainability doesn’t say in black and white who should be held accountable, it does still help.
Understanding how decisions are made helps developers fix issues. Consider the case of the wolf detector from Faulty Assumption #2. If the designers knew the system was putting more weight on the background, they would have found the solution of removing the background from photos much quicker.
Having explainability helps build trust with the people using the AI. If someone knows the reasons an AI arrived at a decision, then they can decide whether they trust those reasons and therefore trust the AI. Without explainability, users have to trust the creators that it works.

So, what’s the tradeoff? Well, per the picture above, in general the more powerful the AI technique, the less explainable it is. This is not an exhaustive list of AI techniques, nor is this rule universally applicable. But it is consistent enough that we need to be careful of it. There is a lot of ongoing research in this area.

Now, not every AI system needs to be explainable, but that decision must be deliberate. Think of explainability as a non-functional requirement to be explored in the feasibility phase of development.

Conclusion

It may seem like a lot to think about, but in the end there’s only a few core ideas to remember:

Fix Faulty Assumptions
1. AI does not have the same capabilities as humans: AI and humans each have different strengths.
2. AI does not understand context: AI needs to be told exactly what it needs.
3. Automation is not all or nothing: sometimes the best solution is to use both AI and humans.
4. Algorithms can be biased: be careful of what the inputs are.
5. AI does not mean intelligence as we understand it: AI has a very different process, following algorithms rather than human thought processes.
Practice Iterative Development; watch the slope of the S-curve during each phase and understand what it tells you about the problem you’re solving.
Deliberately Consider Tradeoffs; learn what level of more utility comes at the cost of explainability is necessary for your product and how that impacts which techniques are feasible.

When we accept that we need to take an experimental approach to building AI, that failures will happen, and constantly improve iteratively, success will come with it.

Title Goes Here

2020-05-26T00:00:00+00:00

Creating something brand new is hard. No matter if it’s a painting, a system architecture, or a conference talk, the creative effort of conjuring up something from nothing is difficult. Take me for example, staring at a text editor, trying to figure out what to type next and think up a clever title.

Writers know this as the Blank Page, painters as the Blank Canvas Problem. Regardless of the name, we’ve all encountered the phenomenon at some point. It’s that anxiety that comes from having an infinite number of choices for the next step.

Ok Rob, where are you going with this?

A colleague of mine is kicking off a new software project with a new team. We got to talking about what the team needs to do in this situation and I had to sit down and really think about it for a few minutes. I’ve been doing this for a while now and I’m used to just doing it, not articulating the why of it, thus this blog post.

Just as a baby’s first years have a huge impact on their development, a team’s first steps have a huge impact on its long-term growth. It’s the most critical time for a nascent team. I’m not just talking about a Project Kickoff meeting, I’m talking about the first few weeks of a team.

Start with the Principles

A new team has two immediate goals - there’s a feedback loop between the two so it can be hard to separate them:

Getting work to flow; and
Building a team out of individuals

Getting work to flow is Agile in the purest sense. Get work flowing through the process, check it with the customer, figure out what needs to change, and then change it.

Why is building a team out of individuals equally important? Delivering working software is all that matters, right?

Fully half of the Agile Manifesto’s Principles are about people, because that’s how we get long-term success. To really “figure out what needs to change” and “then change it” requires more than just a collection of individuals, it requires a team. That doesn’t happen by accident.

The researchers found that what really mattered was less about who is on the team, and more about how the team worked together.

– re:Work

Principles beget a Process

Just like Scrum is a process for implementing the Principles of Agile, this is the Process for the above Principles (the what, not how).

First, when getting work to flow, do the simplest thing that could possibly work. Rinse and repeat. It’s not easy, but it is straightforward. The most important thing is to break the “Blank Canvas” effect, deliver something, and show progress.

In Dual Track Development and a project starting up, your demos might be a prototype, and not working code. That’s ok. The point is to show progress.

– Poppe Guthrie

Second, make it safe for teammates to talk to each other. Psychological safety, trust, vulnerability, and shared vocabulary are the keywords here. As a team lead with a team of excellent engineers, I consider that my primary job responsibility. If I can help the team be safe, they’ll self-organize and do things better than I could have imagined. If someone is feeling that “paradox of choice” anxiety, my job is to give them confidence that things will get better in time.

Third, create an intelligence system - one in which accurate, real-time information is distributed broadly and quickly, and presented in detail. The key point is that team members can see and react to patterns and decide what to do. If you’ve read the book Nine Lies About Work (which I highly recommend) this should sound familiar.

Each practice I’m going to talk about has worked for me in the past. Not every one is right for every team, they are simply tools in my toolbox. If you don’t like unsolicited advice, feel free to skip to the end.

Getting work to flow

I’m a big fan of visualizing everything, so I start with a Kanban board. My default board has only three columns: “To-do”, “Doing”, and “Done”. Nothing fancy. If you’ve got a physical board, make it as impermanent as possible, since that makes it more likely people will change it.

What about code reviews? Pull requests? Squash or rebase or merge? Doesn’t matter yet. Avoid long drawn-out conversations - find a starting point and move on. Remember, everything can be changed. It’s all an experiment. We’re just finding a starting point to iterate on later. This is a good time to introduce the concept of disagree and commit. Just don’t let that be an excuse for someone to dominate decision-making.

The roles & responsibilities activity is multi-purpose. It can:

Set expectations amongst the team for who is responsible for what
Make sure there are no gaps (e.g. a responsibility which is missing an owner)
Surface conversations that weren’t being had (I’ve heard this called “unstated conflict”)
Identify places in which people are looking to try new things on the project (growth opportunities)

Building a team out of individuals

Pick a team name. I’ve never met anyone strongly against the practice (at worst is mild apathy). Some people really get into it. It’s a short activity which gets the team focused on the same task. It’s low risk since the name can always be changed later. And at the end, the team has a name around which it can establish a team identity.

Psychological safety means individuals feel confident they won’t be embarrassed or punished for admitting a mistake, asking a question, or offering a new idea.

Watch carefully for those to happen and treat them as a learning opportunity. Have a meta-conversation (i.e. “let’s talk about how we talk”) or an impromptu retrospective on the interaction.
The Personal Histories Exercise is great for learning more about your teammates and reminding yourself that they, too, are human.
Have some paid-for team meals. This encourages participation in the exercises and activities. If you don’t have an agenda, I like to get out of the office. Think of the cost of the meal as an investment in the long-term health of the team.

Shared vocabulary is necessary to make sure what people are saying is what others are hearing.

I like The Five Dysfunctions of a Team as a starting point for a shared mental model for our goals as a team. It doesn’t take long to describe and I haven’t met anyone yet that strongly disagreed with it. The goal here is not a perfect prescriptive model, it’s to establish shared concepts.
The Tuckman model of group development resonates with many teams. It sets the team’s expectations for how it will change over time. Progression between stages is often described as linear, when in reality a team may move back-and-forth between stages.
Talking about the fundamental attribution error gives the team a way to hold each other accountable.
If yours is a team which likes feedback, consider the Motivating by Appreciation Inventory. It helps people understand how to give & show appreciation and deliver & receive feedback.

Be deliberate about building communication norms. It’s likely that some of these people have never worked together before.

I like to start with a “no interruptions” rule based on re:Work and Google’s Project Aristotle. This is the first step to ensuring everyone has a chance to talk and for approximately equal time. It’s not an excuse for one person to dominate the conversation by speaking for too long.
I’ve been on several teams which adopted the above practice. Another that goes well with it (to assist with “conversational turn-taking”) is holding up your index finger to show you would like to speak next. “Jim, what you have to say is important. Jane raised her finger first. Jane, please go ahead and Jim will talk next.” and everyone nods!
I was on a team once in which we were spending a lot of time arguing over minutiae. Asking “on a scale of one-to-ten, how many cares do you have to give about this topic?” was extremely effective at focusing our discussions.

Shake up the team rituals

Let standup run long. Bear with me here, I know this is heresy to some. I’m not saying spend an hour on standup. I am saying that new teammates have different experiences and are used to different styles of standup. Let some friction build up, lean into it, bring it up for conversation, and focus on outcomes. Remind people that what worked on past teams may not work here.
One Scrum team decided to start with two Retrospectives per Sprint. One was the typical Sprint Retrospective, the other was mid-Sprint and focused team cohesion and long-term growth. When the team felt they were Performing (to use Tuckman’s term) they scaled back to one Retrospective per Sprint.

Building an intelligence system

Here is my take on chapter 2 from Nine Lies About Work, how a team lead can create an intelligence system:

Liberate information. Think about all of the sources of information you have and make them available to the team, on demand. Don’t constrain information to those who “need to know”. Don’t worry about whether the team will understand the data or be able to make use of it.
Ensure accuracy of data. Don’t worry about making the data simple or easy to consume. The biggest challenge isn’t making sense of data - we deal with complexity all the time and are good at it. It’s accuracy. Clean data is essential.
Trust the team to make sense of the data. We are not the best sense makers. The team is.
Watch carefully to see which data the team finds useful. Over time, increase the volume, depth, and speed of that sort of data.

Conclusion

Let’s recap:

Get work to flow with the simplest process that could possibly work
Be deliberate about moving from a group of individuals to a team
Surface accurate data to the team and let the team make decisions

So, what’s your approach? What principles, processes, and practices have you found effective? Drop me a line and let’s chat.

What Does It Mean to be a Senior Engineer?

2020-05-11T00:00:00+00:00

As a team lead, I coach and mentor many junior engineers. One topic that always comes up is “What does it mean to be a Senior Engineer?” That’s easy, you just… have a four-year degree from an accredited college? Work for 10 years and don’t get fired? Learn 3 front-end technologies? Check some boxes on a promotion form?

Defining what it means to be a Senior Engineer is an impossible task. If you talk to 10 people you’ll get 11 different opinions. It’s tempting to reduce an undefinable thing to “I know it when I see it”. Unfortunately, that makes it too easy to inject bias. Instead, let’s discuss three traits I have observed in excellent Senior Engineers. These traits are not fundamental to their Senior Engineer-ness. That is, you wouldn’t see them on performance reviews or job descriptions. Despite this, these traits are fundamental to their excellent performance as Senior Engineers.

Grow Those Around Them

I can’t stress the following enough: being right is not enough. It isn’t enough for the Senior Engineer to know the right answer. It isn’t enough for them to know and execute the right answer. It isn’t even enough for them to know the right answer and help a more junior engineer implement it.

People often come to Senior Engineers for help. When that happens, an excellent Senior Engineer thinks “How do I teach them to solve this problem the next time it happens?”. Investing in your team yields amazing returns. Training up our team means they can handle more problems without calling us. For example, while we’re on vacation.

Comfortable With Uncertainty

Senior Engineers increasingly find themselves dealing problems for which there is no “right” answer. Systems engineering and integration, architecture, multi-team organization. There are no unit tests for that. At best there are varying degrees of “right enough” for the situation. If you’re familiar with the Cynefin framework, this is the Complex domain of “unknown unknowns”.

This means the best Senior Engineers live a fascinating contradiction. They are confident that they can solve any problem. Simultaneously, they are uncertain they already know the best way to solve it. Living this dichotomy is a conscious effort to mitigate the Dunning–Kruger effect. Good engineers are aware of the Dunning-Kruger effect. Senior Engineers work hard to avoid its pitfalls.

Being comfortable with uncertainty is essential when investigating unknowns. This is often where the most difficult problems lie, and where we can reap the greatest rewards. Investigative tasks are often poorly-defined. Even with a good definitions, exploring the unknown has many unanswerable questions.

For example, how long should we investigate one option before pivoting to another? Too little time means we missed some easy gains. Too much time and we’ve spent too much for an incremental gain. No one can know ahead of time how long is appropriate. A Senior Engineer has to be comfortable with making that determination.

Curiosity Mindset

I have something to learn from everyone I meet.

– Dave Mott

There are many ways to name the following concept. Which resonates with you will depend on your personal lens. “Curiosity mindset” or “growth mindset” resonate with some; others prefer “humility” or “egolessness”. Whatever you call it, what is important is to be aware of your assumptions and biases. Moreso, to be aware that you must question those assumptions and biases routinely.

When a junior engineer doesn’t believe an excellent Senior Engineer, the Senior Engineer must not get defensive, but curious. The Senior Engineer is curious about why others have a different belief. Disagreement isn’t an opportunity to prove someone wrong. It’s an opportunity to understand why they have a belief and show them another option. Further, a Senior Engineer is curious about why they hold the beliefs they do.

What About Technical Skills?

We’ve spent nearly a thousand words discussing Senior Engineers without mentioning technical ability. Strong technical skills are important. We’ve avoided talking about them for two reasons:

They’re assumed for a Senior Engineer
Software development is very much a social endeavor

Senior Engineers aren’t solely focused on building the function, or the page, or the story. Those are table stakes. Senior Engineers take a longer view. The code is critical today, but technical ability, good teammates, and good teams are what let us continue to build excellent products. Excellent Senior Engineers worry about building those as much as they do any feature.

Conclusion

Approach and mindset are as important to what makes a Senior Engineer as technical ability. Junior engineers, I know you’re already watching and learning from Senior Engineers around you. I urge you to watch not only what they do, but how they do it.

Is Artificial Intelligence Worth the Hype?

2020-04-13T00:00:00+00:00

Image courtesy of Jeremykemp at English Wikipedia / CC BY-SA

In Everyday AI Problems, my colleague Jordan Thayer said the following:

When someone asks me “What can AI do for me?”, I often suspect the answer is “Not much” because it’s the wrong question. If someone asks me “Is there a way to make this free text machinable?” or “Are there better techniques for scheduling these work orders?” the answers are “Yes!” and “Almost certainly.” Are the techniques that solve those problems AI? Absolutely.

Is AI worth the hype? Absolutely. Jordan believes this so strongly that he pursued a doctorate in it and dedicated his entire professional career to it. I’m a bit late to the party, but I agree with him and am trying to make up for lost time! That said, AI isn’t a panacea; just because something is worthy of the hype doesn’t mean that individual deployments can’t fail because they’re a misapplication or just a bad idea overall. In the following, let’s discuss:

What is AI?
When should you use it?
When shouldn’t you use it?
So what hype is justifiable?

What is AI?

Artificial Intelligence is getting a computer to do anything that would otherwise require a human. Common applications include:

Machine learning
Planning and scheduling
Game playing
Machine vision
Natural language processing

While the machines are trying to imitate human capabilities, the way they do that is often quite alien. Consider asking an AI and a person each to tell you whether or not a tweet expressed a positive or negative sentiment about a topic. The person would read the tweet, understand its meaning, and give you an answer.

In stark contrast, many AI approaches to sentiment analysis won’t even try to understand the text as a whole. Instead, they look at the distribution of words in the tweet, the length of those words, and the amount of punctuation used. This statistical analysis allows the AI to reliably predict the sentiment of the text without needing to produce a deeper understanding.

It’s important to keep the difference in approach in mind. While AI can do things that we typically think of as requiring a human touch, they do so by different means. Our tendency to anthropomorphize things works against our intuition here. An application of AI doesn’t think in the conventional sense. Its outputs are the result of common processes in mathematics, computer science, and engineering being rigorously applied to some problem of interest.

When is AI Appropriate?

AI comes up in situations you might not think of, or in ways differently than you might imagine. For example, AI happens a lot in industrial settings from a controls perspective: to solve a large constraint problem to ensure that we don’t put an oil refinery in a dangerous configuration. This drone application complements it: use drones to view hard-to-reach elements of an industrial facility to reduce the cost of manual inspection.

If your project fits within these guidelines, it’s a good candidate for AI:

It can be thought of as requiring a human.
You can describe it through a rigorous or formal process.
It has a solution that is right/wrong or good/bad.
The human cost of completing it is significant.
The machine cost of completing it is less than the human cost.

Some problems that you encounter every day fit those criteria, and are often solved using artificial intelligence:

Scheduling constrained resources (classes in classrooms, meetings in meeting rooms, participant availability)
Planning sequences of actions
Predicting the next element in a series based on the previous elements
Identifying elements in a picture
Building a summary of a large body of text

When is AI not the right answer?

AI is not the right tool for every task. It is important to remember that artificial intelligence will not replace human intelligence.

Does your task require a process to be adaptable to unforeseen circumstances? If you cannot predict the workflow for the task, and it takes a human to make nuanced decisions, the task is not suitable for AI.
Is the human cost negligible or the compute cost prohibitive? If AI will not save your company at the bottom line, then it is not worth your time developing the AI.
Can you define your task formally? AI follows strict rules — do or do not; it cannot make decisions, create on the spot, or think out of the box. If you cannot provide those rules to make your program work, it’s not a good candidate for AI.
Do societal norms prohibit automation? In some cases, an AI can completely replace a job previously done by a human. There is a great fear that automation will make humans obsolete. How does society ensure those people can continue to provide for their families? If we find that an AI can completely drive a car, will the passengers trust it? How does insurance and fault work in the event of a crash?

Justifying the Hype

This reality means that we may never see Robby the Robot or R2-D2 or Data. They are relegated to the realm of science fiction with flying cars. AI is often silently in the background, playing a large role in many industries that directly impact our everyday lives. Here are some absolutely game-changing examples:

Greenhouse Logistics

Cultivating crops with higher yields that are more resilient to the elements and pests is a problem whose solution affects all of us - after all, everyone needs to eat! Here, AI is being used to reduce the human effort required for phenotyping.

Phenotyping is the study of plant characteristics, like the size of the fruits they produce, under various conditions. Large-scale phenotyping used to be time and labor intensive - a human made the observations by hand. Scientists developed machine vision algorithms to do it for us.

Further, the AI planning community has been using automation of smart greenhouses as a benchmark domain for a decade. The logistics problems that ‘crop up’ here are moving plants (or equipment) to:

Control the amount of light, water, and nutrients each plant gets
Pass the plant beneath a variety of sensors

Medicine

Medicine has advanced dramatically in the last century thanks in no small part to advances in medical imaging. Medical imaging provides information that is critical to determining what is going on with an individual so that the proper course of action can be determined.

Medical imaging is an excellent domain for deploying machine vision algorithms. In particular, deep learning has been remarkably successful in reducing the time between a first consultation and a diagnosis and increases the number of patients that can be treated by each doctor. This is also a great example of how AI works best with human collaboration.

Conclusion

It’s easy to get excited about AI. There is so much progress made in so many fields which all show the promise of AI. Although we must be realistic about the scope of AI, we can still get excited about its prospects.

We must be unafraid to fail. In the end, all AI deployments are an experiment, because we can’t know upfront how well a technique will work for a set of problems that we’ve never seen before. Failing, understanding, and iterating is a huge part of developing AI solutions.

Speaking: Cloud-based Machine Learning Offerings - Beginner's Perspective

2020-03-26T00:00:00+00:00

Abstract

If you’re convinced that machine learning is worth learning about, but don’t know where to start, this talk is for you. If you’ve never seen machine learning applied to solving a concrete problem but would like to, this talk is for you.

We’ll explore cloud-based machine learning offerings from the three largest providers: Amazon (SageMaker), Microsoft (Azure ML), and Google (AI Platform). We’ll investigate these offerings with open datasets for digit recognition and breast cancer identification.

Our evaluation will focus on the following:

Ease of loading data
Quality of tools for data preparation and cleaning
Availability of machine learning algorithms
Ease of comparing machine learning algorithms on a task

This talk will leave you with a better sense of the trade-offs between the cloud-based machine learning offerings. This will help you select the right offering to solve your problems with machine learning.

Description of target audience

Conference Talk Roadmap

2019-12-02T00:00:00+00:00

Co-authored by Jordan Thayer and Robert Herbig

Presenting information to your peers is an important part of an any career, especially engineering:

Teaching a subject reinforces your own understanding and mastery
Presentation and communication skills are essential to team based work
Sharing knowledge helps improve the teams you’re working on
It helps bring in new business (which keeps us all employed!)

Maybe you don’t feel like you have anything interesting to say. You do. Any idea is valuable to share given the right audience. We’ll present some ways to develop your ideas and find an appropriate venue.

Maybe you don’t feel like you have time to prepare a talk. Giving a good talk does take time, however the time doesn’t need to be spent all at once. You can build a presentation in installments over the course of weeks or months. Most companies have activities that support this piecemeal construction of presentation material.

The Roadmap

We, the authors, think of a conference talk as the capstone to a larger process:

Have an idea
Record an idea
Expand an idea into a lightning talk
Expand the lightning talk into a blog post
Expand the blog post into a long talk
Give the talk internally (e.g. brown bag or lunch and learn)
Give the talk externally (e.g. meetup or conference)

Every step of the process is worthwhile. At every step, you have produced something of value. This process is meant to be interruptible and resumable. It starts with having something worth talking about (which everyone does!).

Have Your Thought

Start with an idea. You are the expert on this idea. You don’t have to be an expert on everything about the topic, just your experience with it. That experience is yours alone and no one else’s.

If you feel like you don’t have an idea, here are some prompts that might help you elicit yours:

What are you doing that you haven’t seen a team do before?
What are you doing that you think others would be excited to learn about?
What is your team doing that may surprise or interest other teams, or what are you doing on this team that you haven’t done on any others you’ve been on?
What of those things do you think you should share with other teams?

Collect Your Thoughts

The key to building a talk over weeks or months is to be able to put it down and then later pick up where you left off. Otherwise spreading effort out will just end up being wasting effort, as you struggle to find your place from when you last left off.

There are lots of things that you could put in your repository. We’ve found the following organizational structure helpful:

A document that captures a collection of ideas
A set of personas to help us target and refine our presentations
A directory for pitches, organized by topic
A directory for short presentations (e.g. lightning talks)
A directory for blog entries
A directory for long talks

The first two elements are what we use when we’re deciding what we should start next. We pick a topic that we feel is particularly important and an audience that we’re especially interested in reaching today. Then we start in on the writing.

Giving A Lightning Talk

Often, a topic and a few related thoughts are enough to give a lightning talk. Ten minutes may sound like a lot before you get in front of a group, but it’s shockingly short once you’re speaking to something you’re interested in. If you spend three minutes explaining the problem, three minutes explaining your approach to it, and three minutes describing why that was better than what you used to do, you’ve got just one minute left over.

That leftover minute is for audience interaction. It’s important to pay attention to how the audience reacts and what questions they ask. This gives you important guidance for your blog post.

Expanding the Talk into a Post

If ten minutes is short, three minutes should be positively claustrophobic. It is critical to stay on point, focusing pretty much only on the central point of each part of the lightning talk. This focus is good for the lightning talk, but it also serves to produce an outline for the blog post. You’ve already done the hard work of distilling your thoughts down to a small number of the most important, salient points. That’s where you start writing from; that’s your outline.

The next step is to supplement those points with supporting facts to flesh out the blog post. Be sure to address any questions that came up during the lightning talk and expand upon any areas that the audience was particularly interested in. Make sure that your supporting facts do not distract from the central topic. A quick check is: if this was left out, would the reader still come to the conclusion we want them to?

It’s important not to stall out here. Don’t wait until the blog post is perfect, just wait until it’s complete. You want feedback on your writing. The best feedback is going to come from people who are already immersed in the topic. For example, the people that attended your lightning talk. If you get that post out there while the talk is still fresh in their mind, you’re going to get more pointed feedback from your readers. The more direct and specific the feedback, the easier it is to take action based on it.

Give a Brown Bag

Our brown bags are thirty minute talks given to our colleagues within the company. Thirty minutes may sound like a lot of time to speak. It is, and it isn’t. In thirty minutes, you can get into detail on a topic everyone already knows about. Or, you can cover some of the most important points of a topic that most people aren’t familiar with. The thing is, you’re not going to make anyone an expert on a subject in half an hour. At best, you can tell a story and convince them that they should invest more time in getting a better understanding.

The lightning talk or blog post can serve as a starting point for the brown bag. Previously we recommended splitting the talk into thirds: what is the problem, how do you solve it, how is that an improvement. That’s still a viable approach, but you may find the following breakdowns attractive as well:

Template 1

What is the problem?
- Who has the problem?
- What’s the cost of not addressing the problem?
How do we solve it?
- What are the techniques for solving it?
- What are the trade-offs?
- What have we used to date?

Template 2

What is the problem?
- What lead to the problem?
- Who typically follows this trajectory?
How do you solve the problem?
- When can you intervene?
- What interventions are appropriate when?
- When is it too early to solve? When is it too late?
How can you recognize these problems?

Template 3

What is the technique?
- What is it’s history?
- What are common misinterpretations of it?
Where can it be applied?
- What are some successful case studies?
- What are some failed examples?
- What’s the most common misapplication?
How do we apply it?
Where can we learn more?

Even if none of the above templates are a good fit for your talk, notice that all of the above are phrased in the form of questions. We find it helpful to think about a talk, from start to finish, in terms of what we want the audience to come away with. The templates above are motivated by thinking about which questions we’d like the audience to be able to answer about a topic after listening to our talk.

Once you’ve figured out what you want the audience to take away and, roughly, what you’d like to present, it’s time to fill out the rough draft. The lightning talk and the blog post should go a long way towards filling in the material for your presentation; you should be able to reuse some of the slides from the lightning talk, and if you made any visualizations or included any pictures in your blog post, those are good candidates for inclusion in the brown bag.

We suggest that you never give the first rendition of your talk to a live audience, even an incredibly friendly audience like the kind we have in house. Instead, give the first version of your talk to an empty room. There are three reasons for this:

Estimating the duration of a slide is hard
Your script will refine itself with each pass
Some issues are only obvious when speaking to a slide

Your talk will improve with repeated presentations. Get the rockiest presentation out of the way before you’re in front of a group. This lets you get better feedback when you do the next dry run in front of an audience of one or two others. This serves two purposes: it provides outside perspective on what isn’t obvious to a non-expert, and it gives you feedback on the quality of the presentation overall.

Find an appropriate external venue

Don’t let your talk be done after you present to your colleagues. You want to share those ideas to the rest of your peers within the software development community.

The first step to giving an external talk (e.g. at a meetup or a conference) is finding a venue. There are a variety of mailing lists, aggregators, and services that can point you in the right direction. The tricky part is finding the right venue. Here are the things we consider:

Is this the right audience?
- Are audience members interested in my talk?
- Am I interested in being known by the audience members?
- Do I want to be associated with the other presenters?
How expensive is it to present here? (your company may cover some of the cost)
- Travel
- Registration fees
- Time away from the office
How prestigious is the venue?
- Who else presents or has presented here?
- Is this the first year? The tenth?
- Who are the major sponsors?
- City-level, Regional, International?

Most conferences will ask for a pitch to evaluate whether or not a talk is appropriate for inclusion in their proceedings. If you’ve been following along with the roadmap, you’ve got a number of sources to help you build the pitch:

The lightning talk
The introduction of your blog post
The outline for your brown bag
The introduction of your brown bag

From these, it should be easy to gather the central points of your talk, a description of who the target audience is, and what you expect that audience to gain from the talk. Those are the core components of a solid pitch.

Conclusion

Public speaking engagements are an important part of any career, yes, even yours. They help us hone our communication skills, reinforce our own knowledge on a subject, and improve the community that we work in. Although every presentation you give is the result of substantial investment, you do not need to spend all of the time at once. Spreading out the work reduces how much it impacts other obligations, like project work. Further, it provides more time for feedback and refinement which results in a better presentation overall.

Facilitation: Don't Lose Before You Start

2019-10-25T00:00:00+00:00

So you want to facilitate a workshop for a team? Maybe you’re external to the team and have been asked to help by facilitating. Awesome, it’ll be fun. Just show up at the time and place annnnnnnd you’ve already lost.

You better think (think)

Think about what you’re trying to do

– Aretha Franklin

Ask The Right Question

The workshop should be answering a question. That gives all of the participants a clear vision of what they’re trying to achieve. “What is preventing the team from moving faster?” is a very different workshop than “How do we improve our deployment process?” which is very different from “How do we fully automate our deployment process?”

Getting everyone aligned on outcomes is key to success.

Get to Know Your Stakeholders

If one person felt strongly enough about this to block off time on the team’s calendar, they are the First Stakeholder. Start with them. You need to understand what they want out of this workshop. What outcomes will make them call this a success? Help them understand their role in the workshop: getting the right people in the room, taking a step back, and letting the team be awesome. If there is no such person, that’s fine too.

Hopefully the First Stakeholder has conveyed their vision of success to the team. Validate that assumption. Talk to the rest of the team. Understand what they want to get out of the workshop. It’s better to discover any differences ahead of time rather than in the workshop itself.

Use these conversations with the team members to learn their perspectives, their pains, their goals for the workshop. Is it scheduled at the same time as their kid’s play at school but they’re forced to attend? That’s good to know. Find out who on the team is quiet, who interrupts, who isn’t afraid to speak their mind. Find out who on the team likes the status quo and doesn’t feel change is necessary.

If what you’re learning isn’t making sense, or there are incompatible goals, if some constraints can’t possibly be met, etc. then have a second sit-down with the First Stakeholder or with the team as a whole. Help them understand what you’ve learned. The workshop simply won’t be successful as framed - the direction needs to change. Be supportive and advocate for the team and the individuals you’ve talked to.

Learn the Team’s Communication Style

Ask if the team has established any norms (especially around communication styles) or shared vocabulary. You as facilitator need to be aware of these and use them in the workshop. If they don’t, be prepared to suggest some at the workshop. A good baseline could include:

Of course, just because the team says they have some established or agreed-upon norms doesn’t mean they’ll be executed perfectly. The usual facilitator responsibility still applies. Having talked about it, though, helps hold the team accountable to what they said.

Pick the Right Time of Day

It matters. If you have a team of night-owls, don’t expect a lot of dazzling creativity at 8am. If the team gets into the office before 8am, don’t plan the meeting for the late afternoon. If the workshop is early, provide breakfast. If it’s around lunchtime, provide lunch.

Daniel Pink wrote a book called “When” which goes into more depth on the topic of chronobiology. If you can, plan activities to occur at the appropriate time of day to correspond with type of thinking involved. Here’s a quick summary if you want to learn more.

Of course, sometimes the time is out of our control. Don’t sweat what you don’t control, just move on and make the best of it.

Planning the Workshop Activities

Kick It Off

The first part of any workshop should be to remind the team why they’re here. The goal of the kick off is to inspire the group. Consider having the First Stakeholder do this part. They must provide a vision of success. This sets the tone for the rest of the workshop and is foundational. It’s also a good time to talk about team norms around communication. Suggest some basic ones if needed. Use that as the foundation to set expectations with the team.

Pick the Right Activities

If I tried to talk about specific activities, this article would turn into a book. Luckily for us, Esther Derby and Diana Larsen already wrote the book: Agile Retrospectives: Making Good Teams Great. Think of it as a cookbook with recipes for activities. The activities are broadly broken up into three categories: gathering data, generating insights, and deciding what to do. There’s a description of each activity and a quick note about what the team should expect to get out of it.

Every activity should get the team closer one step closer to accomplishing its goal.

Vary Up the Type of Activities

There are three types of activities in most workshops:

Emotional or Creative - creative work like brainstorming or how does something make you feel? Example: “What pains have you felt when using the system?” or “What would the ideal system look like?”
Mechanical or Administrative - the most straightforward. Example: “Draw a diagram of the system as it is today.”
Intellectual or Analytical - sometimes requires focused attention. Problem solving. Example: “What steps do we need to take to mitigate the problems in the system?”

In general, I would start the workshop with an emotional activity. Bonding or trust building helps to get people comfortable speaking with each other. On the other hand, if the team needs to wake up (say, they’re night owls at a morning workshop), I suggest starting with a mechanical activity to warm up.

The majority of presentations are purely analytical. They offer information but no human connection. The goal is to mix analytical content with emotional content, which creates contrast and therefore creates interest.

– Nancy Duarte

She is talking about presentations, but her advice applies here too: vary up the types of activities to keep people interested.

Know Your Audience

As the facilitator, your audience is the team you’ll be working with in the workshop. Use what you learned from talking to people before the workshop to shape your approach and the activities.

For example, if there are team members who are naturally quiet or aren’t comfortable speaking up, most activities can be adjusted to help them out. A typical brainstorming activity could start with 5 minutes of silent brainstorming. That same change would help out team members who aren’t comfortable thinking out loud or extemporaneously.

Mitigate Common Stressors

We find that the percentage of favorable rulings drops gradually from ≈65% to nearly zero within each decision session and returns abruptly to ≈65% after a break. Our findings suggest that judicial rulings can be swayed by extraneous variables that should have no bearing on legal decisions.

– Extraneous factors in judicial decisions

Don’t let easily controllable extraneous factors cause distraction or reduce the effectiveness of the team. If they fail, it should be on their own lack of merit (I kid, I kid!). If the workshop intrudes on a mealtime, provide food. Regardless, provide snacks and drinks. Being hangry is a real thing!

Likewise, plan to take breaks about every hour. Each activity should either be done within an hour or be able to be paused for a few minutes at the one hour mark. Read the room and go longer or shorter as appropriate.

Pace Yourself

Estimate time for each activity (range, not single point). Know what you want to do if the workshop is running fast, or what can be cut or shortened if the workshop is going slow.

End With Action Items

Set the team up to succeed:

Recap where you ended up with the original goals. Were they all met? What remains undiscussed?
End with concrete action items.
Action items should have deadlines or target dates when possible.
Each action item should be assigned to one person. If everyone is responsible for an item, no one is responsible for it.

After the Workshop

How involved you are in the ‘after’ phase varies. In my experience, the best results come from the team committing and the facilitator offering to be available for advice, suggestions, and help. You’re the chicken, not the pig.

Key Takeaways

You know your context better than I do. To butcher something said by the famous George Orwell, break any of these rules before doing something that doesn’t make sense.

You should still consider everything I mentioned here. Be deliberate. That doesn’t mean you need to invest time trying to account for every possible outcome - be agile and lean and pragmatic. Spend more or less time preparing based on the importance of the meeting and the expected return of that prep time.

Plans are worthless, but planning is everything.

– Dwight D. Eisenhower

Improvise, adapt, and overcome.

It’s going to be fun.

Speaking: Making AI More Accessible to the Non-Developer

2019-10-11T00:00:00+00:00

Given at

PyData Indy 2019: Recording, Slides

Abstract

Many of our clients have domain experts who are identifying interesting properties in large sets of data. The experts are often systems or mechanical or electrical engineers who are not statisticians, data scientists, or programmers. Rather than hire one of those and teach them the domain, these clients want their existing experts to leverage AI techniques to better perform the tasks they are already doing.

There are many AI libraries available in Python, but they are designed to be used by programmers. We have been building some tools in Python to lower the barrier to entry for those existing libraries. We detect common errors early, make evaluation of learner performance easy, and visualization of learner behavior and the underlying data more accessible.

We’ll talk about what drove these decisions and walk through a simple example of using this tool on a readily-available dataset.

Description of target audience

Speaking: Cybersecurity in the Modern Age

2018-04-17T00:00:00+00:00

Given at

Indy.Code() 2018

Abstract

Cybersecurity is a critical part of the software we develop. New risks and threats are emerging every day while the cost of a breach has never been greater. However, even if the software professionals understand this, communicating the risks and impact to the rest of the organization is difficult.

Attendees will leave with a better understanding of the importance of cybersecurity, an overview of how threat modeling can be used to detect our own vulnerabilities before they’re exploited, and a framework for how to discuss cybersecurity with the larger organization.

Description of target audience

Anyone involved in the software development process, not just developers themselves, could benefit from learning about the state of cybersecurity and what we can do to make it better.

Speaking: Cybersecurity in the Age of IoT

2017-09-28T00:00:00+00:00

Given at

Prairie.Code() 2017

Abstract

Description of target audience

Security in the Age of the Internet of Things (abridged)

2017-06-02T00:00:00+00:00

Originally published at TechPoint.

The Internet of Things is growing fast. Connecting so many devices leads to better decisions, safety, and efficiency. But with this comes new security challenges. We, as the defenders, are in a constant arms race against malicious actors. They can fail to attack a system one hundred times and be no worse off. But it only takes one mistake in our defense for them to win. We have seen these growing pains countless times before (and will again) as technology changes.

What makes IoT security different?

Now that the number of devices involved is so much larger, there is a larger impact if things go wrong. Why is that?

Many of these devices are being made by companies without a strong background in security
Speed to market is a key metric in this emerging market
This encourages companies to do the bare minimum for security
Security is not a competitive advantage, so it often further deprioritized
Businesses often focus on the next version, leaving minimal support for released products
Deploying updates to already-released devices requires an investment in infrastructure

In short, security is rarely made a priority and given enough time or money.

Won’t the market self-correct?

Not with the current economic incentives: the cost of failure is externalized. Bruce Schneier has a great explanation:

Think of all the CCTV cameras and DVRs used in the attack against Brian Krebs. The owners of those devices do not care. Their devices were cheap to buy, they still work, and they do not even know Brian. The sellers of those devices do not care: they are now selling newer and better models, and the original buyers only cared about price and features. Insecurity is what economists call an externality: it’s an effect of the purchasing decision that affects other people. Think of it kind of like invisible pollution.

This is similar to how credit card fraud primarily affects merchants and banks, not the end user. In fact, some criminals find it more lucrative to keep their presence hidden and rent out the compromised device.

Why should consumers care?

A new type of malware is spreading that permanently disables any vulnerable IoT devices it can find. If this trend continues, customers will now be directly impacted.

Devices like the Amazon Echo (powered by Alexa) are becoming more and more popular. Alexa must listen to (but not necessarily record) everything that it can hear. What is the risk profile of an Echo (or similar device) being compromised?

Some IoT devices track health or fitness data (e.g. heart rate, temperature, footstep count, etc.) that can reveal a lot about you. How active you are and when can reveal when you are out of the house on your morning jog and your sleep patterns. Trends in this data can reveal if you are ill or have a chronic medical condition. Samsung’s new smart refrigerator can report its contents, which could reveal if you are on vacation. The type of food you eat reveals information about your health. The cost of the food you eat can tell a picture of your finances. On the small scale, this is invaluable for targeting individuals. On a larger scale, this information can be used to build profiles of consumers, which is nothing new, but now far more intrusive.

Why should businesses care?

Liability is murky in many of these cases (having not been tested in the courts), but there is a lot at stake. Take cars, for example. On the relatively tame end of the vulnerability spectrum is being able to get access to sensitive data on the car and its owner (which is still a big deal!). On the scarier side is the risk that hackers could exert more control over a big packet of kinetic energy with squishy humans inside.

For businesses, IoT devices are likely the weakest link in a security strategy. A compromised IoT device could easily lead to a far more serious breach. Attackers use such breaches to extort money from businesses. With a high potential cost of failure, even an empty threat cannot be ignored.

Where do we go from here?

The media can help by separating fact from fiction. “Hotel ransomed by hackers as guests locked out of rooms” was a sensational headline that certainly drew some attention. But it wasn’t true and only added to the fear, uncertainty, and doubt surrounding the issue.

The economic incentives described above need to change. We need to align manufacturers and consumers so security is at least considered. I’m not optimistic about this happening on its own. Historically, the free market does not address externalized problems well. You may have heard of the tragedy of the commons. This is where the government might have to step in. No one likes regulations, but sometimes they are necessary. It works for pollution and it could work here.

We in the industry can help by making it easier to get security right. Stronger industry-supported guidelines would go a long way towards setting a baseline expectation. Besides the purely technical concerns, we need guidelines for design and user experience. Monique Magalhaes rightfully points out that “the highest levels of security can only be achieved with equivalent highest standards of usability. They depend on one another.” Making security features more accessible to the consumer would go a long way towards improving security.

Whether we are businesses, journalists, technologists, or consumers, we need to enter this brave new world with eyes wide open. And while I hope my post freaks you out a little, I’m excited to see how we all come together to figure it out.

Security in the Age of the Internet of Things

2017-04-20T00:00:00+00:00

The Internet of Things is big. No, really big. No, even bigger than that. How big? My colleague Brad Boyer explains it better than I could (and handily defines the thing part of IoT, too). Go read it - I’ll wait.

Welcome back!

Security is hard. No, really hard. Ok, maybe not quite as hard as that. But it is easy to get wrong. Easy enough that OWASP publishes the Top 10 Most Critical Security Risks every few years, along with how to mitigate those risks. Yet those same vulnerabilities still appear in the wild. It is why we have sites like have i been pwned?.

The S in IoT stands for security

@lino

There are new attack vectors

Many of the current-day IoT devices are only recently Internet-enabled. In some cases, they’re only recently even digital. This is a radical shift in capabilities and platforms which results in new attack vectors that we are still trying to understand. We need to explore the implications of new devices with new capabilities in new contexts.

A perfect example is the prevalence of accelerometers. They are in nearly every smart phone out there, as well as other devices people keep on their person like pedometers. However, many people do not know they are a component in their devices, and many of those devices trust the accelerometer data too much. Who would think of an accelerometer as an attack vector? These researchers, for one. They came up with a series of acoustic attacks that can inject false data.

Alexa is the voice service that powers the Amazon Echo. This allows customers to use their voice to interact with devices. It is a great capability to have around the house, but its risk profile has to be carefully considered. We all know someone that enjoys pranks (there is a relevant XKCD for everything!) But I bet most customers never considered what could happen if a newscaster accidentally used the magic words on TV.

I hope the buyer understood the implications of buying a wireless-enabled sniper rifle. I hope the city council understood the implications of investing in light bulbs that could talk to each other.

New types of data can be exposed in a breach

Speaking of Alexa (see what I did there?), people are now realizing that in order to react to voice commands, Alexa must listen to (but not necessarily record) everything that it can hear. Some people are comfortable with that and some are not, but it is something about which all customers need to be aware.

Once it detects the wake word, according to Amazon, the Echo starts streaming audio to the cloud, where it is secured until the customer permanently deletes it.

Detectives requested access to the audio data from an Echo in a murder case. What is the “reasonable expectation of privacy” when dealing with a device that is always listening? What happens if police misunderstand how the technology works?

Let us look at a different data point: your heart rate. That can tell you a lot about someone. How active they are, and when. When they are asleep. If they are ill or have a chronic medical condition. Pacemakers are an obvious collector of that data. Indeed, in at least one case that data was used to prove arson and insurance fraud. Now there are more and more devices that a user might not expect to record their heart rate (for example, pedometers). One couple found out they were pregnant via their FitBit data.

Imagine what would happen if the data store were breached. Building profiles of consumers is nothing new, but now there are more ways to gather more data.

Samsung’s new smart fridge can report its contents. What is the risk profile of that data being leaked? If your fridge is empty, maybe you’re on vacation. The type of food you eat affects your health. The cost of the food you eat gives a glimpse into your finances. This information could be valuable to a malicious actor. A smart thermostat could have similar risks.

Children’s toys are now joining the IoT, which brings up new privacy concerns. Germany has already banned one such toy, and security researchers are concerned about another. When sensitive data is held by a third party, consumers need to consider the worst case. What happens when kids’ voice messages are leaked? Won’t somebody please think of the children?

Vulnerabilities are common and easy to find

IoT devices are marketed at a very broad audience, meaning consumers are less likely to be technologically adept. That makes secure default settings critically important, which many devices do not have. Even worse, many do not make it easy to change those defaults even if the consumer is aware of the need.

Manufacturers commonly load devices with a default username and password, which is easily looked up. However, some devices take this a step further and have hardcoded credentials which the user cannot change. Typically these hardcoded credentials are not even mentioned to the user, leaving them unaware of a large hole in their security profile. One of the more recent and nefarious malware packages, Mirai, scans for IoT devices that have known credentials.

In many cases a single manufacturer produces many devices with different brands (this is known as a white label product). The wide-spread nature of this business practice leads to what is known as a class break, where one smart person can come up with one clever hack that breaks an entire class of systems. In fact, that is exactly what happened when the Mirai author released their source code. That malware is not even very advanced, but it nonetheless effective. If a vulnerability is found in one device, many other brands and models may also be affected. Discovering which devices are the same, however, is something the vendors do not make easy.

Vulnerable devices have never been easier to find. There is even a search engine for the Internet of Things. Shodan makes it easy to search the web for IoT devices.

Vulnerabilities are hard to fix

Windows users have only recently gotten used to regularly updating their computers, and Microsoft has been working on that for many years. How many people think “it’s Tuesday, time to check if my refrigerator needs any software updates”? Many IoT devices are not even designed to be updated. This means once a vulnerability is discovered, it is only a matter of time until that device is compromised. Even if the device is factory reset, without an update it will be breached again. Even for some of the devices that support updates, it is not always easy. Combine that with the fact that some of the devices have an expected lifespan of 10 or more years and you can see how big of a problem this is.

Why should businesses and consumers care?

I have described above what could happen in the event of a breach. Some sensitive data could be leaked with some serious consequences. But there are more reasons than that.

One easy answer is that a vulnerable IoT device is likely the weakest link in a security strategy. A compromised IoT device has nearly the same threat profile as any other compromised device on a network.

What if “we do not have anything of value on our [network/site/etc.]”? You still have your reputation to think of.

Malicious actors are now using some compromised devices to anonymize their activity. The device is turned into a proxy through which the hacking, spamming, DDoS, or other attacks are launched. This makes it harder to catch the criminals, and introduces the possibility of innocent people being caught up in the investigation.

Unfortunately, with the proliferation of vulnerable devices and malware that can compromise them, criminals are building massive botnets. They use these botnets to extort money, censor opponents, or whatever they can make money doing. Even an empty threat is enough, sometimes. And these attacks are only growing in scale as time goes on.

Liability is murky in many of these cases, until it is tested in the courts, and there is a lot at stake. Take cars, for example. On the tame end of the vulnerability spectrum is being able to get access to sensitive data on the car and its owner (still a big deal!). On the scarier side is the risk that hackers could exert more control over a big packet of kinetic energy with squishy humans inside.

So why don’t they care?

Thankfully, Bruce Schneier has a great explanation:

Think of all the CCTV cameras and DVRs used in the attack against Brian Krebs. The owners of those devices do not care. Their devices were cheap to buy, they still work, and they do not even know Brian. The sellers of those devices do not care: they are now selling newer and better models, and the original buyers only cared about price and features. Insecurity is what economists call an externality: it’s an effect of the purchasing decision that affects other people. Think of it kind of like invisible pollution.

This is similar to how credit card fraud primarily affects merchants and banks, not the end user.

Criminals sometimes find it more lucrative to keep their presence hidden and rent out the compromised device.

Maybe consumers will start to take notice if a new trend of malware continues to spread that permanently disables any vulnerable IoT devices it can find.

Why is IoT different than what we have seen in the past?

These are the growing pains we have seen countless times before (and will again in the future) across various industries. Devices are being connected in new and novel ways. The “arms race” between attack and defense is changing very rapidly. New techniques are being developed on both sides.

However, now the number of devices involved is much larger, with a correspondingly larger impact if things go wrong. Why is that?

Never before have so many connected devices been so physically accessible
Many of these devices are being made by companies without a strong background in security
Speed to market is a key metric in this emerging market
This lends itself to cutting corners (or doing the bare minimum) when possible
Security is not a competitive advantage, so it often deprioritized
Supporting products after manufacturing requires a certain mindset (businessset?)
Deploying updates (or at least notifying the public of vulnerabilities) requires an investment in infrastructure

In short, security is not often made a priority or given enough attention (either time or money).

Won’t the market self-correct? Not with the current economic incentives. Neither the manufacturer nor consumer have a reason to prioritize security because the cost of failure is externalized. Even if the consumer were security conscious, there is too much information asymmetry between consumers and manufacturers. Consumers cannot easily find most of the information they would need to truly evaluate competing products.

Where do we go from here?

Probably the most important things is to carefully separate truth from fearmongering. “Hotel ransomed by hackers as guests locked out of rooms” makes for a sensational headline - it is sure to get a bunch of clicks. But it wasn’t true and only added to the fear, uncertainty, and doubt surrounding the issue. This is how we make sure we are solving the right problems, and not protecting against unrealistic movie plot threats.

We need to change the economic incentives described above. To align manufacturers and consumers so security is at least considered. It is even better if consumers can be aware of the risks that the IoT introduces and deliberate about their use of these devices. However, I am not optimistic about this. Historically, the market does not address externalized problems well.

That is where government regulation comes in. No one likes regulation for its own sake. No one wants the government involved unless it is necessary. But regulation works for pollution and other externalized problems (you’ve probably heard of the tragedy of the commons), and it could work here too.

At the same time, we need to find a way to make security easier to get right. For software and hardware development, industry-supported guidelines would go a long way to setting a baseline expectation. In addition to the purely technical concerns, we need guidelines for design and user experience. Monique Magalhaes rightfully points out that “the highest levels of security can only be achieved with equivalent highest standards of usability. They depend on one another.” Making security features more accessible to the consumer would go a long way towards improving security.

Refactoring JavaScript - a play in three acts

2017-04-10T00:00:00+00:00

Act 1, the setup

Once upon a time, there was a JavaScript codebase. This codebase used the function expression syntax:

const returnTheNumberOne = () => 1;

For reasons that aren’t relevant to this blog post, I needed to replace this with the function declaration syntax:

function returnTheNumberOne()
{
  return 1;
}

Act 2, the confrontation

Usually some clever find-and-replace (read: regular expressions), mixed with a bit of manual labor, would take care of this quickly enough. I started down that path with a few minutes of tinkering.

Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems. Jamie Zawinski

It didn’t take me long to realize I needed to find a better way:

The codebase had different types of function expressions, which meant I would need to write several different regular expressions.
This same transform would be used later on a different codebase, so I wanted something flexible and repeatable.
There was also a good chance that someone else would be doing this next time, so I wanted something others could understand easily.

Act 3, the resolution

Enter JSCodeShift, stage left. JSCodeShift turns JavaScript files into an abstract-syntax tree (AST). This provides an object model that can be used to do more complicated transforms than could be done on context-less text.

The wonderful AST Explorer will show what the AST looks like for both our input and target. I’ve marked up the ASTs from the two code snippets above to show how they are related. This should help explain what needs to be transformed and how.

A codemod is JavaScript code which will operate on the nodes in the AST. Typically, it will find nodes that match some pattern and replace them with something else. At a high level, it could look something like this:

module.exports = (file, api) {
  const j = api.codeshift;
  const root = j(file.source);

  function replaceNode(nodePath) {
    ...
  }

  return root.find(...)
             .replaceWith(replaceNode)
             .toSource();
}

Using the AST for the input code, the target is any VariableDeclaration node which contains an ArrowFunctionExpression node.

return root.find(j.VariableDeclaration, {
              declarations: [{
                init: {
                  type: 'ArrowFunctionExpression'
                }
              }]
            })
           .replaceWith(...)
           .toSource();

According to the AST for the target code, what we found will be replaced with a FunctionDeclaration node. If we created this node by hand, we would have to manage a lot of AST-related details: line numbers, object references, parent relationships, etc. Luckily JSCodeShift provides builder functions such as j.functionDeclaration(...) to do that for us. According to the FunctionDeclaration definition, that node is built with id, params, and body. We can get those from the VariableDeclaration and ArrowFunctionExpression nodes we found above.

function replaceNode(nodePath) {
  const { node } = nodePath;
  const variableDeclarator = node.declarations[0];
  const arrowFunctionExpression = variableDeclarator.init;

  return j.functionDeclaration(
            variableDeclarator.id,
            arrowFunctionExpression.params,
            arrowFunctionExpression.body);
}

return root.find(...)
           .replaceWith(replaceNode)
           .toSource();

Conclusion

It can take a little while to write a codemod, so a find/replace can still be faster in simple cases. There are also some cases in which small text changes result in significant changes to the AST that would require writing a second codemod. Analyzing the AST from this snippet is left as an exercise to the reader:

const helper = require('helper');

const helper = require('helper').foo;

Also, the way code comments are handled surprised me: they are properties of the closest node in the AST. That means they must be copied manually if you are changing that node.

JSCodeShift makes difficult or complicated code transforms much easier. The resulting code is far more readable than a regex. And when best practices change in the future, the codemod is easy to revisit, understand, and update for the new standard. The neverending march of progress just got easier.

JSCodeShift is a powerful new tool in our toolbox, though not one we’ll use every day.

Links used in this post:

Growing a Community

2016-11-10T00:00:00+00:00

This is part of an ongoing series of posts about a side project I am working on with Rob Uhl:

The DragonRealms community

com·mu·ni·ty

a group of people living in the same place or having a particular characteristic in common.

a feeling of fellowship with others, as a result of sharing common attitudes, interests, and goals.

a group of interdependent organisms of different species growing or living together in a specified habitat.

When I started playing DragonRealms (DR), I wasn’t really focused on the community. I was busy learning new mechanics, exploring the world, and listening to Rob wax nostalgic about his time in DR (15 years ago). And to be honest, the game systems themselves somewhat discouraged new players from interacting with other players:

I had no money to buy things from the community, and no skills that can contribute back to the community (e.g. crafting)
Most of my time was spent hunting rats to make enough coin to repair my gear to get back out hunting rats
Specific player-made items (which I could not afford) are needed to access most of the in-game chat systems
Many questions were answered with a link to the (mostly) official wiki, but just enough content is inaccurate or out of date to confuse a new player
There is a newbie help chat system which includes other newbies and volunteer mentors (members of the DR community who are of above-average helpfulness) - though as volunteers, they aren’t always available
The character-growth model of DR (perhaps the subject of a future blog post) encourages players to maximize the number of skills they train, which disincentivizes players from spending time idle (e.g. chatting or helping a new person)

I mean, you know you are part of a community when you play a multiplayer game, but at first you don’t really KNOW it… you know? Luckily for me, Rob was a great help, as were a few other players I ran into by seeking out popular hangout spots. And as with any other community, there is a learning curve: 20 years of informal rules, systems, and conventions have formed. Some of those are unspoken, undocumented, and few people will take the time to explain them. Ask me about the NPC healer sometime… It’s also hard when most of the in-game chat systems are strictly “in character” - that is, from your character’s point of view. It’s hard to get Ogg the Barbarian to explain the nuances of a complex system, even if Ogg’s player wants to help.

DR’s chat channels have the usual problems (strong language warning!) that crop up when you mix a normal person, anonymity, and an audience. There are some official policies around how this is kept in check, and the topic comes up constantly in DR forum discussions. There are even changes being implemented right now to the chat systems to try and reduce trolling and griefing (being deliberately irritating to upset others). I suspect there are many reasons for this, and it’s not an easy problem to solve.

The Lich community

com·mu·ni·ty

a group of people living in the same place or having a particular characteristic in common.

a feeling of fellowship with others, as a result of sharing common attitudes, interests, and goals.

a group of interdependent organisms of different species growing or living together in a specified habitat.

One of the things that Lich supports by default is a set of chat channels (hereafter, Lnet) that go through the Lich servers, rather than the DR servers. That means those channels do not need to adhere to the DR policies. DR does not (and will not) support out-of-character (OOC) chat, whereas Lnet does.

I believe this strengthens the Lich community - I’ve seen wonderful conversations on Lnet about life, careers, and relationships. In addition, the Lich community is much more positive than that of DR in general. I constantly see people healing others, discounting services (or even giving services and items away), answering questions on game mechanics or scripts, and so on. This cooperation and collaboration has a positive feedback effect.

There are a few training strategies that have become pretty popular in the Lich community (optimizing training would be a good future blog post), one of which requires a specific item that is hard to get. One generous Licher went and bought 20 of the item and handed them out to everyone that needed one - but they still had 10 left over. They wanted a way to make the items accessible to other Lichers in the future, but DR does not have an easy way to do that. In order to support cooperation, we created a character who only exists to share items within the community. Anyone can contribute items or request them.

We have another player whose character is a healer. He could be out in the game world training, but instead has decided to contribute back to the community by making himself available to heal Lichers. Everyone knows to first check if he is around before finding another healer (who are often slower and charge money for their services).

The Lich community is also resilient to disruption. A few months ago some well-known trolls and griefers joined Lnet. With their usual tactics, they tried to antagonize Lichers, who wisely decided not to engage with their antics. Instead, we simply continued having fun. Without people feeding their bad behavior, they got bored and either left or stopped being disruptive. Either way, the Lich community is better for it (and maybe we converted some of them to be productive members!). I hope that as we get more popular and our population grows, we will continue to foster good behavior.

A community within a community

com·mu·ni·ty

a group of people living in the same place or having a particular characteristic in common.

a feeling of fellowship with others, as a result of sharing common attitudes, interests, and goals.

a group of interdependent organisms of different species growing or living together in a specified habitat.

When we began writing our scripts, we took a very Agile approach. Write what we needed for our characters, add settings and configuration that worked for us, and expand the scripts’ capabilities over time as we encountered new needs or edge cases. This was fantastic for rapid development - getting the most functionality in the least development time.

But it also meant that we tackled error paths and edge cases as we encountered them. Our code was not perfectly robust from the start, and for the most part, that was fine. Most errors just stopped a script, and since we were at the keyboard, we would fix the problem and restart it. At worst a character might lose an item (ask Rob about his cleric’s shield sometime).

But occasionally, rarely, there would be a bug that was noisy. Typically these errors would be a broken while loop or bad conditional return that would result in spamming a room with commands. Even if we reacted in a few seconds, hundreds of commands would have been sent. After the first of these it was clear that we had to be responsible members of the scripting (and/or Lich) community, as members of the larger DR community.

To that end, we implemented a few different strategies in our scripts:

Be deliberate about pausing between commands or actions. In many cases, this is as simple as sending an action, then waiting until we see text that indicates the action was taken.
Check for repeated actions. For example, movement: do not go to one room only to immediately leave for a second room; instead we write a bit more code to detect this case and go directly to the second room.
Use timers to check for infrequent game state changes, rather than checking more frequently. For example, characters can teach a class, but this is rare. We only check for active classes every few minutes.
Avoid using common hangout spots for training. This keeps spammy training processes away from players that want to congregate and interact with each other.

The truth is that we need to be careful that our scripts do not negatively impact those around us. Furthermore, we need to be acutely aware of the perception of others in the DR community. Even though we are following the official scripting policy, some people take offense to our use of scripts. It is common for those players to try to break our scripts, for example, by slipping an item into a character’s hand. Our scripts need to be robust and handle unexpected game state, as well as being careful when recovering from an error.

Testimonials

I asked on Lnet what they thought about the Lich community (names have been removed for privacy):

Person ‘K1’:

The collaborative effort is certainly helpful. Lnet is extremely helpful. Whereas my experiences with genie [an alternative front end and scripting solution] were rather… solo. Even when my friend and i helped develop some plugins for genie, it still felt like the community kept the best secrets to individuals. Knowledge-sharing wasn’t a big thing. it was still the “i’ll share a bit, but my script will always be better”. For example, the necro healing conversation that we’ve have been having. Wouldn’t have really happened when i was rockin’ genie seriously.

Person ‘M’:

The community aspect definitely isn’t something to understate. DR-lich is super friendly and helpful.

Person ‘A’:

By the way just wanted to thank everyone in lich for being so helpful. I wasn’t sure if I was going to stick around but going to be upgrading my account and unlocking my old one.

Person ‘F’:

I just started playing this again because they sent out free codes. If it weren’t for the lich community, I’d be gone again already.

Person ‘K2’:

I think the real linchpin of Lich is the fact that so many of us remain because of Lnet. Lnet demonstrates that OOC chat can be friendly and helpful. I’ve read on the official forums that Lnet chat is horrible and trollish, and that just has not been my experience. We’ve managed to not have Lnet turn into Barrens chat, as it were. I suspect because collectively we’ve gone out of our way to be helpful, whereas the game world simply doesn’t allow for it in meaningful ways.

Why Are We Writing These Scripts?

2016-10-31T00:00:00+00:00

This is part of an ongoing series of posts about a side project I am working on with Rob Uhl:

We’ve talked a lot about the infrastructure we’re working with, but haven’t spent much time on what it is we’re actually building (or, for that matter, why). At a low level, a script is simply a Ruby file with the .lic extension. At a higher level, a script is a way to automate some manual steps. It can only do what a user can do, albeit with more speed and accuracy.

Why use scripts?

Speed and accuracy are definitely advantages over not using scripts - not to mention making sure you don’t forget a step when doing something involved. Many games have taken the approach of disallowing scripting in any real sense (see: World of Warcraft macros). DragonRealms (DR), however, has quite a liberal scripting policy.

DR has been in development for over 20 years. Over that time, many systems have been introduced, modified, removed, and reimplemented. As in any large-scale software effort, sometimes the new and old system coexist for a time. Sometimes a very long time. For example, there are hundreds of non-player characters (NPCs) from whom you buy various items.

Some of these NPCs use one system in which you must read from an item in the room to see what they sell (usually a catalog, a register, or one of several other nouns). Then you issue the buy command, which does not actually buy the item, but instead asks the NPC how much they want for it. Then you offer the amount to complete the transaction.
Other NPCs use a system in which you order to see what they have available, then order item to complete the transaction.
Some of the NPCs that use order treat order item as a request, which then requires you to order item a second time to complete the transaction.

I consider remembering which NPC uses which system to be mental overhead. For me, dealing with three different ways just to buy an item from an NPC takes me out of the game - it breaks my immersion. I want to think at the ‘buy an item’ level of abstraction. So I took the time to write a script that deals with the how. From now on, I can use that script (and reuse that code in other scripts), letting me think in terms of what.

Focus on what is fun

Let’s look at crafting (I’ll be using Forging for these examples, but the points apply to all crafts). In DR, it is very involved - there are many steps, each in the right order, and you have to watch for random mistakes to appear and then correct them. One person’s deep, rewarding, and immersive crafting experience is another person’s tedium. That’s where scripts come in: letting you, the player, think at whatever level of abstraction is the most fun for you. I think that’s pretty awesome.

At the lowest level of abstraction is the player that wants to do it by hand (and there’s nothing wrong with that!). They’re going to type pound ingot on anvil with my hammer, wait to see if their character made a mistake (such as because they’re making a difficult item relative to their skill level), then type push my bellows to keep the flames hot, and so on - continuing until the process is complete. Very immersive, very much a role-playing game. You can practically feel the heat on your face as you read the text (seriously - the text is DR is very well-written!):

Sparks fly into the air as you transfer the scissors back and forth between the forge fires and the anvil, alternating heating with vigorous hammering of the metal. The work proceeds as planned and you avoid introducing any defects.

But for those that want it, we have a script named forge which automates the crafting steps only. It starts with an ingot and ends with a finished item. You are responsible for procuring an ingot, finding an unused anvil, and so on. But if you don’t find that fun, we have another script named smith that will take care of buying an ingot from an NPC (taking care to use the right verb for each NPC!), search out an unused anvil, and then start crafting.

The beauty of this system is that scripts are purely additive - they do not take away from the game. They are tools in your toolbox, only doing as much or as little as you want them to. And your need can easily change over time. The first time you craft, you should do it by hand to understand how the process works. The 300th time you make something, you may decide to use a script. And because of the experience and skill model of DR (the topic of a future post), if you want to get good at a craft, you’ll eventually be making that 300th item (or 3000th…).

But you don’t have to take my word for it

I asked some of the folks using our scripts what they thought (names have been removed for privacy):

Person ‘E’:

I use scripts to train, and perform matters of rote for me so that I can spend the time I would normally be available to play as an opportunity to roleplay and interact with others instead of feeling pressured to work on progressing. Without scripting i feel like i have to choose between roleplaying and making progress given the time sink involved. Scripting enables me to enjoy both sides with giving one up.

Person ‘C’:

I find watching my character play the game through logic I’ve written (or some else) is really satisfying. Writing a script to do some complicated task, watching it fail terribly, fixing it and then finally when it works for the first time; it feels like an accomplishment. And less to the point, you have this really nice collaborative project going so we can all share and improve on each others work. Also time is a precious commodity for people, having it spent on braiding grass or really any DR skill training is not adding to my immersion in any game world. I think its interesting the first time, so you see a flavor of how it works, read the text, and form a mental image of what your character is doing… but beyond that its just a waste of time really.

Person ‘I’:

I agree, I think of DR as the ultimate grind and scripts help with that.

Person ‘N’:

Just wanted to say thanks again for the amazing amount of work you all do on this. It’s changed DR for me.

Person ‘V’:

I would also venture to say that in writing a script you’re taking a deeper look at what you’re doing, which is fun. In writing a script you’re taking the time to think about it and make it efficient. You’re thinking about why you’re responding to things and how you react and why. That’s pretty neat. I wish there was a way to force me into that mental framework in everyday life, I’d probably be a better person lol.

What We've Got Here is Failure to Authenticate

2016-10-22T00:00:00+00:00

In the previous post, we set up server-side rules to redirect HTTP traffic to HTTPS. Using HTTPS ensures that the client and server are communicating securely and that no one is intercepting the traffic. An example of this redirection is in row 1:

But there’s still a problem: the browser is making that initial request over HTTP. That request is still vulnerable and a malicious entity could prevent the redirect to HTTPS.

HSTS and you

HTTP Strict Transport Security (HSTS) is a security policy which indicates that your site should always be accessed over HTTPS. Enabling it means that now your browser won’t make that initial connection over HTTP. Instead it will internally redirect itself to the location from before, which uses HTTPS.

Luckily for us, Cloudflare makes it easy. On the Crypto configuration page, there is a HSTS setting. Before you can enable HSTS, there’s a bunch of warning text to read and acknowledge, and for good reason. Since you are telling browsers to always use HTTPS, if HTTPS somehow becomes disabled or invalid on your site, users will not be able to view it. The HSTS setting has a ‘max-age’ which indicates for how long it is applicable. That means your site may be completely inaccessible to users for that long.

Don’t let the warnings scare you. As long as you’re aware of the implications, HSTS is a good security feature. Test your HTTPS connection thoroughly first. Then when you are confident it is working, set ‘max-age’ to a small value (ideally 1 day or so; but if you’re using Cloudflare you are stuck with 1 month). Continue testing and gradually increase ‘max-age’. Also be aware of browser compatibility.

To disable HSTS, carefully reverse the process. Turn off the HSTS policy, but keep supporting HTTPS until ‘max-age’ has elapsed. Then you can disable HTTPS.

But there’s still a (smaller) problem: HSTS only prevents the browser from making subsequent requests over HTTP. The browser is still making that initial request over HTTP, which is a potential vulnerability.

Preloading to the rescue

Many smart people have thought this over and decided that browsers should have a list of sites which support HSTS preloaded when they ship. If you visit a site which is in this list, your browser doesn’t even make that first call over HTTP - it already knows to use HTTPS.

To submit your site for inclusion in the preload list, you must redirect HTTP traffic to HTTPS and include the HSTS header. The max-age must be at least eighteen weeks, use the includeSubDomains option, and use the preload option. The steps on these two blog posts, plus Cloudflare’s defaults where not specified, meet those requirements. Now it’s just a matter of visiting the Chromium HSTS preload submission app.

When Good SSL Certificates Go Bad

2016-10-11T00:00:00+00:00

I recently wrote a blog post after a long period of inactivity and I got some feedback. The most common response was “you blog?” - but the second most common response was “hey, your SSL certificate is bad”. This was rather unexpected since I use GitHub Pages specifically to avoid having to think about that sort of thing.

Sure enough, when I went to www.rpherbig.com in Chrome I got an Unsafe Site warning:

That’s no way to greet people visiting my blog. Proceeding to the site gives a bit more information:

It turns out that this is a known problem when using GitHub Pages and a custom domain. In fact, it’s been a problem since at least 2014. I’m not sure how it took me this long to notice, but enough is enough - it’s time to do something about this.

You only need one piece of flare

Enter Cloudflare, stage right. Cloudflare’s product sits between the end user (you, reading this blog post) and the content server (in this case, GitHub Pages). Cloudflare offers a whole lot of services - among them making it easy to configure SSL (image courtesy of CloudFlare’s blog post on the introduction of strict SSL):

The signup process is painless and straightforward. I won’t detail the steps I took here since I used the defaults. Do note, it took the better part of a day for my SSL certificate to be authorized, and a bit longer yet for the name server (DNS) changes to propagate and take effect. The next day I was back in business:

Not so fast…

All of our hard work only matters if the visitor is using HTTPS, so let’s force its use. GitHub Pages allows you to enforce HTTPS, but only if you are using the github.io domain.

For a custom domain, it’s a bit trickier. You will need to create up to three Page Rules in Cloudflare (depending on if you’re using a www subdomain like I am):

URL matches	Setting
http://rpherbig.com/*	Always Use HTTPS
http://www.rpherbig.com/*	Always Use HTTPS
https://rpherbig.com/*	Forwarding URL (301 - Permanent Redirect): https://www.rpherbig.com/$1

Once you have the Page Rules in place, I highly recommend testing them by visiting each of the URLs to ensure they redirect properly. In this example, you would test http://rpherbig.com, http://www.rpherbig.com, and https://rpherbig.com - and expect them all to redirect to https://www.rpherbig.com.

Here you can see my test for http://rpherbig.com. Cloudflare redirected us to https://rpherbig.com (row 1). Then https://rpherbig.com was redirected to https://www.rpherbig.com (row 2). Then the final URL of https://www.rpherbig.com was loaded (row 3).

It’s important for the security of your site that these Page Rules be set up correctly so that the redirects happen in the proper order. If https://rpherbig.com redirects to http://www.rpherbig.com, you’re in trouble, even if you eventually end back up on HTTPS.

A Lot Can Happen in a Year

2016-09-30T00:00:00+00:00

One year ago (346 days, but who’s counting?), Rob Uhl introduced me to DragonRealms (DR), a game he played many years ago. DragonRealms is an online text-based role playing game (RPG), also known as a multi-user dungeon (MUD). MUDs were the precusors to today’s massively multiplayer-online games (MMOs). I played many a MUD back in the day, though not this one, so I was interested. DR used to require a paid subscription to play, but the recently added free to play (F2P) option made the barrier to start playing virtually nonexistent.

In true RPG fashion, DragonRealms has a very large set of skills that impact your gameplay. But unlike many RPGs, you gain experience and levels for each skill independently, and the experience gain is based on your usage of that skill. Want to get better at swinging a sword? Go swing a sword a lot. But that won’t help you swing a mace or craft some armor.

It quickly became apparent that some parts of the game were very repetitive. For example, you first have to climb hundreds of trees to train up your Athletics skill before being able to take a shortcut (swimming across a river instead of waiting on a ferry). This is analogous to the ‘treadmill’ effect in many MMOs. Don’t get me wrong - there are many interesting and non-repetitive parts of the game, but in some cases you have to slog through the tedium to get to the good parts.

Why should you care? Why am I telling you this? Well, like any good software engineers, we saw an opportunity to automate the boring parts. So we set out on a year-long journey (that is still ongoing).

The default front end had some basic scripting capabilities: regex matching, loops, and labels/GOTOs - very BASIC-like. You can imagine how much fun that was to use. Even a basic script like selling gems could run over 700 lines. And there’s not really a meaningful way to debug that mess if you make a mistake. It’s the Volkswagen of scripting languages - it’ll get you where you want to go, but it’ll be uncomfortable. That lasted about a week before we started looking for other options. We evaluated several and ended up picking one, Lich, and a year later we’ve written 20,000 lines of Ruby.

“But Herbig, you yada yada’d over the best part!” I hear you say. That’s right - no one writes 20,000 lines of code without some good stories to tell. Rob and I will be writing more posts in the future about some of the interesting things we’ve done for this project.

In the meantime, I’ll leave you with some numbers, because who doesn’t love numbers?

First commit: Oct 16, 2015
17 contributors
3468 commits
705 issues
166 closed PRs
20,240 lines of Ruby (code)
7,941 lines of YAML (configuration and data)

Spoiler alert: it’s pretty awesome.

GL HF

Book Review - The Talent Code

2015-07-17T00:00:00+00:00

The Talent Code
Daniel Coyle
ISBN-13: 978-0553806847

Overview

What is the secret of talent? How do we become great at something?

Coyle suggests that myelin is behind it all. Myelin is an insulating material that forms a sheath around nerve fibers in the brain. The stronger the myelin sheath, the better the signal strength, speed, and accuracy of the nerve impulse. This in turn makes physical and mental actions quicker, clearer, and more accurate. This is what we commonly refer to as a talent or skill.

Now we have a new question to ask: how can we promote myelination? Coyle suggests that there are three components: deep practice, ignition, and master coaching. The book is full of case studies to illustrate how this works, so I’ll give a short description of each part.

First, it is important to note that practice is not deep practice. Simply going through the motions of practice won’t cut it - deep practice must be deliberate. This deep practice, as Coyle defines it, requires several things:

A deep practice session must be focused on learning.
We must purposefully operate at the edge of your ability. If we aren’t making mistakes, we won’t learn anything new.
We must be able to accurately identify mistakes. If there is not a clear distinction between success and failure, we can’t tell if new approaches and techniques are working or not.

If we are going to invest enough time and energy to grow our talent, we need to be highly motivated. Building that motiviation is what Coyle refers to as ignition. I call it engagement. I think some might call it passion. Whatever the name, we must be interested and invested in learning.

Master coaching is the concept of a third party that assists in the learning process. The coach does not need to already be an expert in the skill that is being learned, though it helps. Rather, the coach is there to facilitate deep practice sessions and sustain ignition (such as with encouragement and motivation).

Takeaways

Ignition and deep practice can be mostly driven by the individual. Finding a master coach seems more difficult.

The best coaches/mentors don’t need to be Great Leaders, they need to listen and observe. It is not inspiring speeches that build talent, it is small, targeted, highly specific suggestions. It is not pep talks, but rather customizing a message to the personality of the student.

Break everything down into its component pieces. Actions, thoughts, movements, bars of music. Small components make it easy to focus on repetition and quick iterations, which are key. We need fast feedback on failure. That sounds familiar - where have I heard that before?

Myelination is one-way (wraps, it does not unwrap), barring disease, injury, or age. This explains hard-to-break habits - it is easier for impulses to fire for well-established bad habits than new good habits. We must keep going until the pathway for the good habit is stronger.

When praising others, do not praise smarts. This leads to an emphasis on appearing smart, which encourages low risk-taking behaviors. If the person is not taking risks, they are not operating at the edge of their skill, which slows progress and learning.

Questions

How can we sustain ignition?

How can we become master coaches?

Can we get into “deep practice” mode at work? That is, can work be treated as practice?

How do we train “slow” or “low feedback” skills? A few examples that came to mind would be architecture and estimation.

Book Review - The Wisdom of Crowds

2015-01-28T00:00:00+00:00

The Wisdom of Crowds
James Surowiecki
ISBN-13: 978-0385721707

This book is in two parts. The first part explains Surowiecki’s theory of the wisdom of crowds: under the right circumstances, groups are remarkbly intelligent, and are often smarter than the smartest people in them. This can happen (so the theory goes) even if most of the people within a group are not especially well-informed or rational.

Think about that for a moment… A group of laymen can outperform experts. It seems so counterintuitive. What kind of a game changer would it be if it were true? (That’s rhetorical, but you can still send me your thoughts!)

The second part of the book consists of case studies. These are situations in which a crowd, which may consist of non-experts or include a small percentage of experts, outperform the experts alone. There are many case studies provided, most of which are rather interesting.

Are crowds actually wise?

Maybe.

Surowiecki does a great job explaining his theory. His writing and approach makes it very accessible to a wide audience. He provides a lot of case studies - around half the book!

But I’m still not convinced of the efficacy of the wisdom of crowds. The case studies in the book seem cherry-picked to support the theory. A reviewer on Amazon pointed out that the world of Wall Street provides plenty of negative examples to counterbalance the positive examples in the book.

If so, under what conditions?

The author proposes that most problems fall into one of three categories: cognition (something with one or more correct answers), coordination (characterized by a systemic solution), and cooperation (get self-interested and distrustful actors to achieve a common goal).

The book claims that for a crowd to be wise, it needs diversity, independence, decentralization, and aggregation. The first three are pretty clearly explained in the book, but the fourth is left rather vague. The book says to design the aggregation mechanism such that errors or incorrect answers distribute evenly (i.e. cancel out) and correct answers aggregate. That makes sense, but it’s not exactly practical advice - the book doesn’t really explain how to do this.

I think the theory is promising, but I have my reservations: the restrictions on the problem space, the difficulty of determining who makes up the crowd, and the complexity of aggregating the crowd’s solutions. I’m not the only one with these concerns: for more reading, check out this link and this one.

Book Review - Waltzing With Bears

2015-01-27T00:00:00+00:00

Waltzing With Bears: Managing Risk on Software Projects
Tom DeMarco and Timothy Lister
ISBN-13: 978-0932633606

You’ve probably heard of this book, even if you haven’t read it. You’re probably already familiar with a lot of the ideas in this book, even if you haven’t read it. That’s because a lot of the advice in this book has become best practice for risk management.

DeMarco and Lister devote several chapters to convincing you that risk is bad and managing it is good (i.e. will help lead to a successful outcome). I was surprised that they spent so long on what I thought was obvious, but they point out how common ignoring risk is in our field. No one wants to give or receive bad news, and in some corporate cultures it’s not even possible without repercussions.

A good point that the authors spend quite a while on is that a delivery date should not consist of a single date, but rather a probability distribution. This date is at 50% confidence, this date is 80%, and so on. You can treat risk the same way; for example: this risk has a 50% chance of occurring and will have an impact of 2 weeks if it materializes. The book gives some specific examples how to determine reasonable curves for various parts of a project (risk included), and then how to combine curves into the probability for the delivery of the project as a whole.

That is all predicated on the ability to quantify risk and how it will impact the project, and the book offers guidance on how to do this. It also acknowledges that sometimes a company’s culture will prevent the application of these techniques. You have to make do with what you have.

Following from all of this is the interesting idea that you can express commitments as probability distributions. You can then help your stakeholders understand the most likely outcomes of the project, as well as what factors influence those outcomes.

GitHub Pages and Jekyll and Windows, Oh My!

2014-11-29T00:00:00+00:00

You may have heard of a small company based out of Albuquerque: Micro-Soft. Don’t feel bad if you haven’t, they’re a pretty small company (but keep an eye on them, I hear they’re going to have a huge IPO in ‘86). Because they’re such a small player in the market, Jekyll doesn’t officially support their operating system. However, Jekyll has endorsed a guide by @juthilo that “seems to work for most”.

Don’t get too excited though, because if you followed my advice and used GitHub Pages, that link is just a red herring (much like Communism, according to Wadsworth). What follows is cherry-picking parts of several guides to get it all working.

The Setup

The zeroth thing you’ll need to do is setup your GitHub Pages repository and clone it locally (left as an exercise to the reader).

The first thing you’ll need to do is install Ruby. Follow the instructions on only page one of juthilo’s guide, then return here.

Second, we’re going to install Jekyll, but we’re going to do so in a way that is compatible with Pages. Create a file in your repo named Gemfile and put the following in it:

source 'https://rubygems.org'
gem 'github-pages'
gem 'wdm', '>= 0.1.0' if Gem.win_platform?

Now open a command prompt (I suggest GitBash), navigate to your repo, and run gem install bundler, then bundle install. This will take a little while, but it ensures that we are only using gems allowed by Pages (one of which is Jekyll itself) and the appropriate versions thereof. GitHub is very restrictive as to what gems you can use with Pages, and rightfully so since the code will be running on their servers.

Now run jekyll new . to create your site with a bunch of defaults. You can now build your site locally before publishing by running jekyll serve and opening http://localhost:4000 in a browser. By using serve, changes to files will be updated immediately - just refresh the page. You can push a changeset to GitHub when you are happy with the result and it will be published to your site.

Technically, you can stop now. You have the tools to manage your blog. However, if you want to use syntax highlighting there’s one more hoop to jump through. Otherwise you can skip the next section.

Syntax Highlighting

Page three of juthilo’s guide has a nice comparison of two popular syntax highlighters (Pygments and Rouge). However, Pages does not support Rouge, so the decision is made for us.

Go ahead and follow the instructions on only page three of juthilo’s guide, choosing Pygments and skipping Rouge.

If you accidentally set your highlighter to Rouge, you’ll get an email from GitHub saying that deployment of your site failed, but with an empty error message (needless to say, it took me a while to figure that one out).

Start using Jekyll

Here are some of the more interesting files/directories in your repo right now:

_posts/ contains your posts. By default it has one named Welcome to Jekyll that you may or may not want to keep.
_site/ contains the static HTML for your site, if you built it locally by running jekyll build.
.gitignore specifies files that Git should ignore. You should add _site to it.
_config.yml stores, you guessed it, configuration. You should update the placeholders with something more useful.
about.md is your “About” page. You should update it with something more useful.
README.md was created when you made the repo on GitHub, and has nothing to do with Jekyll. It is only visible when someone browses GitHub, not your site. Nonetheless, you should update it.
More information can be found on the official Jekyll site.

To publish a new post, simply create a files in _posts/. Files in this directory must be named YEAR-MONTH-DAY-title.extension, where extension is either of the two supported formats (.markdown or .textile). More information can be found on the official Jekyll site.

Drafts

If you’re like me and have multiple machines, you may be interested in the “drafts” functionality offered by Jekyll (drafts are simply unpublished posts).

Create a _drafts/ directory and commit your works-in-progress to it. These files will not be shown on your site, but you can now leverage the power of git while you work on your future posts.

You can preview your drafts locally by adding the --drafts switch when you build or serve Jekyll. Drafts will then show up as if they were published posts. This switch is local only - it does not affect how your site will deploy to Pages.

To publish a draft, simply run git mv _drafts/title.extension _posts/YEAR-MONTH-DAY-title.extension and commit/push. Adding the date to the file’s new name is mandatory.

What’s Next?

This was the easy part. Now you need to fill your blog with content!

But as for your site, there’s a lot you can do. One of my coworkers started tracking his professional development projects. Another wrote a neat Jekyll theme.

As for me, I’m not sure what I’ll do next. Off the top of my head, I want to look into a few things: custom domains, analytics, and RSS vs Atom. But I make no promises as to where the Muses take me next. If you have a suggestion or request, feel free to drop me a line (check the footer for my contact info).

GitHub Pages and You

2014-11-23T00:00:00+00:00

Blogging should be about the writing, not the mechanism for displaying text. For this grand experiment, the first step is just to get some text served up in the easiest way possible (agile blog design, if you will).

Let’s avoid as much work as possible: no custom domain, no hosting, no database, no theming. How could we possibly get away with that? Hint: it’s in the title.

What is GitHub Pages? If you create a repo with a specific name (username.github.io), the content will be automatically served up at http://username.github.io. It’s the kind of URL you don’t take home to mother, but it’ll work (remember, the emphasis is on the writing). And with GitHub taking care of all the hosting headaches, it’s worth it.

GitHub’s own site does a good job of explaining it in detail. By the end of their instructions, you will have an externally accessible site and a static index.html page. Pushing to the repo’s master branch will automatically update the served content.

Now what? Where to go from here? The end of the GitHub Pages tutorial offers some suggestions: use Jekyll to start a blog, set up a custom URL, or set up some more advanced features like a custom 404.

Since we’re going for simplicity, let’s start with turning that static index.html into something a bit more useful. Jekyll is a static website generator that was recommended to me, and in turn I recommend it to you.

GitHub Pages and Jekyll were designed to work together. It’s smooth sailing ahead as long as you aren’t using Windows. If you are, batten down the hatches and hang on. I’ll be writing soon about the edge case that is Windows soon.

Hello world

2014-11-16T00:00:00+00:00

A wild blog has appeared!

I’ve considered blogging for a while now, but somehow I never quite got around to it. I recently felt particularly motivated, so I sat down to start writing.

And promptly stopped. I had no idea what to write about. I decided to take a quick detour and get a blog up and running. It would buy me time to think of something brilliant to write. How hard could it be to set up a simple blog?

Let’s start with a popular blogging tool, Jekyll. Mix in an easy hosting platform like GitHub Pages. Sprinkle in a dash of Google Domains for a personalized domain. I’ll do my writing on my laptop, a Windows machine, and run Jekyll locally before publishing.

Spoiler alert: it didn’t go as smoothly as I expected.

What was supposed to be a nice leisurely exercise in procrastination turned into actual effort and my first few posts. It’s funny how things work out.

The blog of Robert Herbig

Speaking: When is a Regular Expression Better Than Artificial Intelligence?

Given at

Abstract

Tags

Description of target audience

Speaking: What Are AI Agents, Anyway?

Links

Abstract

Tags

Description of target audience

Course: Building‍ Security into AI

Links

Abstract

Tags

Description of target audience

Speaking: Can We Learn to Manage Uncertainty? Probably!

Links

Abstract

Tags

Description of target audience

Vibe Coding Is the Purest Form of Agile (And That's the Problem)

Vibe Coding Appears Deeply Aligned with Agile

But Vibe Coding Quietly Violates Agile’s Deeper Principles

Bridging the Gap Between Vibe and Viability

Why Vibe Coding Fails - and How Signal Coding Fixes It

Vibe Coding and the Drift Into Entropy Loops

Self-reinforcing Entropy Loops

What Is Signal Coding (Really)?

Core Practices of Signal Coding

Plan and Structure First

Prompt Intentionally

Inject Durable Signal

Stabilize and Refactor

Why Vibe Coding Fails Over Time

Failures Driven by Limited Context

Failures Intrinsic to Vibe Coding

Symptoms of the Entropy Loop

Signal Coding: Breaking the Entropy Loop

Speaking: Escaping the Trap of Self-Sabotaging Meetings

Escaping the Trap of Self-Sabotaging Meetings

Given at

Abstract

Meeting Facilitation Don’t Lose Before You Start

Given at

Abstract

Tags

Description of target audience

Speaking: Avoiding False Starts with Artificial Intelligence

Links

Abstract

Tags

Description of target audience

Speaking: What Does Security Look Like When Building AI?

Given at

Abstract

Tags

Description of target audience

Speaking: GenAI Adoption: Balancing Compliance, Innovation, and Action

Links

Abstract

Tags

Description of target audience

Speaking: AI is More Than Just ChatGPT - How AI Can Help You Today

Links

Abstract

Tags

Description of target audience

Guest: AI and UX: Managing Expectations and Implications

Links

Abstract

Tags

Description of target audience

Speaking: Making Machine Learning More Effective By Applying Agile Practices via MLOps

Given at

Abstract

Tags

Description of target audience

Speaking: Solving AI Problems the Easy Way With Off the Shelf Tools

Links