This quarter, our experiments were focused on AI enablement, exploring new tools, and improving workflows. Below are a few highlights from what we explored during CCC Days.

AI Experiments

Building a Metics Dashboard with AI

As part of our ongoing AI-focused experiments, we launched a bold experiment: Could a non-technical team build a functional internal dashboard tool using only natural language prompts and generative AI? The result is a standalone prototype of our Project Management (PM) Scorecard, created without traditional coding.

The PM Scorecard aggregates weekly project metrics from multiple data sources (task tracking, time tracking, and retrospectives) into a central dashboard. Historically managed through a complex and manually updated spreadsheet, the scorecard tracks key indicators like on-time delivery, roadmap confidence, team collaboration, and budget adherence.

Our MVP achieved automatic score calculations and a working interactive dashboard. While automated data collection remains unfinished, we proved the concept: lightweight AI tools can empower non-developers to build useful internal products quickly.

Agentic MVP

At RoleModel, we are always looking for ways to accelerate development by leveraging AI to streamline boilerplate code generation, enabling teams to focus on higher-order problems that will result in delivering customer value. Our goal was to cut down the time spent on initial codebase setup for a Minimum Viable Product (MVP) by using tools like GitHub Copilot to create entity relationship diagrams (ERDs), roadmaps, and user stories—transforming abstract plans into actionable steps. 

Leveraging assets from our sales process, we generated a foundational roadmap with user stores, iterating on prompts to balance speed and accuracy. AI also helped us quickly scaffold views, forms, and navigation, while building tests, both model and system-level, that aligned with system goals.

Though this effort wasn’t without its challenges, we’ll continue to refine our prompts and examples as templates for future projects. This approach isn’t just about speed—it’s about creating a more complete and stable foundation for exploring complex problems earlier in the development cycle.

n8n QuickBooks agent

We explored building an AI agent in n8n, a self-hosted workflow automation platform,  to streamline interactions with QuickBooks Online, aiming to allow our team to answer client-centric questions about invoicing, payments, and company performance. 

Our key takeaway was the importance of structured data: preloading fixed datasets based on customer names for prompts allowed the tool to efficiently retrieve invoice and payment details for multiple clients in a single query. However, performance remained a hurdle, highlighting the need for optimization. 

We learned that providing full context upfront, rather than expecting dynamic problem-solving, was critical for success. This experiment underscored the value of combining structured data, clear prompts, and thoughtful model integration to create a functional, albeit imperfect, AI-driven workflow for QuickBooks.

Process and Tool Experiments 

LightningCAD Static AR

We’re pushing the boundaries of visual design with our new static Augmented Reality (AR) feature for Railing Designer, empowering users to overlay their 3D railings configurations within real-world photos. We’ve previously explored live AR; given the current state of hardware, we see value in a static version that allows for viewing the scene without being on-site.

This experiment demanded intricate math and iterative problem-solving, such as navigating complex research papers and refining trigonometric approaches to simplify calculations, but we made significant progress.

This innovation enables a seamless workflow: users capture a photo, load it into the app, and draw two sets of parallel lines to define horizontal and vertical surfaces. The 3D view then dynamically adjusts to match the image, enabling users to visualize railings as if they were part of the original photo. 

This not only enhances the design experience but also strengthens Railing Designer’s ability to sell designs visually, helping customers better realize the value of their investments. 

Optics Theme Builder

Managing design tokens between Figma components and CSS code has long been a source of friction, leading to errors, manual copy-pasting, and wasted time. To address this, our team embarked on a project to create a unified, centralized "source of truth" for creating and updating our Optics themes, aiming to streamline the process of defining and managing variables. 

The goal was to build a data model for tokens based on the spec published by the Design Tokens Community Group that could seamlessly bridge design and development. Though the initial phase focused on defining the app’s structure and data model, challenging but critical, progress was made on UI for colors (including linked variables) and JSON exports to Figma. 

Looking ahead, we’re prioritizing completing the UI for all token types, resolving Figma import issues, adding CSS export functionality, and deploying the tool publicly. This effort isn’t just about fixing a workflow—it’s about creating a foundation for greater consistency, collaboration, and agility as we continue to refine our design system and codebase.

RoleModel Website Next 

Our team has been on a mission to elevate our design and collaboration workflows. After evaluating several alternatives to our current headless CMS, Butter, we think we’ve found a winner with Framer. Framer’s flexibility, robust collaboration tools, and seamless integration with design systems make it a game-changer for our goals. 

To start, we overhauled our existing website to align with our new brand identity, refining navigation, card styles, button consistency, and spacing. Parallel to this, we launched a Framer CMS experiment, rebuilding navigation and footer systems from the ground up while testing its component structure and CMS capabilities. 

The results? A powerful platform that blends Figma-like live editing with advanced collaboration features—like commenting, staging, and version history—making it a breeze for designers and non-designers alike. With Framer, we’ve unlocked faster iterations, deeper creative freedom, and a more intuitive workflow, especially as it evolves with features like custom page creation. The momentum from this CCC day experiment has us excited to push forward, ensuring our digital presence reflects the same excellence we bring to every project.

We are excited to continue to explore this opportunity and evolve the tools we use for us and for our partners.

This is our time to think bigger, experiment boldly, and push boundaries. From testing cutting-edge technologies to refining workflows that elevate our partnerships, CCC Days are where ideas take shape. It is also an opportunity for junior team members to lead, innovate, and grow. Whether we uncovered tangible improvements in our workflows or gained valuable insights to refine our approach, every effort contributed to our collective growth. We’re thrilled to see how these initiatives will continue to elevate our craft, empower our partners, and unlock new opportunities for their competitive advantage. 

As we mark ten years of LightningCAD, we’re pausing to reflect—not just on how far we’ve come, but also on how deeply our roots in Expertise Amplification, Iterative Value, and Process Scaling have shaped our journey. 

Process First, Software Second

When LightningCAD launched in 2015, our mission was to bring rich, guided design to the browser. Inspired by our long-held philosophy—process first, software second—we built a platform that enables users to design efficiently with the capability of highly trained engineers. It’s a dynamic framework that can be customized to codify constraints and convert your domain expertise into real-time visuals, cost estimates, and bill of materials—all while you design.

The LightningCAD framework came out of the recognition of a significant gap between the complexity of CAD and the limitations of designing on paper. This is why we created LightningCAD, a framework that combines the precision of CAD with the ease of hand-drawn design, all delivered over a web browser. This innovative approach allows both experts and end-users to effectively design, collaborate, and estimate with unprecedented simplicity and efficiency.

Crafted Through Partnership

​​Over the past decade, LightningCAD has been shaped through close collaboration with clients across various industries, including construction, manufacturing, marine, industrial, and defense. In every case, the goal has been the same: capture the unique expertise of a team and embed it into an intuitive, browser-based tool that delivers immediate value.

These solutions have streamlined design-to-quote workflows, reduced project timelines from days or weeks to minutes, and empowered teams to focus on high-value work instead of repetitive tasks. The result is more than just faster design—it’s smarter decision-making, stronger client relationships, and tools that grow with the business.

By focusing on the process first and the software second, LightningCAD ensures each implementation is a perfect fit for the people using it—and for the customers they serve. These custom solutions deliver real results, such as:

• Cutting design times from days to minutes while enabling command of premium market positioning.

• Revolutionized field workflows for landscape professionals.

• Brought military precision to engineering, reducing weeks of manual planning to minutes while meeting strict U.S. Air Force construction standards.

• Transformed piping system design, giving customers an easy, browser-based tool to lay out complete air systems in 2D and 3D—including drops, outlets, and fittings—while instantly generating accurate estimates and parts lists. 

Each of these stories isn’t about flashy technology—it’s about embedding expert process into tools that scale human capability. 

Iterative by Design

Ten years of LightningCAD has taught us that great software isn’t delivered all at once—it’s cultivated through steady, intentional improvement. That belief is the heartbeat of our creative process—one fueled by collaboration, craftsmanship, and the conviction that lasting value emerges from ongoing refinement. We approach every engagement as a long-term partnership, where the goal is not only to launch a powerful tool, but to continue refining it as needs evolve.

Our iterative process is about more than code releases—it’s about delivering iterative value. Each enhancement builds on the last, guided by real-world use and direct client feedback. That could mean reducing design time even further, adding new visualization features, or streamlining integrations with other systems. Every improvement is shaped by what matters most to the business at that moment.

This long-term, collaborative approach ensures that LightningCAD doesn’t just meet today’s requirements—it grows with our partners, continually unlocking new efficiency and opportunity. By making iteration a cornerstone of both our technology and our relationships, we help clients move faster, serve their customers better, and stay ahead in their industries.

Here’s to ten years of designing with intelligence—and to the next decade of building together.

Want to explore how LightningCAD can modernize your process? Let’s talk.

With many of our team members working remotely, CCC Days give us a valuable chance to connect face-to-face, collaborate across departments, and work with people we don’t usually interact with in person.

During this time, we shift our focus to experiments—testing out new ideas, exploring emerging technologies, and test-driving methods that could help us serve our clients more efficiently. It’s also a great opportunity for junior team members to step into leadership roles, run projects, and grow their skills in real time.  This quarter, we focused on AI experiments and LightningCAD efficiencies.

Here are a few of the experiments we explored during our latest CCC Days:

RoleModel Way of Developer AI

We conducted an experiment to refine the RoleModel Way of Developer AI, focusing on leveraging Large Language Models (LLMs) for code generation and editor integrations. Our goal was to compare the performance of the newest local models (running on an on-premise server) with cloud-based solutions like GitHub Copilot, specifically assessing their viability for tools such as autocomplete and agentic code development. Using a VS Code plugin called Continue, we tested local model integration but found significant performance gaps—local models were slower and lacked advanced features like agents or tool calling. This highlighted the challenge of balancing speed and functionality for rapid development workflows.

Shifting focus to cloud models, we explored GitHub Copilot’s capabilities, noting its robust infrastructure on Azure servers and potential IP protection for organizations. We also experimented with Copilot Instructions—custom markdown configurations to guide the model’s behavior, such as adopting a pirate persona or referencing project-specific files like READMEs, Gemfiles, and private packages. 

Our current recommendations include:

• Pilot GitHub Copilot via business subscriptions to assess usage and cost.

• Develop shared Copilot Instructions to align with team best practices and tool-specific context.

• Continue exploring local models as advancements may improve their viability.

This experiment underscores the importance of balancing performance, privacy, and customization when integrating AI into developer workflows, setting the stage for further innovation in code generation tools.

Curve-curve cutting and intersections

We tackled the next phase of the Lightning CAD curve implementation journey, aiming to resolve persistent issues with curved shape distortion and sharp edges during boolean operations. Despite our previous progress, cutting curved surfaces often resulted in jagged, distorted remnants, while even simple polygon cuts introduced unwanted artifacts. Our goal was to refine the curve-cutting process by delegating complex calculations to a third-party library, leveraging existing workflows for polygon booleans.

Our first experiment involved wrapping Paper.js in a lightweight LCAD abstraction, enabling precise, distortion-free cuts by translating LCAD paths into Paper.js-compatible structures. By day’s end, we achieved a clean “clipper” abstraction that preserved curve integrity. The second challenge: integrating this with Property Intel, whose path structure differs significantly—storing points instead of segments and dynamically updating them. By reconciling transient segments with Paper.js, we achieved impressive results, with smooth, crisp cuts for circles, polygons, and curves, eliminating prior distortions.

While early demos showed promise, complexities remain, such as reconciling control points and ensuring predictable editing. Future work includes refining LCAD’s path structure—currently based on segments, which limit flexibility—to better support Property Intel’s dynamic updates and curved hole creation. By extending Paper.js’s path abstraction, we aim to enable native curved holes and smoother editing modes. This progress marks a critical step toward a more intuitive, accurate curve UX in Lightning CAD. Stay tuned for further updates as we push the boundaries of 3D modeling precision!

Advanced 3D Model Imports

For our LightningCAD projects, we’ve identified a critical bottleneck in our 3D model import workflow. Partners often have existing 3D models of objects we are representing in the systems we are building but the import process was time-consuming. To address this, we focused on two goals: improving model quality by setting customer guidelines and streamlining the efficiency of common processing steps with tools like Blender scripts. 

Our solution? A STEP importer directly in Blender, built on Open CASCADE (the same technology used in some of our software systems). This tool parses boundary representations (B-rep) into triangles, allowing us to control the number of triangles along curves for optimal quality and performance. 

To further simplify the process, we created a customer guideline emphasizing preferred formats: STEP files for precision, Blender files for direct access, and OBJ for geometry preservation. We also automated repetitive tasks with a Blender plugin, reducing vertex counts significantly by simplifying geometry. We also added presets and scripts to automate common parts of the process, ensuring that as many details as possible were flattened and we only export the necessary information in the models. 

These improvements not only boost performance but also reduce post-import cleanup, making our Lightning CAD workflows faster and more reliable. Making it easier for us and our partners to support even more 3D models in our LightningCAD solutions. 

OpenWeb UI Setup and Integration

Our team explored the potential of Open Web UI, an open-source, self-hosted AI interface that can be customized to your workflow. We wanted to focus on customization for better integration with internal tools in a private AI environment. For example, we through an MCP server enabled our AI models to fetch time-off data from our internal tracking system, Almanac.

The experiment revealed Open Web UI’s strengths: it’s highly extensible, requires minimal setup, and supports integrations with cloud models (like ChatGPT) or open source models (via Ollama). A number of tools, such as web search, are easy to enable from a large set of community supported extensions. Using Model Context Protocol (MCP) showed promise for connecting LLMs to structured data, such as fetching time-off data from Almanac, our internal tracking system. However, limitations emerged, particularly around user authentication—MCP currently applies a single set of permissions to the entire server, lacking granular access controls. Although authorization is an area that MCP continues to evolve. 

As LLMs reshape workflows, platforms like Open Web UI offer a flexible, self-hosted path to unlock value, whether for internal efficiency or client-facing solutions. The key is to balance experimentation with strategic integration, ensuring tools align with real-world needs.

Everyone across the company was hard at work for this round of CCC Days, diving into a wide range of experiments. Some efforts led to tangible improvements in how we work, while others offered valuable lessons we can build on in future rounds. Either way, every experiment moved us forward.

RoleModelGPT

As we continue to evaluate our use of AI and Large Language Models (LLMs) in our daily work, we set up this experiment to look at the process for deploying open-source models in our own environment. This would enable more advanced use cases, such as writing proposals or analyzing business documents with the context of other private RoleModel information. This would help to eliminate biases common to public LLMs, protect our intellectual property, and ensure we are not accidentally exposing customer information to the world. This could also lead to a product offering for our partners. While we didn’t get far on our stated goal, we learned a lot more about the process and uncovered some additional experiments to explore around leveraging ways we could smaller-focused LLMs in the software systems we built for our partners, such as context-aware search.

Augmented Reality (AR) Construction Measuring

The construction and engineering industries face persistent challenges in translating real-world structures into accurate digital models, a process that traditionally demands significant expertise and time-intensive manual work. Accurate measurements of existing structures are essential to understanding the real-world context of where something will be installed. This experiment explored an innovation to our LightningCAD® framework through an Augmented Reality (AR) measuring and design mode. Rather than just using AR to orient a design for visualization, the user would design the system in AR mode, marking where features would be placed in the real world. This includes extracting 3D details from the environment and placing a railing system from our Railing Designer platform. Our experiment gave us some positive data and more information about what processing would be needed to make this production ready.

LightningCAD Isometric Drawings 

Isometric drawing is a rendering technique drawn from an angle that renders X, Y, and Z axes equally. This is especially useful in construction to visualize how components fit together. In this experiment, we explored some libraries and algorithms to incorporate isometric drawings into an existing project. Our results were promising, with a good base of functionality to continue working on this for customers that need these kinds of rendering for workshop drawings or installation guides. Particularly need to finalize the integration with our PDF library to support exportable drawings.

Hotwire Native

Over the last several years, we’ve embraced the Hotwire style of development within our Rails applications. This has also included several hybrid native applications using the Turbo iOS and Turbo Android frameworks as a thin native wrapper around our mostly web application for a great mobile experience with minimal development effort. With the recent release of Hotwire Native to replace these libraries, we wanted to experiment with upgrading our existing applications and implementing the customizations we’ve seen as common needs. We made good progress with one of our cross-platform applications and have now released these updates to production; and are ready to take on the next project using this approach.

System Monitoring Signal vs Noise

Our team relies heavily on Slack as our primary communication channel, utilizing various channels per project to ensure all critical messages are captured in one place. Over time, the number of messages that are noise from our error reporting or logging systems has grown, and the goal of this effort was to find ways to reduce that noise so the signal (important messages) doesn’t get lost or ignored. We did this by implementing filtering rules and a Slack bot to better summarize information about errors at regular intervals.

It was a great CCC Days, and we are excited to see how these experiments help us further our craft and serve our partners by providing new ways to grow their competitive advantage. 

Our theme for the year was Impact Mindset, inspired by the concepts and practices of Liz Wiseman’s book Impact Players. We explored how to adopt this mindset individually through our attitudes and habits, fostering deeper trust and credibility as a team committed to focusing on the W.I.N. (What’s Important Now) for our partners.

In support of our theme, we introduced impact awards, which went to employees who demonstrated the attributes of being an impact player as nominated by their peers and recognized by the leadership team. We celebrated these awards at our annual company retreat.

Part of our supporting strategy this year was better defining The RoleModel Way and our Core Values. The RoleModel Way is a collection of principles and practices that define RoleModel’s culture. Some of our focuses include The RoleModel Way of Mentorship, Design, Testing, Project Management, and Selecting Technology. We also refined how we talk about our Core Values of Character, Collaboration, and Craftsmanship this year.

We also distilled our learning from years of custom software projects on how we encourage people to think about return on investment (ROI).

This year, we moved into a new Headquarters space in Apex, NC, and updated our logo and brand colors in conjunction with this new era of RoleModel. This new logo helps visualize our priorities by showing RoleModel (culture and values) as primary and software (what we produce) as secondary.

We hired six new employees this year, three of whom are graduates of the 2024 Craftsmanship Academy, and showcased their journey with a docuseries this summer. We are also celebrating the knighting of two new Craftsmen, Jeremy and Justin!

This year, we also launched our new design system, Optics. We created Optics as a design system to provide a shared collection of components and solutions for common design challenges. It’s customizable for unique project needs, integrates seamlessly with our development tools, and ensures consistency across projects. Optics offers a strong design foundation that evolves through collaboration between developers and designers. By standardizing design and implementation, it streamlines our workflow, enables designers to use best practices, and ensures excellent accessibility in all projects.

Now, at the year's close, we look forward to 2025 and our theme for the year: Disciplined Professionalism. As an attribute of Craftsmanship, we will be looking to apply disciplined professionalism throughout the organization personally (in our attitudes and habits), as a team (building trust and credibility), and externally (W.I.N. as a team). 

We are so thankful to everyone that made 2024 a great year! See you in 2025!

This CCC Days was especially exciting because it was our first in our new headquarters space. We loved showing our remote team members our new office and inviting our families to an open house to tour the space and fellowship together. We are blessed to have this new space to continue the work we do with our partners as we continue to grow for years to come.

Keeping with our 2024 theme Impact Mindset and the RoleModel Way of Selecting Technology, our experiments focused on exploring new technologies and approaches that would help us work more effectively as a team and deliver greater business value to our clients. We’d like to highlight some of our experiments. 

RoleModel Website and Optics

With the updating of our new brand which we announced over CCC Days, we wanted to update the RoleModel website to incorporate it. We also wanted to use this as an opportunity to rebuild our website on top of our Optics design system. 

The major focus for this experiment was refining how we pull Optics into an existing project and refining our use of our headless CMS to provide more flexibility in how we present content. Having existing design direction ahead of time we were able to make great progress by repurposing our existing content and officially launching the new website a couple of weeks later. In the process, we learned a lot about how we can apply this technology stack to clients' marketing website needs.

Tailored Select

In most applications that we build, there is a need for a drop-down control that can be searchable. This will often be used for long lists or selecting multiple items like tags. HTML has the built-in <select> tag, but it is pretty limited in functionality. So that means that we often reach for a 3rd Party library to add this functionality. Over the last few years we’ve been using Tom Select, but it isn’t as flexible as we would like for how we want to customize it. We also wanted a framework-agnostic autocomplete widget with native-feeling keyboard navigation that would be easy to test in our standard tooling.

So, we set out to build our own open-source component. We’ve been leveraging web components in our projects, and this seems like the technology choice for a flexible and accessible control that we wanted to build. Our initial goals focused on building the multi-select behavior and making it easy to style.

It doesn’t yet match the broad set of features of other select libraries, but we’ve released it as an NPM package and will be continuing to improve it over time. Pull Requests are welcome!

Point Cloud data in Railing Designer

A point cloud is a set of data points in a 3D space that corresponds to surfaces in the real world. They are created by taking a LiDAR (light detection and ranging) device around to different points of the building and taking scans and the software stitches it together to create a consistent space. This experiment explored the possibility of using point clouds in our LightningCAD framework, specifically looking at placing railings on a surface created from point cloud data. 

There are a number of challenges in working with point clouds due to the sheer number of points and imperfections from scans. While we didn’t get to a final shippable solution, we were able to determine a viable path forward of converting point clouds into usable data that we could pull into our framework. 

These represent just a few of the experiments we worked on during CCC Days. We are always excited to have our team gathered together, and we especially loved being able to show off our new space and announce our new brand in person. We look forward to the future of RoleModel Software, serving our partners under our new brand in our new headquarters space. 

Craftsmanship

Craftsmanship is pursuing excellence and is brought about by character combined with collaboration to drive positive results. It isn’t synonymous with intricate or complex. Craftsmanship is more than just how we build software and its technical details.

Craftsmanship at RoleModel is focused on sustainable delivery with our service-oriented approach through disciplined professionalism, not obsessing over details. 

Sustainable Delivery

Sustainable delivery is finding simple solutions to complex problems and recognizing the need for pragmatic and sustainable solutions over the long term. It is about delivering value now, but it's not being satisfied with the value that we produced right now—it's improving that over time. 

Delivering value is our focus, and that’s why we say “craftsman ship.” They ship software in incremental solutions that deliver value over the long term. 

Service Oriented

Craftsmanship is service oriented. This means working with passion rather than on your personal passion, anticipating challenges, and being people focused. 

Internally, this is through mentorship, where we come alongside those around us and help each other grow. With our partners, we want to come alongside them and serve them to help them accomplish their vision. 

Disciplined Professionalism

As Jacko Willink says, “discipline equals freedom”, and disciplined professionalism is a mark of Craftsmanship. This means being self-disciplined and self-motivated, always learning new things, and consistently paying attention to the right details. 

Random acts of excellence are not craftsmanship; rather, we seek to consistently apply the RoleModel Way. Consistency, paired with the willingness to take on new challenges, produces powerful results. 

Craftsmanship in Practice

Craftsmanship at RoleModel is exemplified by leading by example. This means consistently producing excellent results through two sets of eyes to ensure we meet our high-quality standards. While also taking time to sharpen the saw and continually improve the way that we work.  

Since this is the last piece of our series on our core values, let’s recap. 

• Character is built through dependable trust, demonstrated in humble confidence while embracing servant leadership. 

• Collaboration is results oriented, leveraging our collective contribution by leaning in. 

• Craftsmanship focuses on sustainable delivery with a service oriented approach through disciplined professionalism. 

Taken together, our core values of Character, Collaboration, and Craftsmanship define our culture at RoleModel. 

Collaboration

Collaboration builds off of good character. High-performance teams need deep trust in each other so they can count on each team member to contribute their unique skills and abilities in every project in order to achieve excellent results. It’s not just working alongside others but creating an environment where everyone contributes their best work.

Collaboration is equal parts art and science; it's asking great questions to draw out the facts and figures that we need to do the work we're doing. But it's also actively listening to what other people are saying so you can hear what they're not saying. Whether it's communicating with our partners or coworkers, everything we do is about collaboration. 

Results Oriented

Collaboration is results oriented; it requires beginning with the end in mind and having a shared ownership of the outcome. I love the African proverb, “If you want to go fast, go alone, but if you wanna go far, go together.” 

Being focused on results doesn't mean running over people to get the results. We foster an environment where everybody can grow and learn. Team members are conscientious to critique the work rather than the person, so that we can consistently lift each other.

Collective Contribution

Collective contribution requires rich and effective communication. Each party is fully engaged, asking good questions and actively listening. The communication is balanced, not one-sided or passive, from any one party. 

We want to hold each other to a higher standard and encourage each other so that we can grow together and ultimately produce more as a group than we could as individuals.

Leaning In

Leaning in is a buffalo culture concept from our friends at C12. On the prairies of the American West, cattle disperse in the midst of a storm. Conversely, buffalo lean in and charge into the storm together, coming out the other side stronger because of their herd mentality. 

Collaboration is an active practice; we want to have our heads up and our eyes open to be mindful of circumstances. We want to step up when the opportunity arises and step back when someone else should be there to lead. 

Collaboration in Practice

Collaboration at RoleModel involves cross-functional teams where different team members have specialties they bring to bear for the benefit of the collective team. That means each team member needs to think about how others can easily collaborate with me by being low maintenance. Our collaboration is not just internally focused but is critical to how we engage with and deliver successful software projects to our partners. 

Above all, collaboration is results oriented, leveraging our collective contribution by everyone leaning in.

Our core values are foundational to the RoleModel Way and the culture we’ve built at RoleModel Software. Each value stands on its own but combination casts a unique vision for where we want to go as a flourishing organization that develops leaders, launches careers, and serves with humility so that others would see God glorified in our work. 

Core values are a constant reminder of how we should be behaving, how we should be making decisions, and how we should be working with each other. They are not surface level; they need to be ingrained deeply and put into practice daily. It is a focusing mechanism for the organization and ultimately unifies us to accomplish our long-term goals. 

“[core values] are a small set of vital and timeless guiding principles for your company.” - Gino Wickman

Words are powerful, and each of these values is a single word that can have a variety of meanings depending on your background. We want to share our definition of what these mean to the RoleModel culture, what they are not, and how you'll see them play out in practice. They are not aspirational but are values that we are continually working to grow in.

Character

Character is the first core value we’ll look at; it’s the foundation of our core values and comes first for a reason. It requires a good standard. While we're not perfect, we seek to emulate the perfect character of Jesus Christ. Character is the foundation of everything that we do at RoleModel. It affects everything from the customers we partner with to the people we hire to how we deliver our work. Character is not just the absence of moral failure; it is built through dependable trust, demonstrated through humble confidence, while embracing servant leadership. 

Dependable Trust

A track record of character is built over a lifetime and can be lost in moments. Dependable trust is that track record of knowing that you are a person of your word and someone people can count on to do something even when no one is watching. 

As we work together, we collaborate to get things done. But we're doing it in a very high-trust environment. So it's based on being able to depend on what we're doing and who we're doing it with. 

Humble Confidence

Character is not prideful but requires pride in your work. An optimistic outlook that is humble confidence. We also want to be confident in our work—to have pride in it and to do the kind of work we are excited to put our name onto. 

Humble confidence is having strong opinions but holding them loosely; that lets us be optimistic when we are trying to solve problems because we know we can do it. That's not based on the foundation of perfection but on a foundation of being confident in our abilities to deliver value. 

Servant Leadership

At RoleModel, serving drives us and it is core to our mission of serving colleagues and our business partners. Servant leadership is taking accountability, sharing the credit, and embracing continuous improvement. 

This means strong leaders who invest in those around them and lead by example in taking on hard challenges and accepting accountability. We also seek opportunities to acknowledge the contribution of the team rather than individual accomplishments. 

Character in Practice

In practice, Character at RoleModel means always speaking the truth in love, even when that's a hard conversation because we're focused on investing in others, whether our team or the partners we serve. 

Character starts with you. We’ll never achieve perfection, but it's built over time through dependable trust, demonstrated through humble confidence while embracing servant leadership.

But why update it now? After all, “if it ain’t broke, don’t fix it,” right? We wanted to celebrate the new era of RoleModel. The last several years have represented sustainable growth for RoleModel, and we just moved into our new headquarters space, making this the perfect time for this change. 

With our focus on standardizing the RoleModel Way in 2024, we’ve been refining our language around how we approach things, including our Core Values of Character, Collaboration, and Craftsmanship. This new logo helps visualize that by showing RoleModel (culture and values) as primary and software (what we produce) as secondary. 

The “t” is also more integrated into the design. It represents the cross of Jesus Christ, whose perfect character we seek to emulate as the ultimate role model. It also represents a sword, which we think of as a picture of the lasting craftsmanship that we aim to produce. 

We are excited to offer the same excellent service to our partners under our new logo for many years to come. 

Keeping with our 2024 theme Impact Mindset and the RoleModel Way of Selecting Technology, our experiments focused on exploring new technologies and approaches that would help us work more effectively as a team and deliver greater business value to our clients. We’d like to highlight some of our experiments with our LightningCAD framework and our new project management tool, Linear. 

LCAD Experiments

LightningCAD is our framework for building our Design Price Quote (DPQ) solutions (Railing Designer, Dock Designer, Flow Designer, Building Designer) and other custom design solutions for systemized products with geometric variability. 

Our first experiment continued the work we have been doing to create paths and manipulate curves (specifically Bezier curves), which will open up new features and higher performance. Until recently, almost everything in LightningCAD was represented as polygons/points, making it challenging to represent curves without many points, which slows down performance. This project improved our support of curves in path and direct editing. 

Another LightningCAD experiment examined how we build the UI for our design tools. We’ve used many frameworks over the years, but we’ve been looking for a simple standard approach that is easy to customize and fits well with the technology stacks we use in our projects. The experiment focused on extending the web components experimentation and patterns we’ve been working on in another project and applying them to the core framework. This new approach simplifies the code, gives us new ways to build our applications, and will help us be more flexible as we build additional features into LightningCAD.

Our last LightningCAD experiment was a proof of concept for Deck Designer. In recent conversations with possible partners for Railing Designer, we realized there is a market for Deck Designer software since many companies that build railings also build decks. This experiment explored the channel for a deck design tool and the essential features, including delivering a proof of concept application to share with potential customers.

Linear Experiments

To further standardize our approach, we use Linear as our project management software tool of choice. Linear has tools to help us better apply the RoleModel Way of Project Management and communicate effectively with our customers about projects. 

In most cases, our customers need to know what high-level features are working on. For this experiment, we leveraged the Linear API to create a customer view of an iteration, project, and roadmap. We want the new system to be flexible, with a simplified view for our customers to interact with as we do standups or planning meetings. Something that makes it as easy as possible to get involved with a high-level view to see where the project is at and also be able to submit bugs, issues, and discussion items.

As RoleModel has grown, we’ve focused on having specific metrics that are leading indicators of the organization's health. For our project management practices, we’ve organized those into a collection of metrics called the PM scorecard. With Linear’s GraphQL API, we built some quantitative measures for throughput and on-time delivery that we’ve previously had to measure qualitatively. This allows us to collect data in the course of doing our work that brings insight to the health project and can help us detect problems sooner.

It was great to close out our time in our office with everyone in person. We look forward to sharing updates from our next CCC Days in our new headquarters!

We want to examine three key ideas: an investment mindset, business value drivers, and iterative value. Taken together, these help you evaluate whether custom software is the right investment for your business. 

Investment Mindset

Custom software should be approached from an investment mindset. You shouldn’t think about custom software as a one-time fee that you are paying to unlock a piece of software. It is really an investment in a long-term, sustainable asset for your business. You are not just thinking about the upfront cost but also the vision of where you want to take your business. What’s the long-term opportunity that custom software provides? Off-the-shelf software is something you have to integrate into your business, whereas custom software is something that you can build to fit your business and your competitive advantage. What’s the way you work? What’s unique to your business? That can become the hub—the integration point that accelerates your growth and ability to scale beyond where you are at right now. 

Business Value Drivers

Having the right mindset doesn’t mean that you have to hope and pray that custom software is going to bring value to your business. Hope is not a strategy. But there are unique value drivers within your business that you can focus on, analyze, and determine what return you would get on solving those within your business. 

For example, on the cost reduction side, you can consider the monetary value of:

• having fewer people involved with a process—that can dramatically decrease labor costs 

• increasing estimation accuracy, which can decrease material wastage

On the revenue-enhancing side, you want to think about: 

• Getting to market faster

• Improving customer experience and retention

• Engaging potential customers more effectively (including selling productivity) 

If you focus on factors like that, you can pretty quickly get to a quantified business case for the software that you are considering. 

Intangible Value

In addition to the directly quantifiable value that custom software can bring to your business, it’s also important to consider intangibles such as:  

• brand professionalism

• company culture 

• the overall happiness and well-being of your employees

• software as an additional asset that can impact a company's evaluation

Intangibles like these could be an additional point of value for your custom software project. 

You know your business and can identify the pieces of value that fit with your vision. That analysis and quantification shape the investment that you make with custom software, yielding you the highest return. 

Iterative Value

Custom software opens a lot of possibilities. But how do you narrow the focus to what’s going to be most valuable for your business? Where can you get the biggest return for the smallest investment? Start small with a key workflow or part of the business that would bring immediate value. And then use the returns from that investment to further invest in the long-term vision for what you have with your software. This is Iterative Value. 

You want to start small and release software frequently to reduce the risk of your investment. At the same time, you want to get to value as quickly as possible because money today is worth more than money tomorrow. 

Iterative value de-risks your investment, meaning that you don’t have to go 0-100 before you get value. Instead, you can start small. This might look like a skateboard that addresses your basic needs and functionality and can evolve into a bicycle and, ultimately, the car that you need as a business. This means that every step of the way, you are getting tangible value. 

By incrementally building your software asset, you address your needs now but set a path for achieving your long-term goals. This scalable agility allows you to grow your business beyond simple linear growth and adapt to changing business needs and market conditions. 

When considering your return on investment for software, you can look at a product, and ultimately, that will only ever be what you purchase. Versus custom software that unlocks the potential of a future. You start small and can grow your investment over time and you control your solution. This is an unbounded opportunity that custom software unlocks. 

Calculating ROI

When considering ROI, it’s important to have:

• an investment mindset focused not just on the cost but on the opportunities 

• key business value drivers that identify the impact that this software would have 

• an iterative value approach where you start small and build toward your long-term vision

You have the tools to evaluate the return on investment in custom software for your business. At RoleModel, we want to be a resource; we’d love to discuss these ideas with you further or help you determine whether custom software investment makes sense for your business.

Intentionally Different

RoleModel is intentionally different in the way that we select technology for our projects. Our strategy is focused on the partners that we serve and the common challenges and business problems that they're looking to solve. This means we don't simply select technologies that are new or trending in the market or the shiny things that we, as developers, would like to experiment with. We primarily serve small and medium-sized businesses. These organizations need to be agile, continually evolving their competitive advantage to stand out from their competition. The tools and technologies that we select need to enable us to serve them well by evolving their technology as their business evolves and grows. 

Sustainable Partnership

Practicing the RoleModel Way of Selecting Technology means that we’re not simply delivering an initial project and then moving on. We're actively building long-term partnerships, getting to value fast, and sustaining it over the long term. In order to do this effectively, we focus on building small high-performance teams, leveraging and focusing on developer productivity as that fundamentally impacts many different areas of the project, from how fast we can ship features to the long-term sustainability of the solutions that we’re building. This, combined with the RoleModel Way of project management, design, and even testing, informs the technology decisions that we make so that we can build a solid foundation for our team to work in and handle the transitions that naturally happen over the course of a project within our team. Ultimately, we're not focused on building budget software solutions but rather maximizing the investment for long-term value. 

Leading Edge

I love the analogy of the technology adoption curve from Crossing the Chasm by Geoffrey Moore. It's a bell curve with innovators on one end and laggards on the other. But you'll notice a gap between early adopters and the early majority; this is the point in the technology lifecycle where something has to prove itself. Can it move from the land of the tinkerers to the world of the pragmatists? At RoleModel, we want to leverage emerging technologies but not be dependent upon them. We are students of the chasm, focusing on technologies that are looking to cross it. We want to experiment with those tools that make sense for a given project without jeopardizing the ultimate success trying to have. 

So, how do we apply this practically? We've got an experiments culture at RoleModel, which means we're always looking for potential opportunities where a new technology or refinement of our approach will make a significant impact on a partner’s project. Additionally, we set aside time each quarter for some internal experimentation, looking to prove technologies that are on the cusp of crossing the chasm that we can implement in our future projects. For your project, you experience the confidence of working with a team that understands the proven technologies they're using to build a solid foundation, with the added benefit of the RoleModel team continually evaluating technology trends and tools that could be applied to your project without a complete rewrite. 

Technology is always changing, and that’s part of what excites us as developers—seeing the new opportunities that that brings. But it has been met with discipline; the RoleModel Way of Selecting Technology is how we approach that—by being intentionally different, focused on building sustainable partnerships, while still being on the leading edge through our experiments culture.

Improving Common Feature Requests

As we partner with our clients, a few areas that we’ve recently gone deeper in functionality are notifications and custom formula editors.

One of our focuses is expertise amplification, and one way we do that in software is by creating an excellent user experience (UX) for our partners. With better UX, anyone in their company can benefit from the expertise of the experts that is encoded into their software assets. This concept led to our first project with custom formula editors. 

With many of the manufacturing partners that we work with, our software goes a long way to amplify their expertise, but not all of that can be baked into the software statically. They need a way to override or change calculations over time. Often with projects like this, we are migrating from Excel to custom software, so the idea of formulas is familiar. With this experiment, we wanted to improve the usability of creating those formulas with things like autocomplete and errors. In addition, creating a better baseline for us to start with on new projects. 

Leveraging the monaco-editor, we created a custom theme and language for editing formulas. This added the creature comforts and error checking, making complex formulas much easier to work with.

Another one of our focuses is iterative value, which is getting value to our partners by getting them working software as quickly as possible and then increasing its functionality iteratively throughout the course of the project. Over our last few projects, we have been doing more with notifications and wanted to experiment with the best approach for multi-channel notifications.

Historically we’ve built notifications for for email, SMS, in-app, or mobile push notifications, but those were always a bit separate approaches. We wanted to experiment with unifying our approach across mediums. We chose to use the noticed gem, which is the base for a new framework feature coming in Rails 8. By having a unified framework, we can more easily slot in features like batching notifications or delaying notifications to see if they get read in the system. These experiments will support more functionality than the patterns we had previously developed for ourselves. 

New Technology

Our LightningCAD Framework is a powerful engine for creating detailed 3D views of user-created designs. Viewing in a browser is great, but we want to continue to push the technology as Augmented Reality (AR) and Virtual Reality (VR) become more common. We previously experimented with AR/VR, but the focus of this experiment was to ship a production-ready demo for our Design Price Quote (DPQ) platform.

In our most common verticals, Rails Designer and Dock Designer, we use this technology in slightly different ways. AR makes the most sense for Railing Designer because when you are laying out railings, you usually have an existing structure, so AR lets you see your railings in your space. Our goal was to create an AR demo that easily aligns with the current structure. For Docks, there isn’t an existing structure as you are building on the “open water,” so VR is a better fit to explore the blank slate.

These experiments allow us to work with team members we don’t get to work with regularly and foster collaboration as we work to develop a new process or solve a problem. Our experiments let us try new procedures or tools, make us more efficient, help us serve our customers better, and ultimately, allow us to grow in craftsmanship. 

The reason is quite simple:

• to increase confidence and,

• to provide documentation.

Losing sight of those reasons gets us lost in the details. Tests should provide clear documentation and to provide confidence that the system works as intended. The reality is that in the pressure and desire to grow the features of our software, we can lose sight of this fundamental purpose, even if we've bought into these primary testing objectives. The test we wrote on Day 3 that gave us confidence and documented our intent may be slowing us down or confusing us on Day 33 or 133.

Automated testing is code written alongside business logic that executes scenarios and validates that functionality is correct. It’s not a replacement for manual testing but a way to constantly ensure the evolving software is healthy and high-quality. 

The RoleModel Way of Testing is how we approach software testing in our projects. We’ve developed these principles and techniques over hundreds of successful projects that have resulted in sustainable software assets. Writing tests is fundamental to our focus of Iterative Value. Without it, we don’t have a solid foundation to build on, and we can’t work iteratively with confidence.

Increase Confidence

Why is confidence so important when you’re developing software? When you don’t have confidence in your software, you become afraid of it. We’ve seen this many times as consultants when we come into software projects without tests, and the software has deteriorated over the years. It gets to where it is very hard to build new features. Every time you do something, it breaks, and the cycle repeats. You fight against that deterioration in software by continually improving the software, refactoring it, and making it better. Tests enable you to make a change or improvement, and then you can run your test suite and know if you broke anything.

Having confidence in your test suite means ensuring that your tests and the overall test suite are:

• correct, and actually do what they claim

• consistent, no intermittent or occasional failures that erode your confidence, and

• provide a tight feedback loop significantly faster than manually testing each change you make to the system.

Though Correct and Consistent should be obvious, they often get so much focus that the Tight Feedback Loop part gets lost. A bug is found, so a test is added. An intermittent test failure is found, so we add some protection around it (e.g. sleep(1)). Before we know it, the test suite goes from seconds to minutes and perhaps from minutes to hours.

Feedback Loop

At RoleModel, a large part of confidence comes from having feedback along the way. This applies to many areas, but especially to testing. The faster our feedback, the bolder our changes can be. A fast feedback loop lets you know if you broke something fundamental. And you can receive this valuable feedback without having to break your stream of consciousness.

Receiving quick feedback from tests means a developer should be able to:

• make a small change (such as modifying a class or method) and get feedback in seconds

• refactor a sub-system and get feedback in less than a minute

• run the whole suite in a few minutes

The important factor is more than how fast the whole test suite takes to run. For a large system, it might be understandable to wait 15 minutes for a full run. However, if you need that full run for 80% confidence in your change, then something needs to be fixed with the testing approach. A test suite that takes too long to run will decrease confidence because the whole suite rarely runs. You might work for an hour or two without running the full range of tests because you didn’t want to break your rhythm of development. Then, when you finally do run the suite, it’s harder to figure out which of the many things you did during that hour broke something.

When working with a growing and evolving system, the build-up of slow, full-system tests can become a problem gradually over a long time. It is often difficult to determine a single point when the tests became less useful, so developers should periodically take a step back to evaluate whether the test suite is still useful and instill the confidence it should be providing.

Provide Documentation

Automated tests also provide documentation. Code is read 10x more often than it is written. And well-written tests, like well-written code, give an insight into the test's intent. 

We write tests to document the system, bridging the gap between the business stakeholders and the technical team by providing a common language. The language used to describe the tests and the system's expectations are in the terms of the business, and the tests execute that documentation to prove that the system fulfills the necessary conditions. 

Tests Should Have a Consistent Style

When a large team of developers and stakeholders work together to reach a shared understanding of the system’s behavior, ending up with a wide variety of descriptive styles can be hard to avoid. Major differences should be avoided, though, as reading the documentation of many styles is similar to reading a book with numerous authors — it results in a very jarring experience for readers.

To address this, we suggest auditing the readability of the tests at significant project milestones, such as when adding new members to the team or approaching a major release. This process will not only help get new people up to speed on system functionality but can also help ensure that documentation and desired functionality are maintained for future team members.

Depending on the type of test being written, some frameworks specifically call out sections as Given, When, or Then. Other frameworks do not make a specific differentiation between these sections, but the principles remain the same. Good tests should have a general structure that is easy to follow: 

• Given sections provide background detail and setup that is required before the test begins; 

• When sections give an action that is going to be tested and 

• Then, it provides assertions or expectations for the results of the actions provided. 

Good test structure should make it fairly obvious which lines of test code belong to each section. For example, in general, Then often includes keywords such as “assert” or “expect.” When it becomes hard to distinguish each section from one another, or a significant amount of bouncing between Then and When exists, tests become significantly harder to maintain, and their purpose is often confusing. The context for any given test scenario should appear to be a concise setup of only a few lines, and the structure of actions and expectations should be clear to future readers and maintainers.

Tests Should be Expressive

Expressive tests document the system by communicating the purpose of a piece of code, not just describing its functionality. For example, on a BlogPost object, you might have a test that checks for a published_at timestamp. An expressive test would check for this functionality and describe its purpose: “BlogPosts have a timestamp so that readers can discern how up-to-date the information is.” Or, to give a less trivial but also hypothetical example: “Patient data is encrypted in order to comply with HIPAA regulations.”

Expressive tests communicate purpose, not just functionality. They do it at the same level of abstraction as the unit under test. For example, a high-level UI integration test might be expressed as, “Logging in takes a user to the profile page.” If you're testing a more granular unit of the system, the test should still be expressive and purpose-driven: “ProfilePhotos only accept JPEGs and PNGs to simplify browser compatibility.”

It's easier to keep purpose in mind and write expressive tests if you identify the high-level acceptance criteria and tests first and then work your way down to the smallest unit under test. A team that writes consistently expressive tests and aligns with these principles communicates better — not only with each other but also with any developer who follows them in the codebase for the lifetime of the software product. 

Working Iteratively with Confidence

Our suite of automated tests allows us to work iteratively with confidence. This is because we have a safety net that ensures that we can confidently delete or add code because we know that we aren’t going to break something that already exists there. This means that knowledge from the developer and the team working on the project is initially encoded into the software asset so that they can focus on the part of the problem they are solving and make it easier to catch additional developers up on the project later. 

It’s important to recognize that tests are code as well, and developers need to examine them to understand how they work. Write your tests with the same care as you do the application's actual features. If you do, you and any future developers who work on this project will thank you.

Like the code we write, we want our tests to embody intention-revealing names in the language of the business they are testing. We should look for opportunities to refactor and reuse tests as much as possible and then ensure that they are always run and correct by having continuous integration in code reviews that look at the tests as much as they do in the production code. 

The Feedback Loop Starts with TDD

We write our tests first because we want to drive functionality from a failing test and get the benefits of TDD’s red-green-refactor cycle. 

When writing our tests, we start from the outside and work our way in, taking the perspective of the software's end-user and working our way into the system's core business logic. 

We follow three steps, and we do them iteratively:

1. Write new expectations the system does not fulfill. We create a test, and we watch it fail

2. Write code that makes the system meet that expectation, which causes the test to pass

3. Step back and consider the system as a whole. We look at our tradeoffs so far and ask ourselves if they are correctly tuned. Is this the best system that could meet the expectations that have now been written for it? 

We can adjust the code if needed. Because we have the tests in place, we can adjust that code with confidence, and we don’t have to worry about regressing past behavior or failing to meet previously met expectations.

Michelangelo is quoted as saying that inside a block of marble is a sculpture waiting to be uncovered. The sculptor's job is to remove the excess and reveal what was already inside it. Similarly, for the skilled TDD practitioner, the software system is to be revealed by creating these tests and developing the system. Ultimately, using TDD lets us confidently create the best systems possible for customers that meet their needs today and tomorrow. 

The RoleModel Way of Testing Works

Software is full of theory. Theory can be helpful, but what counts for us is delivering value for customers. Testing the way we do lets that happen:

1. We can change systems confidently and quickly, knowing that our automated test safety net will flag any regressions

2. Our code is clear, even to people who haven’t touched it before (or in a while) because the tests show how to use it and interpret it

3. Feedback loops for us and for customers are fast, so we can respond to changes well, proactively fix any errors, and accommodate future growth effectively

The RoleModel Way of Testing helps us better manage the sustainable software assets we build with our customers and ensure we can deliver iterative value. We do this by ensuring our tests increase confidence and provide documentation.

Focused on Business Value

Focusing on business value means we want to understand our partner’s business and its value drivers. We look at process first and software second to optimize your business's processes. This will allow us to deliver a software solution that best fits their needs rather than fitting their business to the software. 

We use short feedback loops to get constant feedback from our partners to deliver the best product possible as quickly as possible. Nearly every software company will say that they are agile; our mindset around project management is that we want to be agile, in an agile way, adapting our approach as we need.

Every project has tradeoffs and decisions that need to be made, and there are limits of scope, budget, and time. Within any one of the features, we’ve got to pick which of those is most important. We are focused on the project's measurable business goals, ensuring each of those decisions delivers value to our partners. This allows us to brainstorm solutions and prioritize together to make those tradeoff decisions transparently. 

Start and Steer

The best way to finish a software development project is to get started. That doesn’t have to be scary. We are going to start and steer together in a completely transparent process where our partners know what we are doing and why we are doing it. We focus our process on getting working software into our partner's hands early and often through demos, iteration meetings, and daily standups. But when we start a project, we don’t start it; go away, and work behind the scenes. We partner with our customers; they are part of our team. We work together to make sure that we are steering the project in the right direction through the entire life of the project. And at the end of the day, we end up with a working system that meets your business needs and that we collaborated to create; we didn’t just make it up on our own.

Tight Feedback Loops

Tight feedback loops are foundational in how we manage projects at RoleModel. We’ve standardized our processes to ensure that we have the right meetings to get feedback from our partners and stay on course. These meetings are designed to get feedback quickly rather than waiting a long time to discover that we’ve been moving in the wrong direction. 

We leverage targeted planning cycles so that we are focused on what’s important now for the project and for serving the business. We step back with retrospectives that allow us to focus on what’s working well and what can be improved in our collaboration. The point of all of that is to make sure we are validating that we are creating the software our partners need at every step. So, we want your business needs for value to drive what that software is, and we don’t want to use our imagination to figure out stuff that we think might be right. We look at the working software we’ve developed together, knowing it’s right because we developed it together. 

This proven approach is important because it focuses on mitigating the risks involved in a custom software project, ensures that we have buy-in from our partners/users along the way, and ultimately ensures that the value we deliver is visible, given that software is often an invisible product. 

Proven Approach

RoleModel’s approach to project management is something we’ve honed over decades. The primary focus is driving toward a customer’s Minimum Viable Product (MVP). We break that down into achievable pieces that we manage with them, and even beyond the MVP, the roadmap we’ve created together casts vision beyond the initial release. But the point is, we are managing this together with the customer, collaboratively, to produce software that meets their business needs for value.  

Project management is mainly about building trust and mitigating risk. Our project management approach is designed with one thing in mind—delivering valuable software to the partner. Everything we do as part of that approach is designed to mitigate the risk that comes with custom software projects. By using the proper tools and standardized methods we can deliver excellent projects with consistency.

The RoleModel Way of Project Management is how we guide and direct the uncertainties of a custom software project to ensure consistent delivery. We do this by focusing on business value, starting and steering, and continually adapting through tight feedback loops.

Optics was born to support these efforts and to continue the growth of our User Interface (UI) and User Experience (UX) design and delivery practice at RoleModel. We have built this design system, learning from real project work and with deep collaboration between our designers and developers within our delivery team. This journey included many careful and thoughtful revisions to get us to where we are today, and we are sure to continue to mature and shape this design system with each new project we take on. With Optics v1 we’ve set a strong foundation, one that will further enhance our software delivery process while helping us to up-skill and further leverage the unique skills and abilities found throughout our amazing team.

So What Is Optics?

Optics is a fully conceptualized design system, a collection of user interface components in Figma (our design tool of choice), and development implementations of common design challenges that can be shared among our projects and easily customized, while also being flexible enough to fit into and leveraged by our development tools.

The Vision

We needed a system to propel our projects forward, with a foundation for continuous improvement through active collaboration with our developers and designers. Optics was born from the insight that a unified design and development framework propels our projects to greater heights while providing excellent and consistent outcomes for our clients.

Harmonize Design and Development

We sought to harmonize our design and development efforts, and with Optics, we have bridged the gap between design and code through a shared language, allowing us to collaborate in crafting satisfying experiences.

Elevate Design Flexibility

We wanted to elevate our design deliveries while maintaining the flexibility that our clients require. Optics integrates a versatile design system with a collection of adaptable components and enhances our ability to tackle unique project challenges. It offers customizable solutions that uphold our commitment to precision and flexibility in every project.

Crafting Accessible User Experiences

We need to craft the user experience to be accessible and usable by all. At the heart of Optics lies our dedication to accessibility and delivering cohesive user experiences. Our comprehensive Figma component library, along with HTML/CSS components, ensures that every design meets the highest standards of accessibility, allowing us to create designs that are not just visually appealing but also accessible and aligned with our clients' brands.

The Pillars of Optics

Optics is built on three core pillars: our Figma component design library, HTML/CSS components, and thorough documentation.

Figma Component Library

In Optics, the design component library is crafted to give our team precise specifications for each component, fostering consistency across projects. This comprehensive library streamlines our development process, enhancing efficiency while maintaining a high standard of consistency in our work. Every design component has parity with its development counterpart, ensuring a consistent and repeatable design to development experience.

HTML/CSS Components

Our HTML/CSS components provide the foundation for our user interface development. Each component adheres to our best practices for development and accessibility. These components are highly configurable and designed to work hand in hand with our Figma component library to ensure what we design is what we deliver every time.

Documentation

We have documented each of our HTML/CSS components to demonstrate how and when to use each component while providing a playground for our development team to experiment with the various capabilities and configurations of each. In addition to this, our documentation has a growing list of code best practices, training materials, and code recipes.

The Technical Foundations of Optics

At the core of Optics is a suite of elements that anchor our design system. It's a collection of guidelines ensuring our designs are accessible, visually coherent, and meticulously structured. Each principle is a building block for creating designs that are both beautiful and functional.

Today, Optics consists of these guiding principles: Accessibility for all, Color that engages the customer and promotes strong branding, Typography that allows for multi-language support and elegant typesetting, Icons that are clear and that ensure a familiar and intuitive user experience, and Design Tokens that follow clear patterns and are shared between design and development efforts within our team.

Out of these foundations, Optics gets its name from our color system, where we modify color akin to photographic f-stops throughout a luminosity range. As part of meeting our accessibility standards, we’ve designed this robust color system to ensure contrast standards for accessibility are met while having the needed flexibility to provide visually exciting designs with rich color palettes.

RoleModel Design Principles

Optics isn’t just a static design system; it was designed to mature and grow over time and speaks to the core design principles that guide our team. These principles are the foundation of our approach to creating digital products that are both functional and compelling. With Optics, we achieve our design goals early in the delivery process, setting a great foundation for the future of every project.

Our fundamental design principles are that design should be driven by business value with the ability to adapt and refine designs to meet the unique requirements of various projects, keeping our focus on business process first. There should be consistency and standardization of our designs to establish a design foundation across projects, with standardized approaches in design and implementation to enhance overall impact. We design as a team through Cross-functional Collaboration and need solutions that help leverage and scale those efforts by facilitating tight feedback loops of Incremental validation between designers, developers, and product owners to build upon the design foundation. And finally, our designs must be accessible and usable by all, prioritizing accessibility in designs and ensuring that solutions are user-friendly for all potential users.

The Future of Optics

We’re excited to publicly launch Optics, in truth, we’ve been building Optics and using it on projects for several years now. Today, we launch Optics v1, but we’re already planning and working towards enhancements and will be providing those updates on an ongoing basis as we build, measure, and learn with each project.

Optics is a great example of applying RoleModel’s focus on Expertise Amplification and Iterative Value to our software delivery process. We now have a shared set of components and documentation that allow us to address the common user experience needs within our projects while delivering a polished design from the start of a project with less effort. We look forward to building upon this design system to serve and delight our valued customers for years to come.

We honed our approach to software design over the years to help maximize our value to our customers with proven best practices and standard approaches. In practice, this is applied with incremental validation that's driven by business value through cross-functional collaboration. 

Incremental Validation

Incremental validation is our application of iterative value to the area of design. We start with sketches to explore workflows and ideas that we further validate in mockups and clickable prototypes and then ultimately refine these concepts in the working software that we ship along the way. We use incremental validation to make sure that our user experience (UX) is functional (it meets some basic need), reliable (it consistently works as we expect), usable (it’s easy to learn and use its features), satisfying (it is enjoyable to use and life is better and easier because of it). 

Throughout this whole process, the key is receiving feedback from our customers and end users that ensures that what we're building is actually solving their needs. This ensures that we don't develop this whole project in isolation, where we get to the end of the project and the software is not actually what they were wanting. By continuously validating our design, our developers and designers work hand in hand together to continually improve the design and user experience of the software over the lifetime of our partnership with a client. Once we have working software, our work isn't done; we continue that cycle of feedback from wireframes to prototypes to software to continue to enhance the features and the overall project. 

Driven by Business Value

Our design practice is driven by business value. This means we focus on process first and software second, empathizing with our customer to really understand and learn their business so that we can ideate and prototype new ways of working that may be different than they have thought of before but can be validated with the value that the solution brings to the business. We’ll incrementally build solutions that we refined together because we're aligned on the shared business value that our solution is going to bring.

We design with our customers and end users in mind, focusing our attention on their ideal workflow. We want to enhance their productivity first and foremost, but we also want them to appreciate the experience along the way, ultimately creating a software asset that will simplify their workflow and enhance their productivity. This means that the design is not just to be pretty; it is to be aligned with your business value and business needs. 

We also take into account the trade-offs and constraints that exist in every software project. We're going to consider budget and technical implementation, thus allowing us to collaborate together from the business side, design, and development to ultimately deliver the best possible solution for our customers.

Cross-Functional Collaboration

Cross-functional collaboration means that our designers are not isolated members of the project team. We've oriented our tools and approaches so they can be deeply integrated along with our developers as they ship production code, not just design artifacts. This means they are focused on the current feature implementation but also looking ahead to what’s coming next on the horizon, so we can be prepared as a project team when we get there together. 

During a project, the designer is not only coming up with the overall design and UX, but they can also implement their design in code. This allows them to focus on the fine details while developers ensure the functionality works as expected and is performant.

A key part of this cross-functional collaboration is not just our internal team but our collaboration with our end customer. We want to take the ideas that we explored together and reflect them back in a different form so that they can be further validated. For example, using a sketch to ensure on the same page after a conversation. We want to ensure that we are hitting the mark with a feedback loop that’s different from the conversation and the process that we explored so that we can ensure that, incrementally, we get to the right solution. 

In support of our vision of serving business innovators, the RoleModel Way of Design focuses on the principles and practices that we can use to fully integrate as a team where design is central in what we do, not just focused on by designers. We do this through incremental validation driven by business value through cross-functional collaboration.

While it’s central, mentorship is not always natural or easy. It requires work, investment, and consistency. We define mentorship as assisting a colleague with personal and professional growth when invited to do so. It’s not about constantly giving advice, browbeating someone, routinely filling out forms, or being a full-time critic. It’s about giving helpful advice when needed, pointing out career dangers, flagging worthy pursuits, and generally encouraging and advocating for the mentee.

Mentorship takes a couple of forms, both direct and indirect. Each employee has a mentor assigned to them who focuses on advocating for their growth. In addition to assigned mentors, each employee has an opportunity to provide indirect mentorship to those around them by looking for opportunities to encourage and advocate for the personal and professional development of every single member of the team.

Relationship, not recipe

Our focus on membership is about building a relationship, not following a recipe. It’s not focused on performance evaluations or a checklist of steps we need to take—it’s about the whole person. We don’t just want to make better employees; we want to make better people and encourage people to grow. Mentors should encourage their mentees to look back on their accomplishments and lessons learned and look forward, inspiring their mentees with challenging but realistic goals. 

Like any relationship, you get out what you put in. If you contribute to the relationship, you will more quickly establish a foundation of trust that will serve to produce maximum value in your mentorship relationship.  

Trajectory, not a title

Mentors focus on what is holding their mentees back from their growth, providing accountability and steering them on their personal and professional journey. We are more focused on the trajectory of the person. How are they growing? Are they headed in the right direction? We only concentrate on a couple of things at a time to track progress, nurture growth in a particular area, and increase their effectiveness. You can’t focus on everything simultaneously; it’s too much. 

Eventually, the role of the mentor switches to how can I help you steer and navigate growing in those areas? We are going to keep an eye on your progress, but are you continuously improving, iteratively improving your abilities in those areas as you grow? If you are, mentoring has been successful. 

Mentor Replication

Mentor replication is central to how we think about mentorship and growth at RoleModel. It’s not about seeing an individual grow to their highest potential but rather unlocking the superpower that is the ability to mentor others in the same things they’ve learned. We grow by teaching, and focusing on the bigger impact of the team helps each individual to grow to their highest level. Mentor replication means that mentors guide their mentees, the mentees learn to mentor others through that process and eventually pass on that capability to the people they’re mentoring. It’s a reinforcing cycle; everybody gets better at it because we constantly practice it. 

Whether you’re a Craftsman or someone just starting their career, having people who are further ahead and behind you in the mentoring journey allows us to have folks who are humble enough to learn and confident enough to teach others.

We practically apply the RoleModel way of mentorship in several areas. With the Craftsmanship Academy, we build the foundation of learning with a new cohort of employees each year. And we continue that through direct and indirect mentorship focused on a clear growth path with tight feedback loops. 

The RoleModel Way of Mentorship differs from what you will find in most other organizations. It’s not about an administrative exercise; it’s not about checking boxes. It’s about creating a culture where we encourage growth, and people can feel free to receive and give feedback to help others grow. 

Mentorship permeates our culture. We focus on the relationship and not the recipe of how to get there, growth trajectory, not titles, and mentor replication—mentors that produce mentors.

RoleModel strives to be a company that is people and partnership-focused. We don’t want to just create software; we want to make a real impact on the people and businesses we partner with—that’s the most important legacy to us. We strive to be true partners with our customers, not just a vendor, to advance their mission and create software that is instrumental in bringing their visions to life. Internally we focus on developing people into leaders and launching careers through mentorship and collaboration. 

2023 Theme: Increasing Capacity to Serve

Our 2023 theme was increasing our capacity to serve. We described this as stepping on the G.A.S. from our foundation of success in 2022. We focused on Growing individuals, Adding to the team, and Scaling our impact.

This year, our target was further clarifying the path of growth for mid-level developers and designers and seeing everyone advance a level. We did this by introducing a new Craftsmanship Radar tool that better defines the expectations and responsibilities of each level and streamlines the assessment process through clear peer and mentor feedback. Additionally, we knighted a new Craftsman, Sean Kennedy.

We also added nine people to our team this year!  Reed, Sean, Justin, Hunter, Benj, Connor, and Blaine joined us as developers, Dallas as a designer, and Mitch as our Project Delivery Manager. 

Lastly, we focused on scaling our impact with our partners. We did this through strategic CCC Day experiments to expand our capabilities and seek more efficient and consistent ways to deliver value to our customers. We also completed 20 Expertise Amplification projects this year, with four more in progress. These are part of our 10-year target to deliver 100 software projects that provide expertise amplification (new or significantly improved capabilities or processes). We are already halfway there.

Retreat: Team Environment for Growth

Each year we host a company retreat with employees and their families to further relationships, build culture, and collaboratively set the direction for our upcoming year. This year, our annual company retreat was held in Asheville, North Carolina. A facet of our theme for the year was improving the way we grow people. This led to our retreat theme of nurturing a Team Environment for Growth anchored in our core values of Character, Collaboration, and Craftsmanship. While in Asheville, we took a team trip to see the Biltmore Estate and spent some time exploring Asheville, furthering relationships, and sharing experiences outside of work. 

2024 Theme: Impact Mindset

Our 2024 theme and focus is on building an Impact Mindset inspired by the concepts and practices of Liz Wiseman’s book, Impact Players. We will be looking at how we can apply this mindset personally through attitudes and habits to build deeper trust and credibility as a team focused on the W.I.N (what’s important now) with our customers. In support of that, we’ll be working to further define, and refine the unique RoleModel Way of approaching various areas of the business and our projects. We are starting with Mentorship, Design, Project Management, and Testing. Intending to add depth of understanding internally and externally. 

We are proud of the work we’ve done in 2023. See you in 2024!

Better Internal Tools

To best support our clients in building custom software projects, there are a number of internal tools we use, but sometimes they don’t have certain features or fit the way we want to work. Often, we can build integrations into off-the-shelf tools, or create the features we need to improve our capabilities. For this CCC Days, we worked on a new Figma design plugin and a capacity planning function for our internal software platform, Almanac.

We created our Figma design plugin to speed up the starting point for new projects including configuring our internal design system, Optics, and making partners’ branding changes faster and simplify ensuring WCAG AA compliance, which is an Americans with Disabilities Act (ADA) requirement that makes web content more accessible to people with disabilities. We built a custom component into Figma previously, but it was less designer-friendly than we would have liked, and through using it we have seen places where further enhancements would be beneficial and would save time in the design process. Some of the features we built into the new plugin will facilitate creating and managing Optics color themes within Figma, produce WCAG AA compliant contrast colors, create a faster interface for tweaking colors, increase design consistency, and reduce the need to copy/paste. This tool amplifies the expertise of our designers while using Figma and our design system.

Another team worked on creating a capacity planning tool for our internal planning and reporting system. We use this tool to plan our team’s time on projects, but we didn’t have a very user-friendly way to update it and we need a better way of knowing what team members are free to work on projects without double-data entry. We used a Google sheet to track a timeline view of projects and the team members' time on assigned projects. We examined other existing off-the-shelf solutions, but they didn’t fit exactly what we needed. Based on our exploration of other tools we had an idea of what additional features would be of use to us, the new tool has a visual overview of our upcoming work, each employee’s availability, and the company’s capacity to be scheduled for work. Some new features include a timeline of active and expected projects, the total capacity needed for each project, and available company capacity. It can be edited directly and then display the update across the tool’s features, sets expectations for support tasks, and takes time off into consideration. This tool will help us collaboratively plan our capacity for new and existing projects and ensure each customer is served well. 

Testing Improvements

One of our core practices is test-driven development (TDD), which means that we write a test for everything we create to make sure that everything is working according to the business rules we define and easily be changed in the future as the system grows. Improvements in our testing were one of the focuses of our experiments this quarter. 

An example of this was experimenting with adding visual diff testing to our automated tests to build confidence that new changes are not negatively impacting the UI. We are using this approach on one of our current projects and wanted to refine the approach so it will be useful in other projects.  We specifically looked at Playright which with some effort could be integrated into our standard testing setup. While we didn’t get to the final solution we made some promising progress we have built on as we look for ways to bolster confidence in our test suites.

Additionally, some teams looked at tooling improvements with a new continuous integration (CI) setup with GitHub Actions and speeding up our JavaScript tests with parallelization. We focus on continuous improvement with our testing setup so that we can provide Iterative Value to our clients with confidence that we have a sustainable foundation. 

Patterns and Tooling Improvements

Our experiments extract best practices from our tools or processes. Our approach to building software has us focus on the process first and the software second. The same idea applies to our business, we focus on our ideal processes and then build or edit tools to match that process. 

Our last group of experiments worked with patterns and tooling improvements that would facilitate our ideal process. One experiment we worked on was leveraging the new Strada framework to improve our technical capabilities for our mobile apps. When building mobile apps, you can use a fully native approach, a cross-platform approach, or a hybrid-native approach. The hybrid-native approach blends native controls and web content which allows for the performance and animation of native navigation with the flexibility to render content with web technologies.

Strada is designed to bridge the gap between web view and native components of an application via HTML bridge attributes, which makes it easier to progressively upgrade web interactions with native replacements.  Our goal was to refactor one of our existing applications using Strada and identify new features that would be possible within the framework. We worked with both iOS and Android to test native menus, forms, and action buttons, as well as other updates within the app. This was a really good experiment and we see this will allow us to further leverage our typical hybrid-native approach to deliver our clients polished mobile applications faster.

Some of our other projects that focused on internal tools include a client reporting interface, an integration between 15Five and Almanac which are two platforms we use internally, and an emergency support notification system to better alert us when a client needs to get a hold of us during an emergency. We also worked on further extracting and documenting common system architecture patterns and the why behind them so we can have a shared understanding when solving common challenges.

We look forward to CCC Days every quarter as a time to gather the team in one place and work with people who may not be on our regular teams, to grow in our skills and try new methods within our craft, and experiment with new features to eventually build into our partners' projects. This was the last CCC Days of 2023 with our company theme of “increasing our capacity to serve”. As we finish out the year, we are thankful for the time to experiment with new tools and methods that make us more effective so we can serve our partners better.

Custom software development requires a different perspective than purchasing off-the-shelf software. With off-the-shelf, you know exactly what features you are going to get, but you have less control in how it integrates or changes with your business over the long-term. On the other hand, custom software grows and evolves with your business. When you have an investment mindset with custom software, it allows you to shape the software to fit your business and directly impact your return on investment. 

Your business is a system and it’s important to periodically step back and think about the system as a whole. Is it running as efficiently as it could be? Are there areas of your business that are error-prone, or tedious? Is there anything that prevents you from scaling to the next level? Custom software can help you fill in the gaps.

A common misconception about custom software is that every part of the system needs to be built from the ground up. But there’s no need to reinvent the wheel, there are great pieces of software out there. Instead we can build an asset that integrates with those existing pieces of software—essentially building a hub that connects all of those disparate pieces into one unified system. Connecting those pieces lets you streamline your workflows, increase productivity, and reduce errors—driving value for your business. 

“Helping transform businesses with software is what got me passionate about pursing a career as a software developer. Early in my career I was working with a company that had this process where it would take someone three days each week to create a critical asset. It was very tedious. With some software that I was able to build for them, we reduced it down to five seconds to do the same thing and it really transformed their business. And we didn’t take that person and fire them cause their job had been replaced, no we freed them up to do the creative work that humans are really good at and left all the tedious stuff to the computers.” 

Our most successful projects start with investment-minded partners with a long-term strategic vision who are looking to enhance their unique competitive advantage with custom software. Based on our experience working across multiple industries, we’ve identified three indicators that your business may be ready for a custom software solution. 

1. You want to scale your business.

2. Off-the-shelf software isn’t enough.

3. You are overusing spreadsheets. 

You want to scale your business

Everyone wants to scale their business, and there are many ways to do it. You can do more of what you have been doing by hiring more employees and taking on more customers. But custom software allows you to take a step back, evaluate your processes and find your ideal workflow so you can scale the impact you have. Custom software acts as the lever, maximizing the inputs you put into the system that is your business.

Think of where you want your business to end up, are any of your current processes keeping you from getting there? Can they be simplified? Can they be used more effectively? Can you improve on the processes you already have? We can be your thought partners in understanding your processes, and then we can help you build a solution that is tailored to your business and help you scale.

How can we simplify our processes so that our growth is sustainable? One answer is, you guessed it, custom software. Software can codify your expertise and your competitive advantage—the things that differentiate you from the competition. 

Off-the-shelf software doesn’t fit your needs

Off-the-shelf software is great, until it’s not. It may only get you 90% of where you want to go, and that last 10% can be very expensive and it probably isn’t going away. But custom software can not only bridge that gap, it can also help you find other strategic opportunities. 

Sometimes there is a piece of off-the-shelf software that is critical to your business, and you are not looking to replace it. But that piece of off-the-shelf software is the sticking point in your processes causing issues like double-data entry and the errors that go along with it; those are the things that are slowing down your business. 

Recently, we had a client, Upward Management Group (case study) where we were replacing one part of their contract origination workflow but the heart of their business still ran on a legacy desktop application. We found a way to gather all the data gathered by the end users and transfer it straight into their desktop platform—completely eliminating the double-data entry and increasing accuracy along the way. That’s the kind of power and efficiency that custom software can bring to your business!

You’re overusing spreadsheets

Are you overusing spreadsheets? Often you are using spreadsheets to tie together multiple pieces of software that don’t really talk to each other. That’s where custom software comes in: thinking about how you can integrate those systems more deeply so that your custom software is the central hub of your business. Creating this hub allows data to flow directly between these systems, which reduces errors, allows you to scale, and ultimately allows you to design your ideal workflow. 

All business software starts as a spreadsheet. First you may have one, then a dozen, and then an entire collection spreadsheets to manage your business. You may be feeling the limits of that approach. Your business may be struggling with data consistency or the performance of reporting. That’s where tailored custom software can step in. The software we build together can streamline your workflows and codify your ideal business practices in software. Custom software can bring consistency to your data where it matters with the flexibility to grow and change alongside your business. 

At RoleModel, we treat your money as if it was our own, and we want to guide you to the right solution for you, whether that is an off-the-shelf solution, custom software, or a hybrid of the two. If one of these indicators hit home, it’s likely that you have an opportunity to consider custom software and we’d love to walk through those options with you.  

Our 2023 company theme is Increasing our Capacity to Serve, and for CCC days we looked at ways we could increase the value we are delivering to our partners through new capabilities and improved processes. Check out some examples of the work we did during CCC days below:

Web Push Notification for IOS

For this experiment, we looked at leveraging web push notifications that are now available on iOS (as of version 16.4). Often we see that notifications are a primary reason that businesses need to build a native mobile app rather than using the simpler architecture of a mobile Progressive Web App (PWA). We explored introducing trigger notifications in an existing app, managing app icon badges, and ensuring things worked across platforms (iOS and Android). The feature works well, but currently still an experimental feature in iOS that needs to be turned on by each user.

Collaborative LCAD editing

Collaborative editing is standard in many applications, like how a team can work together on the same project in Google Docs or Figma. Our goal is to eventually offer collaborative editing in our LightningCAD application, and this CCC Days experiment is the first step towards being able to offer that. We identified an architecture we could use for this, got a proof of concept working, and developed a plan for building this into a production project. 

Automated PR reviews

Another way we wanted to look at how we could increase our capacity to serve was by improving the feedback loops of our code reviews with some automation tools. This takes some of the common things a Craftsman would need to check on Pull Request (PR) and automatically adds comments using a tool called Danger. In addition, we explored how we could use some analysis tools to quickly show if the code change proposed would increase or decrease test coverage.

Testing Stimulus.js controllers with Cypress

We wanted to use cypress component testing to unit test stimulus controllers. Most of our stimulus controllers are end-to-end or system tests, we wanted a way to unit test the JavaScript with a full browser environment rather than a node-based emulation with jsdom. We had previously used Cypress component testing for React components in other projects and wanted to see how we could that with Stimulus.js through their framework definition API.  We release a new open-source package, as part of this effort and are looking to use this setup on our projects in the coming months.

Our other CCC days experiments included various internal workflow improvements including extracting information from applications or analytics to improve our processes and additional work on LightningCAD. CCC days are some of the highlights of our year, spending time as a company working to further our craft and learning together. We are thankful for this time together and are proud of the work we did to continue to increase our capacity to serve our partners. 

A skill that will help you grow in your profession and as a person.

Written by Josh McLeod

Introduction

Character, Collaboration, Craftsmanship.

At RoleModel, I think our core values are really good. One reason for that is the fact that my opinion of which is most important has changed several times. During my first few years as a developer, I highly emphasized craftsmanship in my own professional development goals and thought of it as the “core” core value—assuming that those who excelled in their technical knowledge were the most valuable, advanced, etc. But then I think of Ken Auer's recent words that he shared with the team and how he expressed his feeling that, through the years, finding people with impeccable character is ultimately how excellent teams are made. After all—if the soil is rocky, good farming will cause little growth.

What has not been mentioned yet is collaboration, and that is what I want to focus on now. Of the three, this core value has not been as emphasized in my career—yet—I think it is equal to the others. A good collaborator must be a good communicator. Communication is the way that one expresses their ideas to others. Without practiced communication skills, one's craftsmanship and character aren’t doing much good. You may have a category for how to grow in the craft of programming (or design, marketing, operations, etc.), but what about your craft of communicating? Growing in this craft will amplify your abilities in all spheres of your life—not just your job.

Why is writing so good for you?

In an article by Justin Bariso titled, “Your success will be determined by 3 things. Here’s how to get better at each” he quotes MIT professor Patrick Winston, whose burden for his students was that “no one should go through life without the ability to properly communicate” and that that would be like “sending a soldier to battle without a weapon.” The three things are:

1. The ability to speak.

2. The ability to write.

3. The quality of your ideas.

I am going to focus on the second of these now, and I would also argue that by practicing writing, one will actually improve one's ability to speak and the quality of their ideas at the same time.

You may be thinking, “Why would writing be important for software engineers?” If you are like me, you probably don’t associate the skill of writing with programming. In fact, having a lesser interest in humanities-related skills may have been what pushed you towards engineering in the first place. So why would you need to practice writing?

Justin Bariso writes in his article:

Jason Fried, the founder and CEO at Basecamp, says that they make all hiring decisions–from programmers and designers to marketers and receptionists–based on the applicant’s writing ability. Why? Because clear writing indicates clear thinking. The written word has special power. It can be done at one’s own pace. It can be continually refined and improved. It influences and motivates. And as more and more work gravitates to remote, it becomes even more important to be able to communicate via writing in a concise, easy-to-understand manner.

Why would Basecamp think so highly of a potential hire's writing ability?

Because clear writing means clear thinking.

The simple act of taking to pen and paper forces one to detangle the mind and produce a cohesive thought. It reveals new angles and lines of thinking. It boosts creativity.

Why programmers should practice writing

Here are some reasons that writing is important for you, fellow developer.

You will write every day: Discussing technical implementations through chat apps like Slack, writing Bug Reports, writing comments in your code, writing technical documentation, writing reviews of other developers, writing company best practices, answering questions from less technical employees or clients, creating design documents for complex work during planning times, and much more.

Jon Leydens, Professor of Engineering Education Research at CSM, said:

“In their first few years on the job, engineers spend roughly 30% of their workday writing, while engineers in middle management write for 50% to 70% of their day; those in senior management reportedly spend over 70% and as much as 95% of their day writing.”

Something that constitutes this much of your day-to-day ought to be something that you take special care to excel in.

Craftsmanship: Writing forces you to fill gaps in your understanding. It will help you gain mastery over the material you are studying and improve your ability to verbally communicate the concepts to others.

It will help you to write better code. The skills you gain from improving your writing skills will translate into the code you write. A clear thinker will write clear code.

It's a learning tool: An article by Judy Willis called, "The Brain-Based Benefits of Writing for Math and Science Learning" concludes with this:

The neural activity or mental manipulation that transforms formulas, procedures, graphs, and statistical analyses into words represents the brain's recognition of patterns. When this is also done in writing, the facts, procedures, and observations are processed symbolically in the writing process -- giving the memory another storage modality and truly illuminating the patterns for the brain to follow as it adds new learning to existing concept networks.

The ability to explain complex topics will set you apart: In an article titled “The Importance of Writing For Software Developers,” Ben McCormick says, “Once somebody hits a minimum threshold of technical skill to hold a job in the industry, about 80% of their ability to succeed in Software Development is determined by their communication and people skills, not their technical abilities.” Being competent at building software isn't enough. Great communication skills will be necessary to effectively lead a team and collaborate with the customer. Mastering your words will set you apart.

Not just a skill for C-levels and marketers

In my experience, as a junior software developer, the benefits of writing are not obvious. More emphasis is placed on getting to a code solution and improving the techniques used. Not much is placed on how to communicate the underlying ideas with excellence. Growing in that ability felt haphazard and tangential. I would encourage the low to mid-level developers to consider this and prioritize communication skills along with technical skills. I think the level 2-3 period of time is great to begin to practice more precise and comprehensive communication. At this point, you have been exposed to enough knowledge to begin applying your own critical thought and opinions.

This skill isn't just for CEOs and marketers. You need this skill too! It is one of the most important things you can practice now that will impact your career and life exponentially going forward.

Some Tips

If you are like me, and you truncated (or completely bypassed) the collegiate path, you may need to indulge in other avenues to get up to speed.

Like anything, practice is key to growing as a writer. You just can't expect meaningful growth if you aren't taking intentional, disciplined steps. What does practice look like?

Reading Books

I think this is probably the most beneficial thing you can do to improve your writing ability. Pay attention to the sentence structure and vocabulary use of authors you enjoy. Read books that push your reading comprehension. Soak it in.

Journaling

Journaling is a perfect, low-stakes avenue to grow as a writer. You needn't spend too much time trying to get the grammar perfect or ensure the flow of paragraphs is flawless. Just write what comes naturally to you and express what is going on in your head as naturally as you can. If you don't already make a practice of this, you should try it. It will probably help you in more ways than you realize.

Transcribe

Find quotes or essays that contain language that inspires you and transcribe it several times. Forcing your hands to produce the same characters in the same order will help you abandon your trodden path of sentence structures, vocabulary, and punctuation.

Technical Explanation

Look back at recent tasks you have completed, find something interesting and try to explain the technical accomplishment as clearly as possible, such that a developer following behind you could speedily understand the context and solution. If there is a portion of your application that is particularly nuanced or confusing, produce some well-thought-out READMEs, making an effort to articulate effectively and simply. If you are writing a commit message, use enough words to supply a sufficient context and explanation of what was done.

Blogs and essays

If you want to take things to the next level, try blogging or writing essays. These mediums demand more time and effort. You will read your work over and over again, move sentences from here to there to make the flow of thought more cohesive, change out words and phrases for better ones, and maybe even get editorial input and feedback before calling it complete.

Conclusion

Words are tools. Punctuation is a tool. Sentences are tools. These tools all help you to become more effective in your job and in your life. The more control you have over these tools, the more influence and reach you will have.

Martin Luther said, “If you want to change the world, pick up your pen and write.”

Treat these tools like your code editor or programming language. Dull them by constant use, and then sharpen them by embracing new innovations and plugins. Recognize the role they play in your productivity and catalyze their usefulness. Read the documentation to learn about new APIs. Observe how the more experienced people around you wield these tools and imitate them.

Remember the advice of Professor Patrick Winston: "Don’t go into battle without your weapon."

References

• Ability to succeed depends on these factors

• The Importance of Writing For Software Developers - Herding Lions

• https://www.edutopia.org/blog/writing-executive-function-brain-research-judy-willis

• Why I decided to write

• How writing can advance your career as a developer - Stack Overflow Blog

We use this time to work on internal projects, test theories about different methods of development, or explore platforms/technologies that could make our service to clients efficient. These experiments also give our more junior team members the opportunity to lead a project and develop their skills in guiding a team.

Below are some of the experiments we worked on these CCC days.

DPQ Kickstarter

We worked on creating a starting point for LightningCAD Design Price Quote (DPQ) projects so that foundational code can be more easily generated based on the needs of the product line  every time we onboard a new partner. Now, developers will be able to choose starting points from a menu of choices and the code will automatically be produced—they can begin the customization from there. These updates will speed up the time it takes to onboard new partners. 

Enhance DPQ and Optics Design System Defaults

We refreshed design themes for our default styles, including enhancing and cleaning up our default control styles and how they work with Open UI. We worked to improve the light theme and began production on a dark theme. Lastly, we applied the controls to our DPQ platform and added components to our Optics Design System.

Richer Turbo Native Interactions

The team worked to create deeper integrations with hybrid mobile apps and native components using Turbo iOS. This included a richer integration for modal forms and the branding on navigation controls. We also experimented with different approaches for full native screens like login with biometric authentication (such as TouchID and FaceID).

Build pipeline / deploy package

We wanted to improve our process for publishing new versions of our LightningCAD framework as an internal package. This experiment focused on the packaging approach for different versions of the framework (CommonJS and ESModules) and integrating with our common development tooling.

Component testing with real browsers

We chose this experiment because we wanted to find some better patterns for testing our JavaScript components with real browsers to avoid the limitations we’ve run into with tools like JSDOM. Often we’ve found that components that incorporate lots of browser events or web components require a lot of stubbing and can be brittle. The team leveraged component tests from Cypress with good success and a path forward to incorporate them into future projects. 

Chow talk search interface for almanac 

Every Friday we have company-wide lunch and learn “Chow and Pow-Wow”. It is a time to connect and share learnings in lightning talk form. The goal was to increase the visibility and access to valuable information from these company-wide meetings. Before, when we need to reference a talk we have to search through the catalog to find the correct one. Now, we can search talks by tags and find the one we need, with the timestamp marked for each talk.

Blazer Reporting Generator Improvements

We use an open-source reporting tool called Blazer in many of our projects. For this CCC day project, we made it easier to add common Blazer customizations to our projects. We also produced a solution to a SQL injection vulnerability in the extension of our use of Blazer.

LightningCAD locator performance+

For this project, we continued an ongoing research project optimizing LightningCAD performance, with the goal of increasing performance for complex applications. We also built interactive training materials and documentation to onboard new developers to LightningCAD, using visualizations to explain core concepts.

Vite Asset Compilation in Rails

Rails 7 has dropped support for Webpacker as the standard way that assets are handled in Rails. We wanted to explore Vite, which promises a better developer experience and batteries-included setup.

Replace Rails UJS Common Patterns

Over the years we’ve built some customizations on top of Rails’s UJS (Unobtrusive JavaScript) and with UJS being deprecated we want to update those approaches to be ready for new projects. This included modal dialogs and custom confirmation dialogs, which are components that we use in virtually every app we build. As a part of the effort, we published a new open-source NPM package to allow for better customization of confirmation dialogs with Turbo.

Refine Operations Automation Environment

Up until this point, we have been developing our Operations automations in Google Apps Script and we wanted to set up an experience that fit RoleModel’s workflow better. We added the ability to edit code locally with our preferred tools and the ability to store code in GitHub. We also created a way to access shared libraries (common code) to share resources between projects. 

__

The whole company was hard at work for our CCC days this quarter, with varying results for each experiment. In each experiment, we either shipped a valuable improvement to our process or learned something new that we can leverage for future experiments.

In 2022 we celebrated the 25th anniversary of RoleModel Software. 

We are so blessed and want to take a moment to thank our clients, partners, and employees for an impactful 25 years in business. We love collaborating with our partners and are thankful they trust us to enhance their business. With this anniversary, we are spending time reflecting on everything we have accomplished this year. 

Growing the Middle

Our 2022 theme was “growing the middle”. We wanted to focus on growing the number of medium-sized businesses we partner with, as well as paying special attention to the middle levels of our company. We have many wonderful Craftsmen who work with our partners to build their ideal custom solutions. We are also fortunate to have many recent graduates of our Craftsmanship Academy who are growing in their skills as developers.

This year, we concentrated on building the people in the middle to bridge the gap; we celebrated several promotions and hired eight people, including three mid-level developers. We focused on growing the number of medium-sized business partners by expanding the reach of our Design Price Quote (DPQ) solutions. Curtis Bos joined us as the Product Manager for LightningCAD/DPQ, and we hired our Marketing Communication Specialist (Becky Passner).

Partnerships

In 2022 we strengthened partnerships and began new ones. We worked with Cultivate Leadership Institute (CLI) to develop an IOS app and a hybrid web app so students could navigate the lesson plans for their program. RoleModel’s work with CLI continues to expand the software so it can be licensed to other organizations. We had the opportunity to interview their president, Dr. Eric Freeman, about their experience working with RoleModel.  We also worked closely with Upward Management Group, diving into their expertise in the rent-to-own industry. We got the opportunity to visit their offices and get feedback on their software. 

This year gave us the opportunity to partner with companies across a variety of industries—three projects to highlight are solutions for Winslow Homes, Methodist Homes for Children, and the US Air Force’s RED HORSE squadron.

Winslow Homes is a custom home builder that faces ever-changing building costs. RoleModel built them a flexible system that made it easy to update prices across the system without changing locked-in estimates. This flexibility helps them ensure they can give their customers accurate estimates.

Methodist Homes for Children is a non-profit that works with children in their care to build life skills. They needed a way to track interactions with their clients and their resident counselors. RoleModel built them a system where users can input information quickly. The system produces visual representations of the data so the resident counselors can show a child’s progress, and track interactions over a period of time. Saving dozens of hours of time per week and vastly improving the quality of care with more accurate data.

RED HORSE is a squadron of the US Air Force that builds airfields. They wanted a better way to find the most efficient place to build a runway for different aircraft. RoleModel is building a system that allows them to import a topographical map and the software automatically calculates the best place to build the runway. 

In our partnerships, we often focus on expertise amplification, creating iterative value, and process scaling. In 2022, we grew the number of projects that involved expertise amplification by 40%. These projects took a complex process and automated it with set rules and parameters within the business context, resulting in quicker and more efficient processes without needing the expert on hand.

Our Team

Each of our partnerships have been possible because of our great team. Every year, we go on an annual company retreat to focus on our collaboration as a company. This year, we spent a weekend in Williamsburg, VA. The retreat is a time of focusing on our goals for the year ahead, both personal and professional. It also gives us time to connect as a company since many of us work remotely. We value the time we spend together, getting to know each other better and creating memories as a group.

We are thankful for our team and the work they do and are excited to celebrate their efforts. 2022 was the most impactful year of RoleModel's history and we look forward to increasing our capacity to serve our clients even more in 2023!

Feedback

Feedback is crucial for success when you are learning a new skill. One of the ways we give feedback at the Craftsmanship Academy is “just-in-time learning.” We don’t critique the work they haven’t done yet, but we ask questions in the moment. “How did you approach that?” “Is your method attainable?” “Is that the smartest way to accomplish that?” 

We practice pair programming and test-driven development because they give you immediate feedback. In the academy, we have code sacrifices. In a code sacrifice, someone volunteers to show us their code, and we all talk about it. “I see you did this. What about doing this?” When you are done discussing their code, you move on to the next person. Do they have something different? Often, feedback applies to more than one person. Code sacrifices let them get feedback from an expert. 

Code sacrifices are a more direct form of feedback than industry-accepted pull requests. In a pull request, I submit the code to whoever is in charge, and they look at it whenever they can get to it. It’s an asynchronous review. I write the code, then later, they find some time in the day to look at it, maybe a cursory glance. They write their feedback; you may want to think about this or that. There’s no dialogue. But with the code sacrifice, you can give and receive feedback in real-time. “What made you choose this method?” “What about doing this instead?” “Here are some techniques I use.”

In-person dialogue is a richer and more effective communication channel. 

Intuition

A few years ago, I was exposed to the Dreyfus Model of Skill Acquisition, which helped me understand the variety of expertise in individuals with the same amount of industry experience I’d observed over many years. The experts best understood why “best practices” were best practices. They understand that context matters. They seek feedback. Not only should what they create “work,” but it should not introduce more complexity than is inherent in the challenge being addressed. “Expert beginners,” on the other hand, just worked by themselves until they got something to work.

At the academy, apprentices always learn entire systems, not just portions of them. Many programs, such as boot camps or computer science degrees, use a fill-in-the-blank approach or have their apprentices be able to select an approach to use.

The concrete examples of software development are entire applications, not just some single problem out of context. We help to develop their sense of intuition by working on concrete examples to cement concepts needed to produce solid solutions. 

There is no way to get around the need to gain understanding. There is a problem that needs to be solved, and we are not going to solve it for the learner. We present the problem, give a concept needed to take the next steps, and leave the learner to take those steps on their own. They can’t give up. If they are stuck because they don’t fully understand the concept (or sometimes previous concepts that they need to build on), they’ll have a chance to get help from the expert in a little while (usually an hour or two). But then it is back to working through the solution themselves.

If the learner “gets it working” but does it by introducing unnecessary complexity, they get the feedback they need. When we give them examples of code to show an approach to solve a problem, we just show them once and then take it away… they have to reproduce it themselves and take it all the way through to a solution.

We don’t fool ourselves and don’t let them fool themselves into thinking they are experts. But they get more feedback in a few weeks than many get in years, and they have developed the habit of seeking that feedback to constantly improve.

Experimentation

RoleModel has a culture of experimentation, but the academy can’t experiment until they finish the immersion phase and have a solid foundation of the basics. We introduce methods of experimentation slowly, in a couple of different ways. 

First, we introduce new constraints, such as writing code that solves this problem in seven lines or less. Now, you can only use this method, etc. We give them constraints, not necessarily upfront, just a little bit at a time. We do this to help teach best practices and to help them understand how to do things in the real world. For example, writing a solution in seven lines of code or less helps them think about how to do things simpler and how to isolate a section of code. It makes you think beyond “does this code work?”

Every quarter, RoleModel holds Character-building, Collaborative, Craftsmanship (CCC) days, where we put aside our day-to-day work and work on experiments to advance our craft together. The academy participates in those experiments alongside developers further along in their careers. So, not only is there experimentation for the academy participants to participate in, but they see how experts experiment. Later, when they start their own experiments, they’ll be doing so with some extra wisdom gained in how to approach an experiment.

After they’ve gotten through our immersion and internship phases, they are assigned to read “Software Apprenticeship: Guidance for the Aspiring Software Craftsman.” Inevitably, they choose to follow its advice in doing some of their own experimentation. But having lived in the environment for ultralearning, their experiments benefit from the wisdom they’ve gained through being guided by mentors that are already what they want to become.

Summary

“Just-in-time” learning allows Academy participants to receive feedback in the moment. They participate in code sacrifices where they can get feedback from an expert and listen to the feedback their peers get, which often applies to more than one person. 

We learn by using concrete examples of real-world software, and we look at entire systems. This helps develop their sense of intuition by cementing the concepts in the contexts they face in their careers. We also give them constraints when they’re learning to write code that help them reduce unnecessary complexity. They’re not experts yet, but they’ll get more feedback in a few weeks than others get in years.  

Conclusion

Scott Young found Ultralearning to be effective across a variety of disciplines. Meanwhile, we developed a similar approach with the Craftsmanship Academy long before we heard about Scott or the work he’s doing with Ultralearning. When we first learned about Ultralearning, it gave us a vocabulary for everything we saw working at the Academy. 

This begs the question, why aren’t more people adopting the principles of Ultralearning? We have examples of the concepts working across multiple fields documented in Young’s book, Polyface’s farming, our Craftsmanship Academy, and certainly others yet to be documented. The principles are clear. Academia’s model falls short.

If you want to learn a skill, using the concepts of Ultralearning will get you where you want to be. Creating spaces like the Craftsmanship Academy helps the next generation more effectively learn their craft by designing an Ultralearning environment. The path to mastery will be clarified through environments that provide both directness and feedback. 

In case you missed them, here are Part One: Why Our Software Craftsmanship Academy Overcomes Academia's Biggest Problem, Part Two: A Successful Environment for Ultralearning Software Development, and Part Three: How Directness Reduces the Need for Drilling

Directness

Academy participants are not solving any “academic” problems. One of the definitions of “academic” is “theoretical or hypothetical; not practical, realistic, or directly useful.” They are taught how to use the same tools and practices our developers are using when they tackle their initial “toy” projects we give them at the beginning of the academy. But these are not academic. They are practical “low stakes” applications (e.g., an interactive game of “Go Fish”) that can be used by anyone… and they are assigned to get feedback from potential users of these applications, which they can find among their family and friends… or random strangers.

Within the first month, they are getting time with experienced developers working on real-world (and typically somewhat advanced) applications.

They are either looking over their shoulders as they work, contributing to the discussion as to how to address the real-world challenges they are facing that day, and sometimes even taking a shot at solving those challenges themselves. They don’t have to overcome the use of the tools, so they have less trouble jumping that gap of knowledge they have not yet attained because the impediment of the tools is no longer there.

By the time they are in the apprenticeship phase, they have the best practices; when they shadow an expert in the field, they begin to apply them to problems they haven’t seen yet. We’ll give them tasks that they are prepared to handle in a real-world project where you can see how it applies. This is where they apply the skill of transfer.

They are learning what they need to accomplish an actual goal. They’ve been through the immersion stage; they have the tools. Now it is time to see how they apply in project-based learning. Sometimes, they are given stricter rules than they will have in the real world for the purpose of learning. We tell them any method you write that’s longer than seven lines of code; you throw it out. In the real world, you may need more. But for the purpose of this project, stricter rules guide better solutions. 

They learn from the source. If you want to learn to be a software developer, you have to learn to develop software. When they fail miserably, we talk about how they can do better. We ask them questions that will hopefully guide them to a better solution. By answering them, you should end up with better code. 

Within months, they are spending most of their time working on project teams, and the rest continuing to bolster their understanding of more advanced topics so they can contribute more to their project teams (and others). Their mentors are not burdened with teaching them everything they need to know about software development; just how to apply the concepts they’ve already learned to the problem at hand and fill in some conceptual gaps… the last 20 percent that takes a lifetime.

Drill

Many developers don’t recognize that they should not just get something to work but get it to work well. The concepts we teach early on guide them to create clear, concise code. Without it, they will be building a big ball of mud. One way we get them to do this is to have them work on the same domain on several different projects with guided rules they must follow and instructions to delete any code that doesn’t conform to the rules. They get it.

And, by building projects with different technologies in the same domain, they see opportunities to do something different/better each time they build a similar application. The knowledge they pick up transfers to the next application, and the gaps get smaller. As their knowledge continues to grow, it is ready to transfer to a different domain.

We drill new best practices in the same domain to ease the cognitive load, pushing but not breaking it. This way, they can apply the best practices in a domain they already know. When they get stuck, we can get them past their freezing point by giving them a boost or just enough of the answer to get unstuck, allowing them to focus on the new skill. 

Sometimes we write the first test for them. Giving them an example, or two, or three. Once they’ve seen an expert do it, they can try it on their own. Giving them directions or examples before they try reduces the cognitive load. 

We design the drills and practices for them. All they have to focus on is the new best practices or skills that they are learning and understand how to apply them to the project. Some skills, like intention revealing names and test-driven development, get introduced on day one and continue all the way through their training. You need to get those things, even if you get nothing else. 

Retrieval/Retention

We have a mantra that we teach the academy apprentices: make it run, make it right, make it fast. We focus on repeating key things often until they become second nature. Some of the principles they learn in the first week they get every week after. If you do something every day, it becomes normal.

The difference between an immersion program and a traditional college degree is that in a college program you skip around between subjects; in an immersion program, you focus on best practices that build on each other, and you practice programming every day so that you can apply it.

As you practice a skill, it causes retrieval. When I jump back into programming after I haven’t done it for a while, I look at a problem and think, “I know there’s a solution for that,” but I have to go look it up. After programming for a few days though, my fingers remember shortcuts that I didn’t even remember I ever knew. Working on best practices every day helps condition your brain to retrieve information and even helps improve background memory—like those shortcuts I didn’t consciously remember. When you are working on projects, solidifying best practices for 8-10 hours a day, retrieval happens.  

Summary

From the beginning of the academy, participants are learning to use the tools developers use in low-stakes applications where they can make mistakes. Within the first month, they start working with experienced developers and see how the tools they are learning to use work in advanced applications. When they get to the apprenticeship phase, they understand best practices and can apply them to problems when shadowing an expert. 

They are learning with a goal in mind. When we give them projects to practice on, they are working with different technologies in the same domain, and the knowledge they gain on each project transfers to the next application, and their understanding grows. By working on key concepts every day, best practices and key concepts become second nature.

In part four, we’ll discuss the critical need for feedback and how it nurtures intuition, which builds a foundation ready for experimentation.

In case you missed them, here are Part One: Why Our Software Craftsmanship Academy Overcomes Academia's Biggest Problem and Part Two: A Successful Environment for Ultralearning Software Development

After reading about the ineffectiveness of formal classroom education in Ultralearning, I couldn’t help but reflect on an invited talk Nathaniel and I gave at the OOPSLA 2000: Educator’s Symposium. The talk was entitled “Apprenticeship in a Software Studio: An Old and New Model for Education,” in it, Nathaniel Talbott and I basically explained our 2.5-year experience. Nathaniel, at the time, was the post-apprentice, and I was the “Master Software Craftsman” who oversaw his learning and growth as we worked on custom software development projects. At the end of our talk, one of the formal educators said, “He’s going to ruin that poor kid.” I recently called Nathaniel to apologize for ruining him. He is a happy husband and father who has provided for many children. After 20+ years in the industry, in which he started two companies, including a successful start-up that was sold for tens of millions of dollars. He readily forgave me.

In addition… we have launched many highly effective and successful software development careers.

Not everyone has made it through with flying colors, and a few dropped out. We’ve gotten better at identifying success factors in applicants. But those who have completed our Academy have definitely learned deeply and in an accelerated fashion. Most have had great success in just about every measure one might have unless having “the college experience” or “earning a degree” is your measure of success. Note, however; we have had some Academy completers who joined after a college experience and one that earned two accelerated degrees after completing our Academy while working for us part-time (a B.S. in Computer Science and an M.S. in Data Science).

What we call “immersion” sections are similar to learning by simulation.

We give them all the same tools that our developers use but give them a project where no one gets hurt if they crash. We start with immersion/simulations guided by our experienced developers and slowly bring them into our real work, with the goal of going from Novice (what we call them until they complete our first two immersion sections), to Apprentice, to Resident, Sr. Resident, and eventually “Developer” and beyond.

So, where is the application of the principles of Ultralearning in our Software Craftsmanship Academy?

First Draw a Map

Ultralearning advises its adherents to draw a map of what they need to learn to achieve their goals. It warns that it won’t be perfect because they don’t know what they don’t know yet.

Since we’ve done this for a while, we have a pretty good handle on the basic concepts Academy participants will need to learn. We’ve drawn the initial map for them on the things they need to learn to become a successful software developer. It may not be perfect, but we are confident it is far better than what they might figure out on their own. It’s the 80/20 rule. We’ll hit the first 80 percent of what they need to know in just about every software project they’ll ever be involved in. The other 20 percent takes a lifetime.

We break the 80 percent into one-week chunks with progressively harder projects to cement the concepts they’ll be building upon and expose them to the next set of concepts. We tell them they are pretty much expected to have a working application at the end of each week, and in order to do that, they’ll have to apply a given set of concepts that we expose to them at the beginning of the week. This is a project that is bigger and different than anything they’ve done before (although relatively simple to an experienced developer).

However, we don’t just draw them a map of concepts with names they don’t understand. As expert guides, we lead them through their journey, giving them what they need at the moment. They can only see somewhat clearly to the horizon that is in front of them. When they get to the following horizon, the next section of the map becomes relevant. 

We point them in the right direction, and the next horizon is a week away. We leave them alone for a few hours to make progress in applying the concepts we’ve given them to the project at hand. We set them up to get to a point on their projects where they’ll hit a bump and will need a new concept to get over. We know it’s coming.

The concepts we give them fit the context of the problem they are facing, so they apply them right away and start getting comfortable with them. They see and feel how the concepts apply.

We check in and make sure they are applying them well, asking them to offer up a “sacrifice of code” that we put on the big screen for each to see as we offer constructive criticism on what they’ve done so far. There are no points marked off their test; just learning how to better apply the concepts. We ask if they have any questions about how to proceed.

They may have other questions, but there is a good chance they’ll be up against a problem that either: they addressed in a way that would bite them later, or it stopped them in their tracks because they smelled the danger and didn’t know how to avoid it. When that happens, we’re ready with the next concept, which usually takes just a few minutes to explain. They are already in the context where the concept is needed. Instead of explaining the context in an abstract way and hoping that they would someday see a concrete example and recognize it, we might explain that this is a concrete example of an abstract, but common, approach to something they’ll come up against again. 

If we told them everything they needed to know ahead of time, they’d be overwhelmed, and some concepts would slip their mind when they need them, even a few days later. They wouldn’t recognize the context where it should be used. Once they have felt the pain and felt how the concept relieves the pain, they rarely forget it. Contrast this with teaching a lot of concepts in a classroom setting and attempting to explain the context in which each would apply and giving them a test in which they have to repeat back the concept and context. If it was years until they ran into the context again, would they remember it? We introduce the most foundational and pervasive concepts early, building upon them and hammering them home over the following weeks. The projects they build in the first part of the immersion are somewhat toy projects (they actually work and can be used, but they are not necessarily very marketable). But, when they join our experienced developers on real projects within a few weeks, they’ll already know these concepts. 

Practice Before Theory?

I remember taking my Linear Algebra class as a sophomore in college. We learned about determinants. I struggled to get the concept. I didn’t know what it was for. Twenty years later, I tackled for the first time a project working with 3D graphics programming.  Someone pointed out the value of a determinant. All I remembered was the word and that it was taught in my Linear Algebra class. I had to relearn how to calculate it and learn for the first time how to apply it. That took a few minutes. Would it have taken any longer if I hadn’t ever taken that Linear Algebra class and instead was introduced first to 3D Graphics programming? I’ve seen people learn in a matter of weeks more of the relevant concepts about software development than I learned in my four-year computer science education at a top engineering school. And in a matter of months, our Academy participants have more experience actually programming and on more significant projects.

The only real academic prerequisite we have before the journey on our initial map is that they’ve already learned the basic fundamentals of programming (variables, conditionals, loops, etc.) and have applied them on some (presumably trivial) projects. Part of the application process includes an interactive assessment in which we present elementary problems and see how they handle answering them. (If they don’t have the background to answer the problem, we see how they might reason about their approach to solving the problem. For e.g., we give them a problem that COULD be solved through recursion and see if they “smell” the solution, whether they can actually write the code or not).

We also give them some pre-work to get familiar with the environment they’ll use when the Academy starts. The more solid they are on the fundamentals of programming and familiarity with the environment, the better, but as long as they have the prereqs before starting, they are ready to be immersed.

After they complete the first three months of our Academy, they have a bit more background to help them draw the next part of their own map. Maybe they want to focus on front-end development, or back-end development, or 3D graphics, or ???. They finish the immersion phase of the Academy with the foundation they’ll need for any of those with content for the bigger picture. For e.g., “front-end development” exists in the context of a broader software application, and they should understand where it fits and why everything should NOT be done on the “front-end.”

Focus

We tell them to minimize any outside distractions during the Academy. They’ll be putting in at least 40 and up to 60 or 80 hours per week focused on getting their projects done within the guidelines they are given.

Just like the example of people becoming proficient in a foreign language through a 3-month immersion, we want them to be immersed in becoming proficient software developers.

Beginning on day one, they have a problem to solve, and they have to solve a certain amount of it by the next day. No time for procrastination. You have a deadline to keep. They keep this pace during the duration of the immersion period. If they get stuck or don’t hit a goal in time, we work with them to diagnose why. Once we understand why they are stuck, we help them develop a solution and try again. 

The whole group has the same tasks to focus on. They all sit in the same room, all focused on the same problem, all with the same deadline. They have to stay focused on best practices, and we give them rules to follow to stay on track. All the problems they work through are designed to engrain good habits and to allow them to focus on the patterns they will need to know to accomplish just about anything. 

From the beginning, they use test-driven development. They must write a test for any code they are going to write; if they don’t write a test, they have to throw out their code. We are teaching them to become software developers of complex systems. Best practices allow you to solve complex business problems without the extra complexities, solving complex problems in a simple way. Once they understand and can implement best practices, they can apply them to complex situations. 

When you want to learn a new skill, there is so much to learn you don’t know what to focus on. Giving a bunch of theories at the beginning of a journey is an almost sure way to use the wrong theory in the wrong context. Since our goal is to teach people to be a producer of sustainable software, the core values of what needs to be pervasive to create sustainable software are what we focus on… not individual theories that only apply in certain situations. We explain the importance of Intention Revealing Names, and the mantras Red-Green-Refactor and Make it Run, Make it Right, Make it Fast (Enough). These are things that the best-experienced developers have learned are consistently important.

In contrast, years ago, I remember being at a client where they hired a young developer fresh out of college with a B.S. in Computer Science. At the end of a workday, he asked me to check out the work he’d been doing. He then showed me how he had built a binary tree collection because the application the client was building had been using linear searches, and they are “so inefficient.” Examining his work, I quickly recognized the unconventional naming conventions he was using that were not consistent with the rest of the system and made several attempts to pinpoint the particular performance problem he was asked to solve. He kept saying that they were using a linear search. I then asked if the typical collections of objects in this part of the application were particularly large, as in the thousands or tens of thousands. He said, “no, typically 5-10 objects.” At this point, all I could do was gently inform him that it would take a lot of work to convert those collections into the ones he created and how quickly the linear searches he was concerned about were already being done by the computer.

Although I am thankful for those who have studied search algorithms, and know a bit about them myself, teaching them without the context of application software development can easily lead an aspiring software craftsman down the wrong path. I typically share the above story in the context of teaching the “Make it Run, Make it Right, Make it Fast (enough)” mantra that will keep a young developer from wasting time optimizing something that takes the computer nanoseconds to accomplish. And when I see them actually doing something that might take the computer seconds or minutes to do, I point out the general types of things that actually contribute to most performance problems (which are almost never bad search algorithms). We discuss where to focus and what to do to get around them. We also point out the costs of premature optimization and why we don’t typically start there.

We give them what to focus on and create building blocks so they can go farther. We build an environment tailored to immersion and create a place where they can succeed in learning new skills quickly.

Summary

Ultralearning advises those who want to learn a skill to draw a map of what they need to learn to achieve their goals; in the Craftsmanship Academy, we’ve drawn the map of the things they’ll need to know for them. We will give them enough information to get to the next place on the map. When they get stuck, we give them the next concept, and so on. This way, they get the information when they get to the context they will use it, and they will remember it better in the future. 

Using “just-in-time” learning helps us teach the basics of software development in the short immersion period of the Academy. Going at this speed requires participants to focus on learning their craft. They have weekly and sometimes daily deadlines to keep up with, and they’ll all have the same task to focus on, so they’ll help each other understand concepts as we go. 

We start teaching best practices from day one, and the problems they have to complete help engrain good habits. Giving them what to focus on and creating building blocks of knowledge helps them go farther. This method allows them to learn new skills quickly and thoroughly.

In part three, we’ll discuss how this focused environment leads to directness in teaching, reducing the need to drill and improving retrieval and retention.

In case you missed it, here's Part One: Why Our Craftsmanship Academy Overcomes Academia's Biggest Problem, and check out Part Four: Feedback in the Context of Directness.

Recently, I have been listening to “Ultralearning” by Scott H. Young. By the time I hit “Chapter VI: Principle 3 - Directness: Go Straight Ahead,” I felt like I was listening to the perfect justification for something I’ve been believing and practicing for years. 

It pointed out that Academia’s dirty secret was their struggle to obtain “the holy grail of education… transfer”, defined as the “ability to extend what has been learned in one context to new contexts. Educators hope that students will transfer learning from one problem to another within a course, from one year in school to another, between school and home, and from school to workplace.” (excerpt from “How People Learn: Brain, Mind, Experience, and School: Expanded Edition 2000”, National Academies Press). The reality is that formal classroom education doesn’t transfer to the exact situation in which you want to use the skill that you theoretically learned. According to Robert Haskell, “research findings over the last 9 decades clearly show that individuals and academia have failed to achieve transfer of learning on any significant level… without exaggeration (there is) an education scandal.”

This particular chapter in Ultralearning then goes on to point out that to learn a topic, you should not ignore directness. Transfer is harder when knowledge is limited. Scott Young points out that you can overcome the challenge of transfer by directness. Concepts learned in direct application are learned more deeply and, therefore, can more easily transfer to other applications of that knowledge.

A better approach might be to tackle a project with some “just in time” guidance from experts in a field. This is consistent with my experience in my software development and consulting career. My experience in other areas I’ve learned at some level of depth quickly (e.g., video production, woodworking, house building) also confirms this approach.

Embracing Situated Learning

This approach is how I’ve been helping others learn software craftsmanship for around 30 years. (I was mostly focused on learning it myself in the first 10 years of my software development journey, which included a B.S. degree in Computer Science).

Helping others become “Ultralearners” all started when Ivar Jacobson sent his daughter, Agneta, to immerse herself in learning what she could of the USA and software development at my former employer. After completing her college degree, she was given a list of sub-projects with the goal—to figure out how to build the software tool he had imagined. She “lived” at our office and in the home of one of our developers while working on these projects and received “just in time” guidance, exposure, and help over the hurdles. After seeing the incredible growth in her over those short months versus the people we had given “classroom training,” we were inspired to do something that would be similar. 

We created an immersion program called the Smalltalk Apprenticeship Program, where we teamed an expert with 2-3 relatively novice developers from our client companies to work on a project. They came to our place for 1-2 week stints over several months and received guided direction in building their project with “just-in-time” learning whenever they didn’t know what they needed to take the next steps.

We found that these “apprentices” would typically advance in 2-3 months beyond what others with 1-2 years of experience had attained without this sort of training.

These “apprentices” were typically in their 20s or 30s and already employed by someone else in business. I was being paid to train them. However, I often wondered what the prerequisites were for success. I kept observing that success in learning had very little to do with the previous formal education of the “apprentices.” Their desire to dive into the challenge of building a significant application with technology they knew almost nothing about, as well as general problem-solving skills, seemed to be more relevant. 

Over the next few years, I worked with people with degrees in Computer Science, Human Factors, History, Music, and others. If there was any correlation between their previous academic education, it might have been that the Computer Science majors typically had more stumbling blocks. (E.g., they might try to optimize the performance of the code before they built an effective model to serve the domain of the application).

When I started my self-funded custom software development company, I determined that I couldn’t afford to hire a college graduate in Computer Science at their expected going rate and then have to teach them how to develop software in the real world. So, I attempted a low-cost experiment to teach some straight-A high school graduates what they would need to learn in a few months and see what they could do. They didn’t pay me, and I didn’t pay them. We were both just investing time. I thought about what they needed to know, gave them some basic instructions, and sent them home with a project and instructions to reach out to me if they got stuck before we met again.

The experiment was far from perfect. But the biggest problem I faced was not the half-baked curriculum. These students were both headed to college without the thought that being a software developer was in their future. They weren’t motivated to learn outside a classroom, and they didn’t see the reward of struggling through to complete the project. They’d get stuck and neither work through it nor contact me to help them over the hurdle. Instead, they would just show up for our next group session expecting me to show them how to take the next step. They had been successful inside a classroom and saw more success inside the classroom as their next steps in life. They looked at our meetings as “the next class” rather than an opportunity to get over hurdles.

We aborted the experiment before the summer was over and had a debrief. They admitted they lacked motivation and were comfortable with being spoon-fed facts and solutions when given a challenge to overcome, rather than some basic instructions and assurance they were pointed in the right direction.

I was familiar with some homeschooled youth that I had met and wondered if they were any different. It seemed that, by the time they were in high school, many of them were teaching themselves in many subjects and doing “real things” outside of academic learning at a level I hadn’t seen in most teenagers whose idea of learning was mostly restricted to a classroom setting. (NOTE: This was 1997, when homeschoolers were harder to come by and had very dedicated parents who were pioneers of sorts). Through providence, I found a homeschooled young man - Nathaniel Talbott - who was self-taught in the mechanics of programming and had worked with people in multiple contexts outside a classroom. He recognized he was far from an accomplished software developer and wanted to “apprentice” under an experienced developer. He was much less expensive than a college graduate, so the risk/reward seemed to be in line for the next experiment.

My goal was to both get help in my business and to have him be better off in 4 years than he would have been had he gone to college. I tried a modified version of the previous experiment… give him a project, give him a little instruction on what I thought he might need to know, and have him ask when he got stuck. It worked wonderfully. Within a few months, I brought him onto a client project with me.

Within the first year, a client recognized that he was contributing significantly more than their own junior developers with 1-2 years of experience beyond their college degrees. So, I decided to take on more apprentices over the next few years, and the process repeated. 

I was pointed to a book about Situated Learning: Legitimate Peripheral Participation. This was an academic summary of “learning by observing and repeating what the experts do.” Their examples were not in the computer world we live in today, but they gave me a few insights and things to reflect upon from my own experience.

Eventually, in 2011, after reflecting on how I guided each of our apprentices and what they had to learn before safely putting them on client projects, and what they could only really learn on real client projects, I created the Software Craftsmanship Academy. Since then, every 18-24 months, we’ve taken on 2-5 aspiring software developers at a time. 

We’ve recently just wrapped up the 3rd “immersion” section of our 8th cohort - 9th if you count our modified version that took place over two summers with high schoolers. It has been a significant investment over the years, and we are convinced that the payback is worth it. A few years ago, I wrote an article titled “Ready to Farm for Software Talent?” that summarized the benefits we have seen from growing our own talent. We have found that we can nurture those that understand the basics of programming and have the desire to learn into solid developers in 12-24 months. 

I am convinced that people who are experts in their fields and want to continue to have an evergreen business should consider building their own environment for Ultralearning rather than relying on academia. 

Scott Young developed the concept of Ultralearning over years of observation and trial and error. The Craftsmanship Academy developed similarly, observation and experimentation with students who wanted to learn to develop software until we found a system that worked. I’ve been pleased to recognize that we have applied many of the principles outlined and the results espoused in Ultralearning. Scott Young gave us a vocabulary to describe the principles that we have seen in action over the years. We’re continuing to reflect further on how we can continue to improve based on thoughts generated by the book. 

We are not the only ones who have discovered that this type of apprenticeship works, Polyface Farms has a similar program to train farmers. They have a 5-month intensive and take on some candidates after that to stay for a year. Programs like theirs, or the Craftsmanship Academy, are few and far between, but the experts who have developed an Ultralearning environment, often by trial and error, find success in the subject they teach. Whether it is a high-tech field or a career as old as civilization, look for those types of programs, whatever you are trying to learn.  

Summary

Academia struggles with achieving transfer of their material. Transfer is the ability to apply what you’ve learned to new contexts, which is difficult when your knowledge about a subject is limited—like when you are learning something new. A better approach is just-in-time learning from experts—giving students the information they need in the moment they need it.

At RoleModel Software, we developed a program called the Craftsmanship Academy for aspiring software developers. After reading Scott Young’s book Ultralearning, I realized he gave us a vocabulary for the ideas that have been succeeding for many years in the Craftsmanship Academy. Through a process of trial and error, we created an environment for Ultralearning software development. 

In part two of this series, we’ll begin to discuss how we’ve created a successful environment for Ultralearning software development in the Craftsmanship Academy.

Check out Part Three: How Directness Reduces the Need for Drilling and Increases Retrieval and Retention, and Part Four: Feedback in the Context of Directness.

When considering if it’s time to hand over the reins, you need to examine yourself and where you are in life. Ken and Reed discuss how to keep your values and the company’s culture as you make that transition. Watch below:

Identifying Key Contributors

People define success differently; for some, it’s the state of their bank account; for others, it may be their personal growth. Entrepreneurs experience highs and lows that others do not face. They also have to face self-introspection, considering their skillset and knowing who they need to be inside an organization to maximize its value. 

Understanding your skill set helps identify what strengths you have running your business and what areas you might need to work on or have someone else take on. Entrepreneurs may struggle with not being able to be everything for their company or not being able to do everything as the company grows.

Knowing your weaknesses doesn’t mean you can’t be effective in the organization; it means you learn where you are most effective. Sometimes, the most helpful thing for an organization is to give away the roles you don’t have the skills to manage effectively.

Whatever the reason, you may need to give away some of the responsibilities in the company. Early on, handing over the reins may be delegating responsibility; Ken and Reed use the example of marketing. Eventually, you may be handing over more than that. 

Enthusiasm Versus Teachability

“Hire for attitude, not skillset. Skills can be learned—attitude seems to be DNA.”

Ken and Reed agree that there needs to be a balance between enthusiasm and teachability. 

People who are enthusiastic but not teachable often turn out to be Prima Donnas; people who are teachable but unenthusiastic, you may end up teaching them for longer than you want to. Finding someone with a balance is ideal. 

Trust and Values Alignment

Reed describes taking on a partner as starting a long-term relationship: you may have differences, but you’ve got to be able to trust each other—and you need to be aligned on your core values. You can always resolve issues if you trust each other and have similar values. Whoever you choose, you need to have confidence in them to fill in the gaps in the business. 

“Entrepreneurship isn’t necessarily about “How big can I grow my company? Can I turn it into the next Facebook?” Or whatever your favorite entrepreneurial success story is. We’re investing in people, and if you end up with stocks and bonds and a little bit of money in the bank later, that’s fine. But investing in people is way more important to me.”

In case you missed it, check out Ken and Reed's other conversations, Episode 1: Starting a Business, and Episode 2: Scaling a Business.

In the second episode of our Entrepreneur Workshop series, Ken Auer and Reed Philips discuss scaling a business. Check out their conversation below: 

How Do You Scale?

Growing a business is challenging, and as you grow, more people may tell you what would be best for the company. Smaller companies can change things up frequently. As you grow, that gets harder to do. As you are scaling your business, it is important to focus on what you do best and stick to that. Reed recalled, "The more I took away things, the more I could focus, the more successful we were.”

Creating Guardrails and Metrics

When Ken started RoleModel Software, he was advised to pick four metrics for the company—and only one of them was allowed to be about money. Some of the metrics Ken discussed were the amount of time that he spent away from home and the kind of work he wanted to do. 

“That other metric [time away from home] is more of having a healthy balance, and how to measure that, I’ve found over the years that’s changed.” 

Building a Team

Entrepreneurs face the unique situation of needing to be experts in self-evaluation for the company's sake. Reed recalls that he struggled with his own capabilities; he found that the best way to manage it was to surround himself with people who helped sure up his shortcomings and gave him feedback about how he could grow for the sake of the organization. These people should help you understand:

• Who you are
• Which of your skills should you amplify
• Which of your skills should you delegate
• And help you challenge your assumptions or clarify your assumptions about the business
• For Reed, the question he asked himself was: How do I either get coaching to help me grow, or how do I find a person to come in and fill that role that the company needs?

Check out Ken and Reed’s conversation about handing over the reins in episode 3 of Entrepreneur Workshop. 

In case you missed it, check out Ken and Reed’s conversation about starting a business in episode 1 of Entrepreneur Workshop.

In the first episode of our Entrepreneur Workshop series, Ken Auer of RoleModel Software and Reed Philips of Knowledge Systems discuss starting a business. Watch below:

Why Did You Start Your Business?

Reed saw issues he thought people would be interested in and tried to fill that space—Knowledge Systems was created because there were people interested in new technology but no place to learn about it. So Reed saw an opportunity and recruited some “really smart people” to help him and others navigate this new space. 

How Did You Get Going?

Knowledge Systems started with government contracts and projects that would generate some cash flow. Then Reed focused on getting people to join his team. 

Ken and Reed both spoke about having a service mindset. Reed says he loved it when customers came to them with an issue, and they would gather the team to solve the problem—bringing joy to the customer and a sense of satisfaction for themselves.

Focusing on People

“People are at the core of any enterprise from my perspective.” 

Ken summed up Reed’s hiring philosophy as:

1. Find good people
2. Take good care of them
3. They’ll do great things for you

Find a group of people that you enjoy being around, people whose judgment you trust. Then let your team move with the customer’s needs, finding a way to fill the need in the market. 

“I think I began enjoying more of watching the people grow more than the business.”

Once you’ve assembled your people, you can focus on what you want to accomplish as a company—something the team enjoys and excels at, where they can serve their customers and take care of each other.

Check out Ken and Reed’s conversation about scaling a business in episode 2 of Entrepreneur Workshop.

Watch now:

“I know what RoleModel software is going to be. We’re going to be the first extreme programming software studio.”- Ken Auer

Ken Auer had an idea 25 years ago. Fast forward to today, RoleModel Software has over thirty team members, has worked on hundreds of successful projects, and kept their goal of serving their customers and delivering sustainable software.

“They’re good at what they do; they make good software”- Duff O’Melia

Our continued success is due in no small part to our collaborative approach to developing software. RoleModel partners with your company to learn your business inside and out. This deep understanding of your mission and values helps us craft software that will enhance your business, letting you focus on serving your customers. 

One way RoleModel embodies the idea of collaboration is that each project is led by a Craftsman—a software expert, leader, and business consultant, all rolled into one. Throughout the development process, our Craftsmen stay in close communication with our partners through standups, meetings, and check-ins where you will be able to see your new working software with new changes almost daily. 

But RoleModel is more than high-quality software: RoleModel has a mission of serving the community and providing an edifying work environment for its employees. 

“It’s been wonderful to see him form the company, to see in many ways how his belief system and what he cares for and the people around him, how he’s been able to encapsulate that in an organization. That is, being able to replicate those values into the community and into the technical community as well.” - Reed Philips

One way that we build community is through our three core values: character, collaboration, and craftsmanship.

• Character: We seek to model the perfect model of character—Jesus Christ. (Philippians 2)
• Collaboration: We deliver superior results as a highly collaborative team. We cultivate personal and professional growth by working together. (Ecclesiastes 4:9-10)
• Craftsmanship: We build exceptional products tailored to our client's needs. (Proverbs 22:29)

Our mission is to glorify God through our work and our interactions with our colleagues. We do this by living out our core values in our work every day. Adam Williams sums it up best:

“As the scriptures say, ‘you see someone who is good in their work, they will stand before kings.’ I really believe that, and I learned that through this relationship with RoleModel Software and with Ken.” - Adam Williams

To all our clients, employees, and partners, thank you for an amazing 25 years! We’re looking forward to the next 25 years!

Watch the video:

Tim answers the questions:

1. What does collaborative decision making mean at RoleModel? 

2. How does collaboration lead to confidence in a project? 

3. What's a real world example of how RoleModel's approach to project leadership helped insure a project's success? 

Not only does RoleModel have an exceptional development team, but each member is also trained on how to help our partners navigate difficult decisions with their technology landscape, and come up with a plan and vision that leads to success and a sustainable software asset. 

Reach out with any questions you have about technology or custom software development, and we would love to help you find answers!  

In the seventh episode of our video series 3 Questions in 3 Minutes (or 3Q3M), RoleModel Software’s marketing director, Jamey Meeker, and RoleModel’s Software Craftsman Gary Passero discuss why business consultation is so important to our process at RoleModel. Join Gary and Jamey as they answer three questions that will give you an inside look at how we prioritize consultation and why it makes a difference on a project. From our early conversations, we work with you to nail down your goals and identify your opportunities with technology, and continue to focus on your value throughout the development process.

If you have questions about how custom software could help your business, schedule a time to talk with us today! We can help you figure out what steps to take next. 

Watch now:

Join John and Jamey as they answer three questions that will help you understand more about how RoleModel operates and how we are dedicated to high-quality craftsmanship in every aspect of our business.

What is the difference between a developer and a Craftsman?

A Craftsman is more than a developer; it is more than a team lead. 

It's about more than just: 

• experience 
• expert-level technical skills 
• leadership
• ability to manage a project 

In addition to each of these, Craftsmen are expected to be true business consultants. That means that RoleModel Software Craftsmen have the ability to:

• connect with a client to discover how software will meet their needs
• validate the client's beliefs about their customers and help them establish vision
• understand the client's business and advocate on their behalf.

In short, being a craftsman means delivering a whole package of skills to manage a project and serve the customer in multiple dimensions.

How important is collaboration in custom software?

Software development, at its core, has a lot of unknowns. Craftsmen start with a thesis about what needs to be solved and how, but through daily standups and on-demand consultations, they're able to pin down the latest understandings and expectations with up-to-the-moment accuracy. 

As the client is learning more about their business and their workflow, so are we - RoleModel Craftsmen help the client address concerns that they may not have even thought of yet. 

With years of experience creating high-value software, a Craftsman knows how to ask the right questions to get the whole picture of what the project should accomplish at its end.

Can give a real-world example of learning a client's business?

John's favorite example of learning a client's business came on a project for a high-end dental lab. 

The client had developed an extremely complicated system for designing surgical guides for reconstructive dental surgery - ten major steps, with dozens of substeps for each.

John chuckles as he remembers being handed a full binder with the company's standard operating procedures for their CAD technicians. 

John and his team jumped in and started studying that process to understand where the client's pain points were and how the steps worked together to achieve the final product. 

As the project commenced and the first meeting rolled around, John pointed to the moment when an open-ended question was asked and he was quicker to the answer than the client's own team members.

"(That moment) increased their confidence that we were hearing them; that we understood what they were working through, and ultimately would be able to deliver the solution that we did in fact deliver."

Watch the full episode here!

Check out the last episode of 3Q3M where CPO Ken Auer breaks down what design price quote (DPQ) software is, why it is useful and how we implement it for our clients' success.

Unfortunately, “automation” and “technology” usually don’t give an impression of being affordable or low-risk.

But what if it could be?

RoleModel Software DPQ (design price quote) and Custom SaaS offerings are built for businesses like yours. We understand you need the expensive capabilities of CAD or CPQ (configure price quote) software and more, but you don’t have the resources to drop over six figures for the right solution. (you probably also want something a little simpler; we don’t blame you)

By integrating one of these offerings into your business workflow, you’re combining your industry expertise with our software expertise to create a customized solution designed to improve your entire business process and help you accomplish more.

LightningCAD, the framework that our DPQ and Custom SaaS offerings are built on, was the result of several million dollars in development costs and years of work. We’d certainly like to see a return on our investment, but not at the expense of your success. We understand how important software like this can be for small to medium-sized businesses who simply could not afford to pay anywhere near that kind of money upfront.

Our goal is for a partnership to be a win for both of us,and that is certainly achievable.

Here’s how it works.

We’re calling it our Performance Payment Plan. Basically, this means that you agree to pay us a percentage of the additional income that you make from using the software as long as it is providing value.

Since the percentage you pay is based on the volume you’re doing, it can be tempting to do the math and look at the resulting number as the price tag for the software. But it’s better to think about it this way:

“You are getting a world-class software partner dedicated to increasing your profits in return for a fraction of those increased profits.”

Integrating DPQ or Custom SaaS into your workflow will:

Increase efficiency on many fronts

It’s all about improving your process and building on it. Having RoleModel DPQ or Custom SaaS as a part of your process will bring increased efficiency to your existing workflow. Whether you’re currently using CAD to do all your design work or if you’re stuck with a pencil and paper, think about what a difference it would make to have your design, sales, and estimating all accomplished within one tool simultaneously. That’s what we’re offering.

Increase overall sales

With the increased efficiency, comes the capacity to handle new business. Your sales team will be able to design and make revisions more quickly, which will cut down on delivery time and allow them to get to more customers. Since you can integrate Custom SaaS and DPQ into your website, it creates a whole new sales channel. Customers can design for themselves within the platform that will keep them from making mistakes so that whoever receives the quote can quickly approve it and move on. Visibility and shareability are also high. Users can experience impressive visual renderings of their products and share them with others, creating the opportunity for referrals and repeat customers.

Elevate your public perception and professionalism

The process improvement that RoleModel DPQ and Custom SaaS bring to the table will not only bring internal success, but will make you look better with customers as well. Our platform can be set up in a way that allows for customers to interact directly as well. Having powerful software adds a professional and sophisticated touch to your company’s image.

Even if you hit a dry spell where business is slow, you won’t be making monthly subscription payments without any return. You’re paying us a percentage of the income from using the designer. So when your income is lower, so is the amount you’ll be paying. You don’t have to worry that paying for the software will drain your coffers.

This also means that if you ever decide that the tool just is not working for you, stop using it, and you’ll stop paying. There’s no binding contract. We fully expect our CustomSaaS products to create real value for you, and we’ll do our best to help you overcome any obstacles you may encounter as you use them. But if you decide it’s not for you, you’re free to move on.

Another aspect of the performance payment plan is that it mitigates your risk. Aside from an earnest deposit fee to get started, you’re not dropping sums of money upfront. Instead, you pay as you experience the software increasing your profitability. Even when you do start paying us, the software will bring you a lot more added profit than you’ll end up paying us.

As you start out with your custom solution, the percentage of revenue we receive will most likely start on the higher end of the scale (around 5%). But as you do more business with your custom solution, that percentage will gradually go down. RoleModel Software assumes the bulk of the risk early on in the partnership so that you can have confidence in your solution and focus on your business.

As you start out with your custom solution, the percentage of revenue we receive will most likely start on the higher end of the scale (around 5%). But as you do more business with your custom solution, that percentage will gradually go down. RoleModel Software assumes the bulk of the risk early on in the partnership so that you can have confidence in your solution and focus on your business.

As you start out with your custom solution, the percentage of revenue we receive will most likely start on the higher end of the scale (around 5%). But as you do more business with your custom solution, that percentage will gradually go down. RoleModel Software assumes the bulk of the risk early on in the partnership so that you can have confidence in your solution and focus on your business.

Good software isn’t cheap; but at RoleModel Software, we want to do more than just make a profit. The goal of DPQ/Custom SaaS paired with a Performance Payment Plan is to help businesses who need software by working within your cash flow constraints to produce a powerful customized solution while reducing your overall risk as much as possible.

In the fifth episode of our video series 3 Questions in 3 Minutes (or 3Q3M), RoleModel Software's marketing director, Jamey Meeker, and RoleModel's CPO Ken Auer break down what design price quote (DPQ) software is, why it is useful and how we implement it for our clients' success.

Join Ken and Jamey as they answer these questions and provide insight to help you understand the strengths of DPQ software and if it's right for you.

What is DPQ?

Many people are familiar with configure price quote (CPQ) systems. They're used commonly in many different applications. A couple of examples would be: 

• Ordering a t-shirt - selecting color, style, size and more
• Buying a tractor - selecting attachments, trim, engine and more

Based on configurations like these, a customer is able to get a quote with a price based on the modifications they've selected.

DPQ is the same idea in general, but the difference is that you're designing, not just configuring. From decks to docks to railings (we've worked with all of these), a DPQ system can be ideal when you're working with anything that has geometric variability. It allows you to design powerfully while staying within the boundaries of your system constraints.

Why is DPQ important?

Ken replies "The industry demands it!" RoleModel Software has received countless calls over the years from people who have a system they are trying to sell and want to scale while doing that. But, they're running into problems with their sales team not getting the correct data from sloppy, inaccurate design, which then requires them to go back and do rework.

The DPQ solution is a constrained design tool that knows your product engineering rules, with only a fraction of CAD's complexity. The result is a design that is exactly what the customer wants and contains all the information you need to know how to build it. The pricing and quoting is then easily calculated based on accurate calculations.

How does DPQ work?

With years of experience in custom software and a well-established base framework called LightningCAD, RoleModel Software has been able to put together a platform that understands the workflow of a DPQ system intrinsically, and all that we have to do is build in your engineering constraints to personalize your system. 

It's changed the game for many of our clients. Tasks that used to take days and were error-prone now can take mere minutes while being error-free. 

You can deploy your DPQ system externally and allow customers to design on their own, with the peace of mind that their designs will fall into your constraints. With very little training, your team is able to harness the diversity of your product lines with a tool that will help them design and estimate faster and more accurately.

Watch the full episode here!

Check out the last episode of 3Q3M where Caleb Woods answers three questions a client may ask before starting a custom software project and stay tuned for more episodes in the coming days!

In the fourth episode of our video series 3 Questions in 3 Minutes (or 3Q3M), RoleModel Software's marketing director, Jamey Meeker, and RoleModel's CEO Caleb Woods discuss how you can know if you're ready for custom software. Sometimes, business owners don't even know what they're supposed to know about their project before getting started.

Join Caleb and Jamey as they answer three questions that will help business persons define their projects and give them the confidence to move forward.

Do I need to know exactly what I want my software to be?

It's understandable that potential custom software clients may think they need to know exactly what they want their software to be. But the reality is that you're going to miss important pieces that you may not have thought of at the beginning. You'll also learn a lot about your needs as the project moves along.

The focus is on your business expertise. That's what we're helping you translate into your software through our own expertise.

The idea is not "Everything needs to look just like this", but instead, think of it as a point on the horizon that we're continually working towards. The journey is going to be a process since you're not just buying a set of features like you would with an off-the-shelf product. You're buying a team and a process to reach the final product.

Focus on the feedback and the process, not the features.

What DO I need to have defined before I get started?

With RoleModel's custom software projects, we like to "start and steer". In order to do that and still have some guiding principles without having the whole project defined, we focus on the business.

No software is created in a vacuum.

We're solving a problem in your business or we're giving you an opportunity to scale.

As long as your business can provide the goals, that point on the horizon, there will be constraints that will guide the project and creativity will be unleashed. Our clients can hold us accountable and vice versa.

It's also important to know if there are certain integrations or other technical aspects that you consider essential to your long-term idea of success with the project. We don't need to do everything all at once, but with those noted, we'll keep on track towards what you need and want.

Do I have the skills to communicate with a technical team?

If you can't translate your business expertise into technical terms then that's a problem. That's where RoleModel Software Craftsmen come into play.

They're experienced in software building and project management from a technical perspective, but they also understand consulting in a business domain.

They're experienced with leading a team and pushing the development of the software projects towards that long-term goal.

RoleModel Software Craftsman speak both languages.

They collaborate with the business owner to figure out the business goals to then reflect that back in the form of real, useful software.

"Ultimately, what we're trying to do is software-enabled business improvement," says Woods. We keep our eye out for ways we can build improvement into your software and then use quality feedback loops to effectively steer the project and guide us towards the next point to focus on.

Watch the full episode here!

Check out the last episode of 3Q3M where Roy Miller answers three questions that everyone wants to know before they get customer software and stay tuned for more episodes in the coming days!

Caleb Woods, from RoleModel Software joins Dr. Tolu Adeleye to discuss unique angles of what it takes to shift from being a technical role in a software company to a key leadership role that involves amongst other things, growing a team of software engineers. Listen in to hear about Caleb’s take on how developing software cannot be done in a vacuum; implying the vital need to bring into play factors such as business analysis and more. Get to learn how Caleb fortifies his leadership positioning through small daily practices that add up on the long run.

How an agile approach in software development helps grow companies. Guest: Caleb Woods

Caleb Woods is the CTO – Software Craftsman at RoleModel Software.

RoleModel Software partners with its clients to understand their unique business context and create custom software that turns their “secret sauce” into an enhanced competitive edge.

I’ve been helping people put expertise into software for the better part of 40 years. I had a course in “Expert Systems” in college and had a short love affair with the LISP programming language — the earliest favored program for AI research. I started my full-time professional career in the mid-80s at the beginning of the “AI craze” and joined a company named “Knowledge Systems” in 1988… just before the “AI Winter” when interest in funding AI research dried up due to lack of delivery of promised results.

But for the last decade or so, I’ve heard more and more people claiming or believing that AI is going to take over the world, and if you don’t get on the bandwagon, you’ll be replaced whether you are a business owner or a programmer or “data scientist.” Microsoft, IBM and other large companies tout how their AI is changing the world.

No doubt, there have been many advances in technologies that would certainly be considered under the AI umbrella. There are some things that many of us use almost everyday that have benefitted from some of those advances. As I type this, I benefit from technology that anticipates what words I might want to type next, and I hope cool stuff like that keeps coming.

But the reality is that the vast majority of software to help us improve what we do in the world today and in the near future need expertise that is not inherent or derived by a computer. My company builds software systems that are game changers for many businesses and their customers. They are — generally speaking — expert systems in that they provide the expertise that came from human experts and make them available through a computer system to those with less expertise. We rarely find any technology that would universally be called “AI” that is capable of providing any significant contribution — though we often would like it to.

One thing that is essential to most “AI” and the building of any software is a feedback loop and the ability to know what to do with that feedback.
I thought it might be worth a shot at talking about how “software”, “computer systems” and “experts” come together and cut through some of the AI hype.

Computers Are Not Intelligent, They Are Just Fast

Although there are those who think there may come a time when machines think, they certainly don’t do it today. They do what someone programs them to do through embedded hardware or software logic, and they do it really fast… and they have gotten faster and faster. Given structured data and an algorithm, they can sort through data very quickly. With a different algorithm, they can turn unstructured data into structured data very quickly. Given enough data in a given context, software systems can use statistics to predict things with a high degree of probability, much faster than a human can gather and process the data to get the same result.

But, the software system doesn’t know whether they predicted correctly or not. Someone who “knows” has to validate the system’s answers or decide that it is trustworthy enough to be useful. In a narrow enough problem with uncertainty as to what the “best answer” is, the software may come up with a better answer than any human can validate or not… How can we know? Do you think there is some expert at Google who can validate that the top hit for each particular search is actually the “best answer”?

Computers Are Not Experts, They Are Just Consistent

In 1980, the Dreyfus brothers created a model for skill acquisition. Although it has its critics, it rings true for most humans who’ve been around awhile and have observed the difference between novices in a skill set and the most advanced experts, and the people in between. These same people criticized AI in its early days, and the debate has gone back and forth.

Aim a software system at a set of data using a set of assumptions and it will consistently come up with the same answers. It can even be set up to question its assumptions given new observations and reassess its answers. Sounds like an expert to some extent.

There are times when this works great. It works great for Google because they can follow sets of rules to get people to popular places on the internet and make Google a lot of money on ads. But who hasn’t searched for something on the internet via Google (or any search engine) and found the results wanting? Why? There is not an intelligent dialog going on between an expert and someone seeking the expertise to get an answer.

Computers Don’t Learn, They Process Data

Well, OK, in one sense they CAN learn. But they have to be told to collect data. They have to have someone produce the data in a way they can access. They have to be told what to do with that data.
Even if computers are set up to “learn” from that data, it is probably for a specific goal. For example, Google scans the internet for lots of words (and images, and other data) with the assumption that people are going to search for the information that those words “mean”. Google has lots of data and has done a lot of processing.

Based on Google’s success, would anyone like a software system (or series of systems) to take that data and create an innovative vehicle to get people from a point in New York City to Sydney, Australia without a human involved? I’m not talking about a Map or Flight plan, I am talking about a vehicle that will safely get you there. If you think so, will you be the first one to volunteer to sit in its seat?
There may be valuable information that has been culled from which humans can learn to help create such a vehicle, and there are robots that can help build it. But we are far from being able to have a computer or series of computers accomplish this goal without humans.

We are certainly not against “machine learning” but the reality is that computers need to be trained, too. And the cost of training can be VERY high, often needing hundreds of thousands of data sets, many humans to help validate the patterns found (which also brings human error into play), and further quality control measures to accomplish even the smallest task.

“Pattern recognition” is something computers can theoretically do very fast. But they aren’t very good at reducing noise like humans are. For example, we humans can look at a landscape architect’s plans and recognize a pattern that they may have used for a shrub, and count them up. If there are 197 of those same shrubs, we are prone to miss a couple or get distracted when counting. However, the subtle variations in the unstructured data require massive amounts of training data for machine learning (ML) models to begin to recognize and separate the noise.

We recently gave a series of such drawings to a machine learning program from a top tech company, pointed it to some of the patterns that we told it was a shrub, and it couldn’t count any of them on the drawings. We encountered better results as we supplied different “control” files showing the assumptions of the learning program may be non-intuitive and tightly constrained. There were other lines on the drawing that threw it off, in addition to an obviously less than perfect algorithm. We have no doubt that given enough data, the correct set of assumptions, control data, and more we could have eventually had much more success. Then we’d have to do it again for each of various other types of shrubs, trees, flowers, etc. Of course, when should a slight variation of a pattern point to the same type of shrub/tree and when should it identify a new shrub/tree pattern. Without a controlled set of patterns — and making sure all architects who might supply our drawings comply with those patterns — the utility of the system we “trained” could have very limited value.

Where Probability Matters, Computers Might Help

Because computers are fast and can process lots of data, they can help pretty quickly deduce some things with some level of precision. When you type in “expert systems” in Google you will get some answers that are “probably” relevant. They have looked for words and patterns of words in a lot of content all over the internet, and then looked at the kind of things people click on when they put in the same words, as well as a lot of data. But type in something more specific, like “parody of bohemian rhapsody related to the Kansas City Chiefs 1993 Joe Montana” and you won’t get anything helpful at all. (I’ve been looking for years for this parody I heard in 1993 on a radio station in Kansas City). Often, the more specific and obscure the search, the lesser chance you’ll find a satisfactory result.

Where Accuracy Matters, Computers Might Help

Computers are consistent or they don’t work at all. They do math pretty well. (NOTE: rounding errors have existed in computers for floating point math forever and it seems to be more common in JavaScript). So, assuming the computer program has reliable rules for figuring something out, given accurate inputs, you will get accurate output. Of course, if the system is missing relevant rules, you may still get output.

An answer produced by a computer isn’t inherently more accurate than an answer produced by a human… especially an expert human.

Where Expertise Matters, Find an Expert

Today, I talked to an expert in alternative energy, and an expert in designing cooling towers. They both have used many computer systems and have found them wanting. They are paid a lot of money for their particular expertise. The latter uses industry leading computer-aided design (CAD) software, and they were speaking to me because the software system that they are using doesn’t understand that they are designing a cooling tower. Is the software helpful to the designer? Absolutely. But it can’t even begin the process of designing a cooling tower or find flawed assumptions that could be disastrous without the expert human to guide it.

The expert can design the cooling tower without the software, just not as fast. Without an expert user, the CAD program wouldn’t know where to start if you told it that you needed a cooling tower and gave it the sketchy input the designer gets every time he’s asked to design one. The software doesn’t know what questions to ask to get the missing or inaccurate information, how to check the validity of the information, where to begin to create the skeleton of the design, what special implications that design will have on its surroundings, etc.

… and Leverage Their Expertise

Expertise is hard earned. One way to leverage the knowledge of an expert is to hire them: either as an employee or a consultant. But reproducing that knowledge the expert possesses and expertly wields is difficult. Many experts turned business owners understand this at a very deep level.

It took me 8 years to train up a very talented individual to replace me in my role of CEO of a custom software development company with very intentional and concentrated time. Imparting my expertise to him took a lot of time, intentional input, feedback loops, and situated learning among many other factors. Along the way, there were things we discussed and I slowly turned over.

But there are other ways to leverage expertise. For example, one can find the tasks that have become well-understood by the expert and use software to make that expert unnecessary to perform those tasks. Many experts learn to do this themselves as a reflective practitioner who is using continuous improvement and automating the tasks that — to them — have become mundane.

Some things I had learned I put into algorithms in spreadsheets. They started simple, became more complex, then were simplified after a lot of discussion and testing. Some of them were eventually put into software tools. We now have more tools to monitor, measure, and summarize many of the things I had learned were important to maintain a healthy business and culture. We continued to learn and refine those things. We now have Key Performance Indicators (KPIs) that are monitored weekly and reflect the health of a company that has significantly grown. Instead of the hours each week I used to spend putting some things into a spreadsheet and intuitively trying to identify, we now have access to more accurate health signals at a glance with very little human intervention.

Extracting and Automating Expertise is an Expert Skill and Computers Don’t Have It

I’ve been involved in the creation of software for the better part of 40 years. When I went to college to learn about it, I was usually provided with specifications that gave me just about all the information I needed to build the software. Every once in a while, I was given creative freedom to make up some information. For example, I was supposed to make an airline reservation system and could guess at what information I needed… no airline required.

When I started my professional career, I was sometimes given detailed specifications, and sometimes given some ideas to explore. It wasn’t until I got into the “consulting” world 33 years ago that I started to learn how to extract information from people. Most had some idea about how software could make their jobs more efficient and effective or provide a service that would improve the lives of others. Most of them didn’t have clear “specifications”. They may not even have had clear “goals”.

The Agile Manifesto was written by some expert software developers. The signers had many years of experience building software for others. There have certainly been excellent practices and process improvements that have followed this inspirational document. But many have raised the “agile” banner and ended up with subpar or even dysfunctional results. I believe this is because the “preamble” of the agile manifesto is often overlooked.

“We are uncovering better ways of developing software by doing it and helping others do it…”

There is expertise necessary to help an expert (or rising expert) turn their goals into working software that encapsulates expertise. It doesn’t just happen by hiring “rockstar coders”. It doesn’t just happen by following a set of rules or practices. It doesn’t happen magically through machine learning.

We have built many systems which encapsulate expertise for our clients, and we are not the only ones that have done so. We leverage technologies like “rules engines”, “APIs to other systems that automate some expertise”, and occasionally some machine learning amongst a growing set of accessible technologies. But most people who need software to improve what they do need expertise of others expertly extracted and turned into a system — leveraging computers — to do things more efficiently or make it more available to others.

Right now, “AI” has seen a resurgence as a buzzword and many tech companies claim that their AI technology is changing the world. In the mid-late 80s it was also a hot buzzword. My previous employer — founded in the late 80s — even named itself Knowledge Systems Corporation. One of the things we did in the 80s was to examine various “Expert System Tools” and apply them to various types of systems. We found that there was only a small portion of those systems that really benefited from the “AI” technology, and the rest just needed a good programming language and good programmers to analyze, design, and build the system.

The same is true today. Yes, the technology has moved forward from some of the naive approaches to produce “artificial intelligence” of the 80s. The horsepower of our computers and the access to information has grown by leaps and bounds. But one thing that remains the same is that the vast majority of software that is needed requires humans — very skilled humans who have gained hard earned expertise — to both extract expert knowledge and analyze, design, and build a system that is an expert at something others would like to leverage.

You can’t wish that kind of software into existence. Humans aren’t just a bunch of data that you can throw processors at to reproduce. The humans are still the experts. We are in the business of amplifying hard-earned expertise. Computers and the technology developed on top of them are just a set of tools we can use to help us do that.

We work in a tight feedback loop with an expert to extract their knowledge a bit at a time and produce a “walking skeleton” of the system they imagine. We continue to extract, reflect, and refine with the expert. As soon as possible, we put it into the hands of those who can benefit from the captured expertise to bring them into the feedback loop.

And that’s how we produce an expert system.

On this episode our CEO, Caleb Woods, chats with the Cybrary Podcast. We discuss the work RoleModel does and specifically highlight our Craftsmanship Academy, a way for those new to the engineering space to apply their skills and learn on the job skills through hands on development training and real world projects.

You can learn more about the Craftsmanship Academy by going https://www.craftsmanshipacademy.com/

In the third episode of our video series 3 Questions in 3 Minutes (or 3Q3M), RoleModel Software’s marketing director, Jamey Meeker, sits down with RoleModel’s Chief Operations Officer Roy Miller to discuss what everyone wants to know before they get custom software. Of course, it doesn’t take long for any conversation around custom software to get very detailed, but before that happens, what are the first things a potential client wants to know?

Join Roy and Jamey as they dig into three questions that everyone looking for custom software wants answered.

What software am I going to get?

A recurring theme throughout the custom software industry is that it is hard to estimate what your software will look like based solely on someone else’s. Roy grants that it may be hard to define exactly what software you’re going to get from the very beginning of the project. But, when you work with RoleModel Software, whatever the final product looks like, it will be high-quality, sustainable software. It will last a very long time and it will grow with your business.
But another and equally valuable aspect of working with RoleModel Software is the collaboration and consulting that is present at every point throughout the process. We study your business, understand your needs for value, and then help you turn that into software that fills those needs. The end result is software that is tailored to you and will meet your current needs, but it is also all yours, which means it will be an investment that continues to pay off over time.

When am I going to get my software?

Roy says that the timeline is highly dependant on the scope of your software project, but the steps for how RoleModel approaches each project are roughly the same, allowing a way to predict how long it will take. We typically start with a small initial investment if you aren’t sure exactly where you want to go. We call this the “Explore” phase. It will usually last 1–3 weeks and by the end, you’ll have real working software (however basic) and a good idea of how many 2-week iterations it will take to get you to your MVP (minimum viable product).
When we actually begin the iterations, you have a much clearer picture of the project direction. Throughout the rest of the iterations, you’ll continue to receive additional working software and your feedback will validate our progress at every turn to ensure the software we produce is what you need.

How much is my software going to cost?

Again, Roy says that the price of the software will depend on your project, but we do make the math a little bit easier. We take the price of your “Explore” phase based on the number of weeks it took and then add the cost of the iterations, which is a flat fee per iteration times the number of iterations.
Another aspect that needs to be considered is the support it takes to keep your software running smoothly once it goes live. Roy says that this number is usually figured as 10–20% of your initial system investment in year 1.
Custom software is an investment, no doubt about it. “We’re not the right fit for everybody”, Roy acknowledges. But, we certainly are happy to talk to you about what software you can get for the budget you have, and if it is a fit, the RoleModel Software team will do what it takes to provide you with transparent, honest expertise as we build your software.

Watch the full episode here!

Check out the last episode of 3Q3M where Ken Auer discusses the difference between custom software and software products and stay tuned for more episodes in the coming days!

Ken Auer is the Founder of Role Model Software in North Carolina in the US.  Since the mid-1980s, Ken’s passion and commitment to software craftsmanship has made him a respected leader in the creation of sustainable software and high-performance teams. He was introduced as "the father of software craftsmanship" at the inaugural Software Craftsmanship North America conference in 2009.

We only see a project as successful when we win together.

In the first episode of our new video series 3 Questions in 3 Minutes (or 3Q3M), RoleModel Software’s marketing director, Jamey Meeker, sat down with incoming CEO Caleb Woods to discuss three common misconceptions regarding custom software. As the new CEO, Caleb plans to continue the legacy of the company that has remained throughout the 20+ years of business by building on the company’s success as an agile organization through sustainable growth. He emphasized our focus on helping customers “amplify their expertise” and ultimately helping them scale their processes and businesses.

Diving into the topic for the video, the first misconception of custom software is that it is “too risky”. Caleb acknowledges that custom software can certainly be risky, but then points out how RoleModel Software looks for every opportunity to mitigate that risk. By creating a “walking skeleton” and getting working software into the hands of real users as quickly as possible, RoleModel works with the customer to make sure that they are getting the right software on a daily basis, not just at the end of the project. The customer knows exactly what they’re getting throughout the entire process, which eliminates a lot of the risk involved.

The second misconception Caleb addresses is that custom software is “too complicated”. He agrees that custom software can be complicated, which is why we focus on the development while you focus on your area of expertise. Our process is set up to allow us to learn your domain so we can reach a point where we’re working together to solve your problems. Because of the high level of collaboration, customers won’t be confused by the features they see. The result will be a tailored solution that you’ve been able to guide from start to finish.

Finally, Caleb addresses the misconception that custom software is just “too expensive”. There may be off-the-shelf software options out there that are cheaper than custom software, but if they’re only covering 80 percent of your needs instead of 100 percent, what are you missing out on in terms of revenue or opportunities? That’s when it would be smart to consider the investment aspect of your solution. This isn’t solved by dumping a bunch of money into visionless software. We start small, providing a return in the form of usable software, which we can then iterate on as the time is right. At RoleModel Software, we want to partner with you and support you along the way. Caleb says “We only see a project as successful when we win together”.

Watch the full video here!

Stay tuned for more episodes of 3Q3M in the coming days!

This week Caleb Woods, CEO and Senior Software Craftsman at RoleModel Software joins the podcast. Caleb and I talk about the role of craftsmanship in developing and maintaining software (or really anything else).

Caleb Woods – RoleModel’s CEO – Caleb is a proven leader with extensive experience evaluating technology trends, leading teams, and implementing best practices. As CEO, Caleb promotes continuous improvement while cultivating a collaborative work environment.

Caleb is a technologist who understands and solves complex business problems. He has a passion for software craftsmanship and producing sustainable software and has become the visionary leader of the next generation of RoleModel Software.

Caleb began his software career as a web developer at an academic coaching company, where he gained experience in infrastructure migrations, team leadership, and business analysis. He’s continued that dedication to technology advancement. At his previous position as Chief Technology Officer for RoleModel, Caleb led the expansion of the company’s technical and design craftsmanship capabilities. That background helps Caleb effectively develop and evaluate RoleModel’s technology landscape. Caleb sets the vision for the company’s strategic full-stack architecture and is an expert at putting together high-performance teams and matching them to clients/projects’ needs.

Caleb also applies the ideas of continuous improvement to his personal life through effective micro habits and is a big believer in intermittent fasting. He also enjoys playing disc golf, cycling, and watching Michigan State football and basketball. He and his wife, Kimberly, have three young kids.

“A little learning is a dangerous thing.”
- Alexander Pope

If you stop learning, you stop growing; you stop getting better. At RoleModel Software, we’re learning every day. In our quest to deliver high-quality, tailored software solutions by closely collaborating with our customers, we see the opportunity to use every situation to get better.

No project is created equal. There will always be something that our developers encounter that is unexpected or unusual. Whether it’s unfamiliar languages, new team members, or a constantly changing project, we like to look at each as a chance to improve.

While we’re crafting customized software solutions for our clients, they’re also helping us get better at what we do.

In other words, continued learning is a big part of RoleModel Software. One of the ways we foster that is by hosting a quarterly internal convention for our team where we take a couple of days to dive into new technologies, frameworks, and ideas, apart from the typical project experience. We call it CCC Days. (Click here to read about the last CCC Days and discover what the “Cs” stand for)

This time around, the experiments looked like this:

Basic Animation Integration

This experiment explored adding richer animations to some of the base styles that we use on projects. Things like:

• Form errors
• Modals
• Page transitions
• Checkboxes and radio inputs
• Links and hover states

The team on this project worked to import an assortment of animations from Animate CSS for easy accessibility to the rest of the company. Check out an example of the implementation for checkboxes below!

Color Theory

One of the areas we’ve been making strides in lately at RoleModel is design/UX. Creating an impressive and dynamic interface throughout our software is important for its usability. This experiment sought to explore implementing Fast’s color theory into our internal CSS starter kit by diving into custom variables, luminance, color scale with semantic names, and more. These concepts were applied by creating a dark mode for Shell Builder, one of our concept SaaS products.

Turbolinks to Turbo

In some of our applications, we use a framework called Turbolinks which is designed to speed up navigation for web applications. Recently, a new framework called Turbo (associated with Hotwire) came out designed to replace Turbolinks. It essentially does what Turbolinks does and more. But it requires an alternative method for implementation. Those on this project looked into what it would take to move from Turbolinks to the newer and more capable Turbo.

Amazon Web Services (AWS) Deployment

We leverage Heroku’s PaaS to simplify the deployment and management of many of our applications. However, there are times when Heroku isn’t the best fit given the project’s needs. We wanted to further explore deploying one of our applications to AWS in a portable way that could be used with multiple cloud providers.

This was an example of a project that didn’t result in a polished final product. AWS is a complicated system, and our developers certainly had their work cut out for them, regardless of what was produced in the end. There would need to be a lot more progress made in this area before it becomes usable, but we still pushed our understanding of AWS ahead a great deal through this experiment.

Financial Reporting + Modeling

Not all of the projects at CCC Days revolve around programming. We want our business model to adapt alongside our technical expertise. We continue to pursue TBS (technology-based service) opportunities, and with growth on that front, our revenue stream changes. The purpose of this project was to plan out the financial management for the future and update projection spreadsheets and models.

Portfolio Presentation + Discovery

An important part of providing useful information for future clients is to organize past work in a compelling way. We know we can do the work, but potential customers want more than to just take our word for it; they want to see examples of what we’ve done. RoleModel Software has over 120 successful projects to date and they cover a lot of different industries and problem domains.

This project was all about analyzing the industries that our software touches and what type of solutions they are (analytics, automation, process scaling, etc). Then, the team tagged RoleModel’s software case studies with the titles they came up with; things like “Manufacturing”, “Healthcare”, and “Agriculture”, among others. They laid out what a possible implementation of a “filter by tag” option would look like on the RoleModel website.

Improve LighningCAD Augmented Reality View

If you read the last CCC Days blog post, you’ll remember we have been doing some experiments with AR and VR in some of our applications. You can read more about our first steps here.

During these CCC Days, we wanted to take our AR abilities to the next level. The developers working on this project cleaned up the experience as a whole and added some key new features.

An example of a new feature would be the addition of anchors. Anchoring essentially helps the software remember where it placed a certain object, even if you walk completely away from the scene and into another room. When you come back, an AR view with anchoring capabilities will place the object in its original spot as soon as it returns to view.

We also experimented with lighting APIs to see how they would affect our models. For instance, if the real-world light source is dimmed, the AR view will compensate for that change and brighten the dock.

Not only that, but we can determine where natural light is coming from and allow that to show through in our model as well.

Curves + Splines in LightningCAD

Sometimes, we may not consider all that it takes for software to render a visible line, let alone a curve. Up to this point, our curves displayed in LightningCAD have not been actual curves, but instead polygons with a high number of vertices to give the appearance of curves. While this method works, it is not as performant or precise as it could be.

An alternative to this approach would be the use of Bezier curves. Bezier curves employ some very complex math to render, but the result is a pure arc that is far more capable of representing curves in real-life applications. Drawing curves are typically quite common in design/drawing tool kits, and this project made great strides to add them to ours.

LightningCAD Playgrounds

In our LightningCAD framework, we provide a robust platform for software solutions that have design aspects involved. However, there’s a lot of complicated code in the background, and it would be helpful to see a visual tool…. well, visualized.

The point of reference was a system called Swift Playgrounds, made for the Swift programming language. Swift Playgrounds lets one see the effects of their code as they create it, providing an interactive and fun environment for learning complex concepts.

The goal of this project was to create something similar, but for LightningCAD. We recognized that the “finished” form would take more time than we could construct over the course of two days. The developers on this project vetted several different software options to use as a starting point, and once they found one (Jupyter Notebook), they spent their time figuring out how to import geometry and drawing capabilities from LightningCAD and then how to get it to render their code inputs. We are looking forward to building on the progress of this experiment in the days to come.

Each group was hard at work over the 2+ days, with varying levels of progress. The point is not to have a polished, fully functional project at the end of CCC Days, though obviously, we’re not opposed to that.
The point is to try something new; to try something that could be useful. Whether the result confirms that this idea is worth pursuing or that is not, it doesn’t matter. The purpose of CCC Days is to pursue possibilities.

These projects never result in failure because when you’re always trying to get better, a setback is just a setup for a comeback.

How would it feel to work for eight years in a job you love, a job you have a passion for, a job you excel in – and to be recognized by the founder of the company as who he wants to put in charge as the CEO?  Do you think there is any pressure there? Oh, while the CEO continues to work at the company!

Well, our guest today has achieved that level of success – and doing it while maintaining his Christian core values and – we should add – the company’s core Christian values as well. Amen!

Caleb Woods grew up in Michigan and started working in a financial consulting firm while still in high school…praise God!  While there, he progressed so fast he soon began customizing CMS plugins and even writing some JavaScript himself. Amen!

He pursued a college degree in Computer Information and Technology through an accelerated program as part of CollegePlus. They were so impressed with his abilities, they offered him a position with their company.

Fast forward a bit and CollegePlus needed help from a software development company and, in the Lord’s plan and timing, Caleb was offered a position with this company, called RoleModel.

After working on a project building a cloud-based storage service for the Agricultural industry and streamlining that process, he was soon put in charge of other projects and provided great insights and initiated some applications that streamlined his company’s operations. For this, he was named the Software Director at RoleModel.  He continued to take on more and more leadership roles as was quickly promoted to Chief Technology Officer.

Then, just a short time ago, Caleb was promoted by the business founder to the role of Chief Executive Officer for RoleModel, a Christian founded custom software company in Holly Springs, NC.

Caleb says the purpose of RoleModel is to “glorify God by applying their craft to serve business innovators and colleagues.” RoleModel is now 20 years old and is a world-class, collaborative software development team with over $5 million of projected revenue and over 30 employees that are all dedicated to delivering the highest quality, custom web and mobile software solutions while cultivating a work environment where community, family, learning and mentoring flourish.  AMEN!

I encourage you to get in touch with Caleb Woods. Reach out to him. Ask him questions. See if he and his staff at RoleModel Software can assist you in developing that missing piece of the puzzle that will propel you to the next level of success. Ask Caleb to come and speak at your conferences. Basically, just get in touch with him today and at least start the conversation.

My guest today is Ken Auer, CEO at Role Model Software. Our conversation focuses on: whether SaaS Founders should outsource their product development.

Join the SaaS & Scotch community: https://bit.ly/saas-scotch

You can learn more about Role Model at: https://www.rolemodelsoftware.com/.

Learn more about my SaaS Strategic Planning Workshop: https://tkkader.com/workshop.

Check out my Youtube channel where I post 3 episodes every week with actionable strategies on growing your SaaS business: https://tkkader.com/youtube

Learn more about my SaaS GTM Coaching Program: https://tkkader.com/gtm

Click to tweet link: https://ctt.ac/1r9tP

See another blog post about offshore development

Ken and I sit down to discuss his background, the journey through software development from the early '80s until now, how his company Rolemodel helps small to mid-sized businesses gain leverage through completed software projects, software and the pandemic, and much more!

Ken Auer’s passion and commitment to software craftsmanship has made him a respected leader in the creation of sustainable software and high-performance teams. He founded RoleModel Software in 1997 and has operated as the CEO ever since. RoleModel Software’s founder was introduced as "the father of software craftsmanship" at the inaugural Software Craftsmanship North America conference in 2009. Since ‘97, Ken has continued to pursue innovation and has driven RoleModel to provide sustainable tailored software solutions for over 100 companies.

www.rolemodelsoftware.com go visit there now!

“Tell me and I forget, teach me and I may remember, involve me and I learn.”
-Benjamin Franklin

Software development is constantly changing and improving. At RoleModel Software, we know that means we must learn to do the same. To expect that what worked yesterday will work for every tomorrow is to ensure you will become obsolete.

In the last 20 years, more than 15 notable programming languages have come into being. Considering how unique one language can be from another, that’s a staggering amount of diversity; and that doesn’t even speak of the additional frameworks that have been developed on top of these languages and require their own level of expertise.

That’s where CCC Days come into the picture for us at RoleModel Software. The C’s stand for Character, Collaboration, and Craftsmanship, which are RoleModel’s adopted core values. In every project, partnership, and interaction, we seek to exemplify these values.

The quarterly CCC Days is an opportunity to learn and improve in these areas.

Our goal is to create something or learn something. The ideal situation is a joining of the two.

In the weeks leading up to the event, the team gets to put up suggestions for projects to work on. As time goes on, the list gets narrowed down based on a show of interest and relevance to what we do.
The vision can be very general; an example from this year’s CCC Days was simply getting a better handle on SwiftUI, which is a framework to build user interfaces across Apple products with the power of Swift. RoleModel Software has not had many clients coming to us looking to build with SwiftUI, so this was something several team members wanted to invest in as a possibility for the future.

Sometimes, there is a more specific goal in mind. Another project idea from this year was to replace a tool that our project manager uses called the “support scorecard”. By pulling in data from an existing codebase and also using Github and additional APIs, the plan was to create a support dashboard to automate the process, making it easier and more reliable.

After a period of vetting the ideas, we decided on a final list of projects.

TypeScript (or type definitions) for LightningCAD core

This project tried to answer the question that based on the inheritance and complexity of LightningCAD core classes, would adding types or converting to TypeScript give us an improved developer experience, even if the client codebases didn’t use TS?

Using JSON diffs for LightningCAD

An exploration of RoleModel’s LightningCAD framework to see how we could leverage JSON diffs for better undo/redo speed and capability, plus opening the door for expanded collaborative editing.

Spike WebXR rendering for LightningCAD

A feature of RoleModel’s LightningCAD framework is that it allows for 3D viewing. This project explored using VR (Virtual Reality) and AR (Augmented Reality) to allow a viewer to get an even more immersive experience of how a custom-designed solution works in reality, referencing software we’re currently working on for a client where we’ve done photorealistic 3D rendering.

GraphQL in Ruby

Those involved with this project were trying to figure out how they might best layer GraphQL on top of an existing Ruby on Rails application, and if it could be used to be a simpler way to build an API for various frontends. If it could, they also wanted to discover the strengths and weaknesses of this approach.

Replace Scorecard with Application

RoleModel uses a “scorecard” to keep track of the health of our support projects. At the moment, the scorecard requires a lot of manual inputs and it becomes burdensome to keep up to date. This project was meant to replace a tedious process that must be repeatedly done, with a platform that could automatically fill in much of the data.

Basic Page Layout Starting point

As new devices with web access continue to be released and requirements change, it is necessary to improve the responsiveness of web apps to fit a large number of different screen sizes and resolutions. This project was designed to explore responsive techniques and the possibility to generate basic layouts for new projects more quickly and with cleaner code.

SwiftUI

This project, as I mentioned earlier, was intended to mainly get a better handle on SwiftUI and how it is incorporated. The team on this project juggled a few different ideas for ways to show their work but eventually settled on creating a companion iOS app for the time reporting and forecasting software we use at the company.

Over the next two days, the whole team got to work. I’m sure that the number of brain synapses firing during CCC Days, if converted into power, could light up a city.

Each person builds on their abilities to solve problems, to work as a team, and to think on their feet. The focus is on experimentation, and that shows itself in more ways than just learning new technology. No one expects to become proficient in a new coding language or framework in a couple of days; in the same way, good character is not grown overnight. Quality collaborative skills cannot be forced.

With our eyes on a future for software development that continues to become more complex and interesting, RoleModel Software is doing its part to ensure success with every new opportunity.

One of LightningCAD’s features is the ability to render a custom-designed model in 3D, which gives a user the ability to see and interact with a scaled, realistic representation of their work.

We’ve done some recent work with the Sayfa Group, an Australian company that produces fall safety platforms and accessories. The 3D capabilities are incredibly useful to them, showing a very clear picture of what is being produced and what it will look like in its final state. Those involved with the designs can manipulate their configuration as much as they need in the web-based setting.

Still, the possibilities were somewhat confined by dependence on a manufactured environment and an inability to actually get up close. It’s limited to panning, zooming, and dragging; a good start, but wouldn’t it be cool to see the model, exactly how it would appear, actually standing in front of you? What about the ability to walk around and even on the configuration?

Now it's possible

LightningCAD already renders the photorealistic 3D model. It was up to our developers to figure out how to transfer that into the XR space. (XR stands for Extended Reality, and it is a general term for alternate reality technologies, such as AR and VR.)

If you’re not familiar with the concept of virtual and augmented reality, here’s the breakdown.

A virtual reality environment is achieved by completely taking over your vision to give you the impression you’re somewhere else; an alternate, “virtual” reality. A headset is used to block out the presence of your actual surrounding, and whatever is showing on the screen inside the headset, whether it’s a movie, a game, or a LightningCAD 3D model, becomes all you can see. For this reason, VR is a far more immersive experience between the two.

Augmented reality, on the other hand, doesn’t seek to block out the real world; it simply adds to it. If you’re wanting to show a LightningCAD model, you could use a special viewer on your phone to display the model in your physical kitchen, virtually placing it on your coffee table. Amazon uses an AR view in their app so that you can see what a product will look like in your house before you buy it.

For virtual realistic viewing, we decided to use the Oculus Quest 2 headset to interact with our model. The Quest 2 is one of the most advanced all-in-one VR headsets available at the moment.
Augmented reality generally doesn’t require much for special hardware. We used an app called WebXR Viewer, created by Mozilla, and simply loaded it up on our phones.

With the hardware figured out, the team set to work adding VR/AR capabilities.
The software we wanted to experiment with was built primarily with JavaScript, so our developers have been using JavaScript’s 3D API, Three.js, to create their 3D objects within the software.
Getting the software to render 3D objects is one of the hardest parts. Since that was done, it was simply a matter of exposing the view of those objects in a different way, whether a headset or a smartphone.
Some of these basics are built into Three.js, so once we enabled those features and wrote some logic to place our model in the real world, it was time to test the result.

In the image above, you can see an example of a 3D model from our software being rendered in AR. This was shot on an iPhone. Notice how the structure appears in addition to people and objects that are also in view.

A bonus of keeping the “real world” involved is that you can move around your model and view it from different angles just by walking. With VR, there is mostly no reference to the physical world, meaning you need additional controls to navigate around the model.

This example is part of a Sayfa walkway viewed in VR. With the headset on, it’s as if you’re standing right next to the structure. As a user moves their head and looks around, the view changes as it would in the real world. The background is blank since we were focusing on the walkway configuration specifically, but there is certainly an option to populate it.

As was mentioned before, a shortcoming of VR is the difficulty to navigate around your design by traditional methods. If you take a physical step, you’ll move in VR, as long as the headset moves with you. The headset tracks movement fairly accurately. The problem is that you’re also taking a step in real life. The space in VR may be wide open, but putting on a headset won’t remove the actual wall standing in front of you.

Since there are some large structures that we wanted to render in VR, we knew there was an additional feature we wanted to enable with our experiment, and that was teleportation. Before you get visions of Star Trek and “Beam me up, Scotty!”, teleportation in VR works a bit differently.

The Oculus Quest 2, like most new headsets, includes two controllers, one for each hand. Once our team figured out the code they needed, they linked one of those controllers to a red circle that appears in the virtual environment.

By moving the circle to the desired location and then clicking a button on the controller, the viewer teleports to that location and the surroundings adjust accordingly, as you can see here.

The virtual ground we can cover with teleporting capabilities is endless. It doesn't matter how big a configuration is, we’ll be able to move around as much as we need.

By adding XR to our robust LightningCAD platform, clients will have another option when it comes to viewing their configuration, and it’s more true-to-life than ever before.

Since LightningCAD is a base framework that we customize for each client, any software piece built on it will have XR capabilities. The implementation of XR in LighningCAD will be a valuable addition and we look forward to watching the endless possibilities in the future for RoleModel Software. In fact, we’re excited to showcase these options early next year in some of the applications we’re currently building.

Stay tuned!

“I’m so proud of our team at RoleModel Software, Inc. who was identified by Clutch as one of the top 10 (#6) Business-to-Business (B2B) companies in North Carolina.” Ken Auer — CEO

Clutch.co is a company that is dedicated to providing buyers of B2B services the most important information when they purchase B2B services. Their team sits in the heart of America’s capital city and takes the time to interview clients, verify the reviews independently to ensure their accuracy, and curate the content so that you can feel confident the next time you purchase B2B services that are ranked on Clutch as a Clutch leader.

This is why we’re so thrilled to highlight our Clutch profile and our stellar star average from reviewers like the COO at a dental laboratory!

Thanks to our enthusiastic positive reviews from our satisfied customers, Clutch ranked us as one of the top web and custom software developers in the state of North Carolina. Our recently rebranded LightningCAD framework is just one of the many exciting things driving a strong year. It’s a privilege to make Clutch’s resource shortlist for 2020.

We’re incredibly grateful to Clutch for selecting us, and even more grateful to our many happy customers who left us great reviews on their platform! If you’re interested in web and custom software development, give us a call today!

RoleModelSoftware.com
LightningCAD.com
consult@rolemodelsoftware.com
919–557–7550

Assuming you don’t have a software development team in-house, or even if you do and they’re too busy to get the job done, you’ll be outsourcing the job to another company. You know you’ll get better value from a team, but now you face another question. Do you hire an offshore team, or an onshore one?

Conventional thinking says offshore is the better choice, because it’s almost always cheaper, sometimes significantly. But is that really true?

The real cost of offshoring

The cost per hour for offshore developers is undeniably lower in many (if not most) cases. You might see something like an offshore developer being one-third the cost of an onshore one. Saving 66% or more per hour looks like a great deal on paper.

Look beyond the hourly rate, though. The rate per hour you pay is the top line comparison. You care more about the bottom line result. That’s where the hidden costs of offshoring can bite you.

Here are three big hidden costs to consider:

• The remote management cost. If your offshore team is too far away to manage well, you’ll pay for that. You’ll lose your grip on the project, and almost certainly waste time on back-and-forth with timing issues. Imagine a team in a part of the world where they’re working while you’re sleeping. That tends to fail, and you end up with software that doesn’t meet your needs well enough, if at all.
• The language barrier cost. Communication is hard. Communication among people who don’t speak the same native language, and don’t have the same cultural context/assumptions, is even harder. Be ready for the extra burden of rework because the language barrier meant somebody didn’t understand what you really wanted. That can get you software nowhere close to what you wanted, and you’ll probably get it late.
• The skills deficit cost. I’ll talk about this more later, but do the offshore developers you hire really have the skills you need? They check the buzzword checkboxes, but that doesn’t necessarily mean much. And when your developers don’t have a clue, the system they build for you can be an albatross instead of a strategic asset.

What’s the cost of delay, or wasted time? That depends on your business, but it’s certainly not zero.

What’s the cost of rework? That depends on what you paid the first time, but rework cost is usually a multiple, not a slight upward adjustment. It is extremely hard for a new development team to transition a disaster into a success without starting over.

The hidden costs are probably higher than the money you saved on the hourly rate. Maybe much, much higher.

An example

We recently worked with a customer who gave us a direct comparison between our entirely onshore approach and another partner they worked with offshore (in South America).

The offshore team they hired created software for them in six months, at a cost of $50,000. Our customer wasn’t fully satisfied with the results and when they needed to scale the solution decided to have us essentially redo the project as “version 2”.

Our onshore team redid the software for them in a single month, at a cost of $45,000. Our version also included migrating all data from the version 1 system to the new one, integrating into their single-sign-on (SSO) platform, giving them almost entirely test-driven code (reducing the bugs they saw in the first launch), and adding more business features than in the original project scope.

That’s essentially the same project done by two different development shops. The onshore shop:

• reduced cost by 10%,
• reduced delivery time by more than 80%, and
• created a long-term, well-tested, software asset with more features.

That is admittedly a single case, but why the difference?

Factor 1: Experience and skills

You can find poor developers offshore or onshore. If you’re based in the U.S., though, you generally find people outside the United States, often in economically depressed areas of the world, who see software development as a path to success and knowingly or unknowingly try to take shortcuts to get there.

Your offshore developers might have academic experience writing software to a spec for a few “happy path” test cases. That’s not a system supporting many users over time, and it often shows. Most offshore developers simply don’t have experience supporting software in production for years. Sometimes you’ll even find developers who haven’t seen the full lifecycle of a single project — they’ve only added to existing codebases.

Do they really know the issues that come up once real people start using software? Do they know what can go wrong when you leave the happy path? Have they seen enough to be fully competent? You rarely find that kind of experience and expertise overseas (it’s actually rarer than you might think here in the U.S.), and you’ll pay for it as your system collapses under the weight of the real world.

At a more fundamental level, you also rarely find offshore teams using software development best practices. They may talk about them in their marketing materials, but they don’t use them.

Consider Test Driven Development (TDD). It’s one of the best ways to maintain design simplicity and project safety, but few developers here in the U.S. use it consistently, and even fewer overseas do. Not using best practices like this can lead to software that’s hard to maintain, and can’t grow and change with your business. You can do the math for yourself on the opportunity cost.

Factor 2: Language and culture

Cultural and language differences can have a large impact on your software development costs and success.

Working with a bunch of developers in a culture different from yours can mean you’ll face different interpretations of “quality”, different styles of handling (or not handling) conflict, or even different understandings about what misrepresentation means. It can get messy quickly, which can cost you time, which costs you money.

And that’s if everyone speaks English. What if they don’t? Then amp up the challenges again. If you have to spend a chunk of time in each meeting translating and making sure everybody nodding is in fact understanding things the same way, you’re going to move slower, see increased rework, and most likely end up paying more for your project.

Factor 3: Management

When you work with developers overseas, it’s typical to get a “manager” for your project who is supposed to herd the cats, give you a single point of contact, and keep things on track. The idea is good, but the execution often falls short of the goal, to be generous.

You’ll often find yourself having to manage a remote team, probably in a wildly different time zone, with different work patterns and expectations. You thought managing local folks was hard!

We have had a couple of overseas clients ourselves, and in both cases we’ve made it work in different ways, whether that’s having them visit us for some “face time” and a well-coordinated project kick-off, or adjusting our schedules to allow for daily synchronization and no language barriers. That’s the kind of effort it takes to manage an offshore project well. Is your offshore team good at managing that way? If not, you’ll pay the price.

Adding it up

The economics of offshore software development aren’t nearly as compelling when you consider:

• the cost of creating a system that can’t stand up in the real world
• the lost time due to miscommunication and mismanagement
• the opportunity cost of having to pick up the slack for that.

In fact, your costs can be much higher with the offshore approach.

If an offshore development shop claims they’ll save you 30%, 50%, maybe even 75%, of course you’d be excited. Who wouldn’t be?

If all you really need is a team to code up when you’ve already fully specified a relatively simple problem, offshoring might be a good option. But when you need a high degree of collaboration with a highly skilled team, and you add up all of the other costs we just talked about, most of the time the offshore claims aren’t really as good as they look.

Why not do that?

It’s not always a bad option. Buyers without any custom software development experience or exposure, though, can be stepping in a deep hole when they do it. They don’t know what they’re giving up by going that route.

There is another option: hiring an experienced team.

If this has the cash register ringing in your head, let me preface it with this…

Most often, hiring a team of people costs more up front than hiring one person. But hiring a team can end up costing you less over time than hiring one developer. It’s counterintuitive, but true.

One of the reasons is the myth of the rockstar.

The Rockstar Myth

Rockstars exist. Some developers actually are that shockingly good (ours are pretty darn good, actually). They seem to do everything right and have the perfect set of skills. They can be a huge benefit to your company. But the number of people claiming the rockstar title is far greater than the ones who live up to it.

There are some common harsh realities when you hire a developer claiming to be a rockstar:

1. Some rockstars aren’t. We’ve encountered some who, to be diplomatic, misrepresented their technical abilities. If the developer you choose really can’t walk on water, you get what you get, and you potentially waste a pile of money (and a lot of time) finding that out.
2. Heroes are often undisciplined. Sometimes they can work magic. Other times, they wreak havoc. If they can’t save the day at the last minute, you’re stuck with the bill, and the mess. Hero coders often don’t do “mundane” things like testing their code (even better, using Test Driven Development, or TDD) or validating the user experience. Those practices — and skills — can make all the difference.
3. One person is rarely an expert at everything. That includes everything you need for your software. You’ll probably need some design, some coding, some DevOps, and some business consulting. Omniscience is rare. Learning that after you start and hang your fate on a single hero can be costly.
4. One person dictates the schedule. Your rockstar might work nights and not be available when you want. Or maybe that person is on the other side of the world and doesn’t get back to you for a day. Or a week. That bottleneck can cause pain.
5. All of your eggs are in one basket (your “truck number” is one). Life happens. What if your rockstar gets sick and your project is on hold for a month? Or what if your rockstar goes silent and refuses to answer your emails? You’re out of luck. Whether they literally get hit by a truck or not, they only have so much time in a day, and there are so many things that can take that one person’s attention, either during the project, or when an urgent customer problem comes up, or weeks (or months, or even years) later when you want to add some significant new feature.
6. Rockstars often lack business experience. They’re frequently focused on technical issues, and not your business goals, which means they might not really understand what you need your software to do.

Rockstars Add Risk

There’s a word for all of those things I just listed: risk. It doesn’t matter if it’s risk of delay or even failure. Either way, it’s risk of higher cost, often much higher.

Ask yourself this:

• What is the cost of correcting what one not-so-stellar rockstar messed up?
• What is the cost of getting only one person’s opinion about the best choices to make?
• What is the cost of trusting one person to know everything about your system if that person leaves?

Probably more than you want to pay.

If you plan to spend $100,000 on a strategic software investment for your business, imagine spending twice that much because your rockstar turned out to have oversold himself. That ain’t tiddly-wink.

Fortunately, there’s a way to avoid this danger most of the time.

Teams Reduce Risk

Hiring a team mitigates most of the risk we just talked about.

You end up with a collection of people who know your system and can change it with confidence. You’re not locked into a single person’s opinions about what your system should be. And you can make progress even if one person is unavailable.

This can end up costing you far less than the supposedly superior rockstar was supposed to. A quick example can illustrate how.

Let’s say you hire said rockstar. He charges you a high hourly rate(he’s a rockstar, after all). He says he works on your system for 6 months, roughly 6 hours a day. He went quiet over a month back, and only emailed once to update you on progress. He delivered something yesterday…and it doesn’t work.

You spent a bunch of money on software that doesn’t do what you need it to. Odds are good the codebase you paid for is a twisted mess, and you’ll need to scrap it and start over. You can’t get solid code reviews to ensure your code is written in a way that’s understandable to a different person who didn’t write it if you only have one developer working on it.

Now let’s say you hired a skilled, experienced team to do the job. They create a system for you in 4 months. Along the way, they deliver working software to you at least every two weeks (most often daily), and it’s fully tested so it’s proven to run. You can validate that it does what you need for your business, because you’ve seen it all along. You never even saw the changed system until it was rigorously tested and peer-reviewed for quality. The team charged you every two weeks for the work they were doing completely transparently, and the total cost came to more than the rockstar’s cost.

True, you paid the team more than you paid the rockstar, but you avoided the rockstar delay and money waste. You don’t have to pay the rockstar, then pay another one to get it right (or rinse and repeat as they keep missing the mark). Did the rockstar save you any time? Any money? Any headache? Any risk?

Not every team works the way I just described, but what you’ve just read is the nutshell version of what it’s like to work with our team. We do that all the time, so you can be sure it’s not a fluke. That’s how it should be.

Bad Teams Don’t Help

If you have to choose between an awful team with lackluster developers who deplete your bank account and can’t give you what you want, and a single self-professing rockstar who may or may not be able to deliver, the rockstar might be worth the risk.

Those aren’t your only options.

A great team without a single rockstar can do amazing things. A great team with great developers, designers, project managers, and DevOps experts can wow you. Look for a great team and you really can’t lose.

Clutch provides a very valuable service to people considering hiring custom software development teams. They get detailed reviews from actual customers. We’re glad their service exists and that it has led to our Clutch Leader Award.”

— Ken Auer, CEO of RoleModel Software

An expert at Forbes acutely observes the potential roadblocks to outsourcing a software development project. It can be difficult to discern which providers can effectively deliver your software solution, especially if you’re not technical yourself.

Here at RoleModel Software, we’re capable of crafting sustainable software that can give your business a competitive edge. Why trust us, though, when there’s a whole sea of software developers?
We’re proud to announce that Clutch.co — a B2B ratings and reviews platform — has named us a top 1000 company. This is a big deal, because Clutch lends credibility to businesses through research-based evaluations.

We maintain a perfect 5-star rating on the site, where you can read the reviews left by our happy clients:

“Everything met or exceeded our expectations. The biggest thing that distinguishes RoleModel Software from other providers is their commitment to excellence.”
— IT Manager, Higher Education Company

“In a time when people expect instant service, this tool sets RapidAir apart as an industry leader… Plenty of companies have good processes in place, but their staff’s desire to think outside the box in an unfamiliar industry really stood out.”
— Andrew Remus, Founder/Owner, RapidAir Products

Since we’re fueled by customer satisfaction, we’re proud to be recognized by such a client-centric platform.

Clutch offers additional resources. For example The Manifest, a leading company ranking site, can help you with your B2B purchasing decisions.

This recognition only further motivates us to provide businesses with the tools they need to grow and succeed. We’d love to start with you — come talk to us today!

I’ll refer to it as I attempt to point out the key points that I have found contribute to the ultimate success of an investment in custom software development.

The Rules of Engagement

The six rules we identified in the original paper were about Extreme Programming. But let’s look at them now, and remove the words “Extreme Programming” or “XP”. If we ignore the fact that they were originally meant to help understand whether you were “Doing XP” or not, and instead consider how important each “rule” is in the success of an investment in Custom Software, we have a fairly concise list of important points.

Let’s discuss each briefly:

E1. [The Team] consists of a group of people dedicated to the production of a software product. This product may or may not be a piece of a larger product. There can be many roles on this team, but there must be at least a [Product Owner] and a developer role.

Rather than a master/servant relationship, it is important to have everyone recognized as a valuable member of the team, no matter who is paying the bills. It is also important to recognize that someone (or group of someones) needs to be responsible to identify the target, and someone (or group of someones) needs to work hard to hit the target. In the original language of XP that would have been called the “customer”, but it has generally evolved and accepted to be known as the “Product Owner”.

The target may (and almost always is) moving to some extent. The product is being built for some set of target users to accomplish something in a better way than they can without the proposed software. The beneficiaries of this improvement can be singular or many. The reality is usually that one of the beneficiaries is funding the effort. They are a “stakeholder”. They may be:

• an investor hoping for some level of financial reward for a new business built around the target, or
• a company owner (or key player) looking to streamline some process that they currently see as inefficient, or
• a “Product Owner” whose job it is to make sure the software satisfies the intended goals of other stakeholders.

There could certainly be multiple stakeholders.

If the goals of the stakeholders include pleasing some set of ultimate users of the software (perhaps a customer of theirs), the Product Owner should have a pretty good idea of what might achieve that goal. They need to be (or quickly become) a Subject Matter Expert (SME) that has the stakeholders’ interests in mind. Getting real user feedback to validate that the goals might actually be met is invaluable.

Could there be a group of Product Owners? Certainly, as long as the group can figure out how to clarify what needs to be done. At the end of the day, if it is not clear who the Product Owner(s) is/are or how to figure out what they intend, you are doomed.

That doesn’t mean the Product Owner is all-knowing. Jim Highsmith referred to one study that showed initial requirements are typically 15% complete and 7% accurate. If the Product Owner were four times better at defining requirements than that average, that would make them only 60% complete and 28% accurate. And even if they were close to all-knowing, there is the problem of perfect communication to the developers who are not.

It is also important to recognize that the developers (the ones who produce the software) have an understanding of how to build software that the Product Owner either does not have, or does not have the capacity to execute. The developer is a “subject matter expert” of a different subject. They also have a communication challenge in conveying their knowledge sufficiently to the Product Owner.

That leads to…

E2. The [Product Owner] must set and continuously adjust the objectives and priorities based on estimates and other information provided by the developers or other members of the team. Objectives are defined in terms of what, not how.

“Priorities don’t matter as long as you get everything done.” I’m not sure who first said it, but the reality is that you will rarely get “everything” done and you will never get everything done at once. I’ve heard it said that “software is never done, it is only released.”

When a project is started, you are the least intelligent you will ever be about what really needs to be built to hit the target. As what is asked for is manifested in working software (or not quite working software) new realizations will come to light. You are on a journey in a dynamic world. When you start, you are trying to hit a fuzzy point on a horizon. But there are two things you must consider:

1. As you progress, the details of the path to your target (and both obstacles and opportunities in that path) will become clearer,
2. The world between your starting line and your finish line does not stop. New information from outside the development effort will inevitably affect your view. Perhaps a competitor announces a new product, or a significant customer will appear with a request that changes your perspective (and perhaps your target).

E3. The [Product Owner] is always available and supplies information on demand to assist developers in forming estimates or supplying desired deliverables. The [Product Owner] is an integral part of the team.

Due to the nature of all of the above, as developers tackle tasks, new questions will come up and new discoveries will be made. If decisions about how to respond to those questions or discoveries are left to the developer, who presumably understands the implications less than the Product Owner, they could go down a wrong path.

In the last two weeks, I saw a requested feature derailed twice when a developer who thought he understood what was needed came up with a “different” way to deliver what they thought was requested.

The first time, the Product Owner wasn’t in the room when the developer came up with an alternate approach to the problem that would be simpler than what had been discussed. Instead of validating that this simpler approach could work with the Product Owner, they asked another developer if they thought it would work. The second developer agreed that it would be simpler. The developer then spent a day working on it, when the Product Owner checked back in to see what kind of progress was made. As soon as the “simpler approach” was explained, the Product Owner instantly recognized a side effect that this approach would cause that would undermine the integrity of the system. He pointed that out to the developer, who recognized they needed to start over.

Due to unforeseen circumstances, that developer was unable to continue on the project, so a new developer took on the task. They sat down with the Product Owner who explained what was needed and why the “simpler” version was counterproductive. The new developer understood the parameters and “got on it.” Again, the Product Owner was distracted for a couple of days. The developer felt that the UI that had been sketched out would not work in certain cases and came up with an alternative. He went down that path for a day and then, when the Product Owner became more readily available, reviewed it.

This time the Product Owner saw that the new UI would be more cumbersome for the 95+% case, and confusing for the remaining 5% case. Two days of development were spent on wrong paths because the developer and Product Owner did not have a tighter feedback loop.

Whether it was the developer’s fault for being presumptuous, or the Product Owner’s fault for not being more readily available is not important. The fact is that the longer the feedback loop between Product Owner and developer, the greater the possibility of efforts spent on misunderstandings will be.

In my 35+ years in the software industry, I can point to the projects that got the most “bang for the buck”. They had two key ingredients:

1. The Product Owner was a subject matter expert, fully engaged, excellent communicator who was quick to provide helpful feedback, and able to reprioritize in short order.
2. There was a strong experienced development team that possessed high customer empathy and could push back when they suspected an important detail was missing or not being given an ample amount of attention.

The Product Owner would wisely push pause when direction on a certain feature or task was not clear or respectfully challenged, redirecting developers to work on something that was more clear while they sorted out the details needed to get clearer/better direction on the feature or task.

I recognize that perfect combination is hard to find.

A strong, experienced Product Owner with an inexperienced development team and low customer empathy can sometimes keep the developers on task with some level of success.

A humble, inexperienced Product Owner who is always available with a strong, experienced development team can come up to speed pretty quickly and also achieve some level of success.

A strong Product Owner who is not quite always available can also succeed if they have an experienced development team with strong customer empathy.

But woe to the rarely available, inexperienced Product Owner with an inexperienced development team with low customer empathy.

E4. At any point, any member of the team must be able to measure the team’s progress towards the [Product Owner]’s objectives.

If the objectives are not clear, people will get caught up in whatever interests them at the time. We try to make it clear what “success” looks like in both the short and longer term, and make sure everyone knows what they are. For example, “by next week, we’d like to be able to 3D print a guide that can be used in surgery for a normal (90%) case.” There could be all sorts of questions about the best UI for a feature, the optimal way to store something in a database, the nuances of an exceptional case, and many more interesting items to discuss and explore. Having clear objectives can keep all those discussions and explorations at bay.

Anyone on the team should be able to ask, “How does [whatever you are working on] help us meet our current objective?” And, anyone on the team should be able to recognize “we’re halfway through the time allotted to achieve the objective, and it doesn’t feel like we’re anywhere close to halfway to the objective. Something has to change… either our focus, approach, or the Product Owner’s expectations. Time to raise a flag.”

The worst waste of money I ever saw on a software project was due to high level managers stating outrageous objectives, and not wanting to hear anyone raise concerns about whether they were achievable. A three month deadline was given at the beginning of the project. It was clear that you could not question the deadline or suggest that we pull back some of the grandiose objectives. When the deadline came, and the objectives weren’t met, someone in the management chain would get fired and a new deadline would be set (typically 2–3 months later) without asking the team what really needed to happen to meet the objectives or how to scale back the objectives to make the deadline achievable. Tens of millions of dollars were spent over the better part of two years with about 7 deadlines that were never met. None of the grandiose objectives were met either by the time someone finally decided to stop the madness and abandon the project.

E5. The team must act as an Effective Social Network, this means:

1. Honest communication leading to continuous learning.
   
2. Minimal degrees of separation from what is needed by the team to make progress and the people/resources that can meet those needs.
   
3. Alignment of authority and responsibility.

When something is harder than was hoped, communication happens that raises the flag and discusses the reasons. People who might be able to effect alternative approaches (e.g. more modest objectives, a different angle, or more/different resources) need to discuss it.

Reality is going to hit people in the face eventually, so you might as well embrace it early to work through the challenges.

Realize that you will be (or at least should be) smarter as you go, but only if you embrace what you find and incorporate it into the effort to meet the objectives. The Product Owners, the developers, stakeholders and others will all be learning, and identifying puzzle pieces that can be helpful in achieving the goals. Encourage them to share what they learn so they can put the puzzle pieces together. The discussions had in working through the problem together may (and often do) turn an arduous task into an achievable one.

Giving a team of ten people each ten pieces of a one hundred piece puzzle, and then asking them to work independently to put the entire puzzle together would be ludicrous. And making them go through some grand ceremony each time they might suspect the other can help them in the name of “protecting their time” is ludicrous, too. Make sure everyone is aligned to the same objectives, and trust them enough to manage their own time to help get there. If something is getting in the way of effective communication address it. You will not achieve your goals if the people holding the puzzle pieces can’t freely collaborate.

Don’t tell someone they are responsible for getting a job done, and then put a spending freeze on them, or tell them they need to use a certain set of technology because the IT department has standardized on it if they have a good reason that using the technology would jeopardize that stated goals. Ask them what they need to get the job done, respectfully question if there are alternatives that might be more cost-effective, or have better side benefits, and then enable them to succeed.

Giving someone authority to go with the responsibility they are given may or may not work. Not giving someone the authority to fulfill the responsibility they were given is doomed to failure.

Many years ago, at a previous company, I recommended a brilliant young overachiever be interviewed for my team. I was told that we had no room for him in the budget so the interview was denied. But a few weeks later, I was given a “new hire” on my team. Another manager had hired him and he somehow got him assigned to me, even though I had recommended against the particular new hire. The new hire was the owner’s nephew. Nice guy, but totally incapable of contributing to the task I was given or pretty much anything we were doing at the company, and he was given no training. He had also been hired at twice the salary for which I thought we could have hired the overachiever. A few weeks later, the president of the company confronted me about the cost of my team and why he hadn’t seen the payback. Somehow I managed to calmly explain that I didn’t ask for the overpaid new hire and he wasn’t capable of contributing. I suggested the fastest way of getting things back in line was to fire the young man we never should have hired. He said, “I may be dumb, but I’m not stupid. I’m not going to fire the owner’s nephew!” He never explained how I was going to be able to reduce my budget.

So, I ended up doing the only thing I had the authority to do. I left that job and started my own company. That’s the kind of thing people do when they feel like they are caught between a rock and a hard place.

E6. Timeboxing is used to identify segments of development effort and each segment is no more than one month in duration.

I’ll assert the following:

• No one likes to be micromanaged.
• Estimates are educated guesses, not guarantees.
• When people decide to risk spending money on something, it is reasonable to expect that they’d like to see positive value in rough proportion to how much they spend

Sometimes I am presented with a problem, and confidently go in a direction that leads to a dead end. I am worth zero in that hour. (Though my education has value that could be helpful later).
There are some hours that all of my years of experience culminate in being at the right place at the right time to solve a problem, and I am worth thousands or tens of thousands of dollars for that hour, just like Charles Steinmetz.

Henry Ford once balked at paying $10,000 to General Electric for work done troubleshooting a generator, and asked for an itemized bill. The engineer who performed the work, Charles Steinmetz, sent this:

“Making chalk mark on generator, $1. Knowing where to make mark, $9,999.” Ford paid the bill.

If I tell someone a software project is going to cost on the order of $250,000 to $500,000, and they decide that it is worth the risk to spend that kind of money to receive what they expect to be a greater reward, it is unreasonable to expect that they’ll just write a check for $500,000 and schedule a meeting for 6 months later to see how it went.

On the other hand, it is unreasonable for them to break the perceived value into rough hourly tasks that would each be worth $250 until it added up to $319,750 and the big spender got exactly what he wanted.

A much more reasonable approach might be to spend some time to explore the problem space and then break down the value into milestones that can be checked along the way. Being too stringent on every detail of those milestones would be counterproductive (see most of the discussion on the previous rules).

Put objectives on every iteration of a reasonably-sized timebox to get things done. Make sure everyone knows the objectives and agrees that they are reasonable and worthy. Recognize that adjustments will be made as the team learns. Expect them to flag any big surprises anytime they occur, and what is being done to mitigate them. Get a summary of where things actually are at every milestone, and have the team adjust accordingly.

At RoleModel, we tell our clients that it is both of our jobs to manage the budget together. We both need to be prepared to make trade-offs as we learn new things and share what we learn. If things look we’re not going to achieve major goals, we may have to scale back our expectations and cut out some valuable but non-essential features. If it looks like we may be able to achieve major goals sooner than expected, we discuss whether we should just come in under budget and be satisfied, or add some other value added features that we didn’t think we’d be able to get.

By having a good cadence for communication about budget and timeline, nothing should ever go to far from expectations in either direction, and micro-managing should be avoided.

Conclusion

These rules of engagement are somewhat timeless and are really rules of a healthy relationship between people of different talents working together to achieve shared goals in the complex world of software creation… turning hard-earned expertise into a high impact asset — that can exploit that expertise — from scratch.

Following these rules of engagement will get you far with respect to desired features, and managing a budget. However, none of what we discussed really addressed the implications of long term quality or the ability to quickly adapt to things you continue to learn over time.

For that, we’ll need to address the “Rules of Play”. I’ll do that in another article.

I’ve been in my industry for years, and I know the landscape well. I want to do X, but I haven’t found any software that does what I want, exactly how I want to do it. Can you all help?

The direct answer to the question is almost always yes, but we typically ask people to consider another question first…

Do you really need custom software to achieve your goals?

If you do, we’re happy to help, and we’d love to have an initial conversation to determine if we’re a good fit for you.
But it’s not a given that you actually do need custom software.
Custom software can cost as much as a house. Before you make that kind of financial commitment, it pays (sometimes literally) to do your due diligence.

If you don’t have experience in the custom software world, it can seem like black magic. The terminology is foreign, the costs are based on factors you probably aren’t familiar with, and many of the issues involved might be things you haven’t thought about before.

We can, however, give you some things to consider based on common themes we’ve seen with customers in the past. Think of it as a questionnaire to determine if custom software should be on the table.

Question 1: Why do you want the software to begin with?

There’s at least one pain point you want to address or you wouldn’t be considering software at all. What’s the pain?
Is it wasted time? Added cost? Missed revenue? Not achieving your vision? This is the value your software will add to your business, so do your best to qualify and quantify it.

We help customers do this as part of our Conceptualize and Explore phases (and we’re happy to do it), but thinking about this ahead of time can help you know whether custom software is the right road for you or not.

And don’t forget that the pain might be a broader opportunity than you were considering. If there appears to be no software for your industry that does what you want, is that true for others? Could you make money on that with a custom software offering you sell? That’s a bigger step, obviously, but it’s worth some thought.

Question 2: Can something “off the shelf” cut it?

If you strip down what you want to achieve to only the “must-have” features, is there anything on the market that will get you where you want to go? This minimalist thinking is something we walk customers through in our Conceptualize and Explore phases, so it’s worth considering it before you decide custom software is a strategic enabler for you.

If you can find something that might do the job, consider buying it, because custom software will very likely cost you more.

If not, is there a set of tools that’ll give you what you want if you cobble them together with a tool like Zapier, which can link tools in creative ways? If so, consider doing that, because again, custom software will very likely cost you more.

If not…

Question 3: What are your bare minimum required features?

This is what you need to create in order to get some subset of real users as soon as possible so you can validate whether you’re right or not.

What you’re trying to create is what’s called a minimum viable product (MVP). That’s the barely sufficient software that will create business value for you. Every word is important:

What is the absolute smallest set of features (minimum) which will give you working software (product) that adds measurable value to your business (viable)?

That’s the goal. Don’t add more than you need for your MVP. Those additional things can come later. First things first.

Once you know your MVP…

Question 4: Do you really have the budget and timeline for your MVP?

This one is a little uncomfortable, but it’s vital to answer.

If you don’t have a budget and timeline that gives you a realistic shot at partnering with us — or any competent development team — to create the software you need, even for your MVP, let’s not try to force something. We’d rather find that out before we even begin, and give you good counsel either way.

How much does your budget need to be? It depends on what you want in your MVP and beyond. Realistically, if you have at least somewhere between $50,000 and $250,000 it’s worth talking to us to figure out if that’s enough. Anything less than that usually isn’t. In fact, less than that probably won’t get you custom software anywhere. It may be enough to leverage a generic platform (e.g. WordPress) for some limited set of functionality, but that’s not what we mean when we are talking about custom software.

We’ve worked with people in the past who didn’t have a realistic idea of what “the next Facebook” can cost to create, or if it’s realistic to create at all. Save yourself that pain.

And remember, your MVP is the first step. You’ll almost certainly want more. So…

Question 5: Do you have the budget for your “full” system?

Assuming your MVP budget and timeline are realistic, how much is the rest of what you want likely to cost?

We try to get a preliminary idea of this in your Conceptualize phase, and we refine it in your Explore phase. It’s different for each app. That said, it’s certainly more money than your MVP, and it might be more money than you have or are willing to spend.

Let’s say we estimate together that your MVP will cost roughly $200,000. And let’s say you know you’ll want a value increment beyond that, probably 3–6 months after your MVP goes live, and that would cost another $100,000. Do you have the total $300,000 to spend?

If you do, that’s great, and we would encourage you to get started. If you don’t, do you have a business plan for how to secure the additional investment necessary to fund the rest of what you want to achieve?

We worked with an entrepreneur who didn’t have all he needed to get started, so we counseled him to wait on the MVP until he had secured investors. He went out and found them, then we built him a great system that continues to help his business succeed.

Or maybe you can invest a smaller amount initially to get either a very minimal MVP as a proof of concept, or at least a “walking skeleton” of one (an incomplete implementation which explores the major system components and their linkages), and use that to secure the funding you need to get to the next level.

Again, we’re not looking to take your money. We’re more interested in helping you be successful.

Finally…

Question 6: How much will support cost?

It’s amazing how many people can relate to support costs for almost everything else in life, but they forget about it when it comes to custom software.

Contrary to popular belief, there simply is no such thing as bug-free software. You can only be assured of the things you’ve tested for in the environments you expected, but users will eventually do something you didn’t anticipate. And there’s no reason to think your initial software will be perfect for your business forever.

You’ll need to fix things and grow things to preserve the value your custom software adds to your business. That means ongoing support.

We sign support contracts with most of our customers, and we like to think our approach is reasonable, but it isn’t free. Would you buy a car and not expect to service it to keep it in good running order? Not if you’re smart, so assume you’ll need to do the equivalent for the software that enables your business vision.

Our rule of thumb for clients is to estimate you’ll spend 20% of your initial development cost for support in the first year after the software goes live. If you do that, you won’t be far wrong. Why? Because that’s what we’ve seen to be true in many real-world systems.

So, you think you need custom software?

If you have a good idea of what you want to achieve with your software, you have a realistic budget that will let you create what you need, you can’t find something off the shelf to get there, and you realize your software will need support to be an asset to your business, then custom software might be a good fit for you.

The next step is to hire a superior software development partner, with a solid track record, to help you create the software that will pay you back for years.

With over 35 years in the software industry, I am no longer amazed but rather saddened, at how often unrealistic and poor choices are made in software investments. Many established businesses want to buy versus build whenever software is mentioned. There are many good Software as a Service offerings to handle commoditized processes for small-to-medium businesses and larger enterprises. There are certain types of software (e.g. marketing and simple self-serve websites) that can be built effectively, quickly and relatively inexpensively by someone who is proficient at a particular platform (e.g. WordPress).
Yet, many businesses have at least one way they differentiate themselves from their competition that is not easily served through commercial off-the-shelf (COTS) software or customizable platforms. They believe they have some expertise that their competition does not. Yet, they shy away from investing in unique software that can capture their unique expertise and leverage it in ways that only software can and settle for “me, too” mediocrity (or worse).

Many business leaders want to believe that this expertise they’ve spent enormous amounts of cumulative time and money in gaining can be converted into software in a way they would never treat any other capital investment. Perhaps they have read about agile processes and think it will help them avoid catastrophe, but try to exercise it with unproven talent. Or they hire a bright person or two — or maybe even a big name company — without really digging into their track record to see if they’ve really ever delivered software that leverages expertise in an effective way for the long haul.

I hope that this article will help others avoid big mistakes in the investment of custom software. Whether that investment is on the order of tens of thousands, hundreds of thousands, or millions of dollars, it should get a return that exceeds the investment. If done well, that should be an outsized return that continues to increase in value over time: a sustainable software asset that is a strategic advantage, rather than a frustrating liability that never delivered on its potential.

Sustainable Software Explained

There are many kinds of software ranging from simple to complex and short-lived to long-lived. At first glance, without giving the differences much thought by the naive, the differences may not be obvious. However, an “information only, publicly accessible” website is radically different from a business application that extracts and codifies deep domain expertise and provides a delightful user experience for secure creation and management of complex concepts which require a level of essential compliance to significant rules.

But the parts of software beyond what a user sees on the screen are mostly invisible and a mystery to many. But let me offer an analogy that may be easier to understand yet extremely similar in many ways.
A simple dog house and a custom-built home may have some resemblances. However, the inherent complexities of the custom-built house require a different approach and set of skills to produce, though some of the same skills used in building a dog house may be useful in building a custom home. While you might safely employ a handy teenager to build a dog house with little risk to meet the basic goals of a dry shelter for your dog, knowing that the cost of future replacement is minimal, you wouldn’t think of asking the same person to design and build your custom dream house that you plan to be an intergenerational home with much more complex desires.

One can build a dog house in a “quick and dirty” way for tens or hundreds of dollars in parts and labor, ignoring the effects of moisture and weather, and it will meet the immediate requirements. For hundreds or thousands of dollars in parts and (more skilled) labor, a premium dog house might be built with much more care to stand the test of time, dressed up with a lot of unusual features. That premium dog house, though, still doesn’t begin to compare to the simplest of custom homes. Again, what it takes to build the simplest and smallest of homes versus the most majestic dream homes will vary greatly in both process and required skills, though some of the same skills used in the simpler home can be employed in building the dream home.

The two biggest factors in determining both the cost and skills needed for building projects are complexity and expected longevity. And many have learned the hard way when they’ve hired people who lacked skills or integrity to do the job well.

Software is much like building in that basic way, though much more adaptive to change if done well. Any significant software investment will also need maintenance in various ways, just like any house that is lived in or subject to the environment will over time.

There’s a bit of a fuzzy line between consumable software and software investments. But the key difference is a mindset. The “consumable” mindset is more of a sprint, producing as much as possible to meet immediate needs without a lot of thought to whether the software being produced is sustainable… Will it scale? Can it be easily changed or extended while there are active users? Are there hidden bugs swept under the rug that could cause significant future damage? Is there a suite of regression tests that prevent bugs from popping up when someone changes something in the code? Beyond the inherent complexity of the problem space, how much complexity has been introduced to the codebase that makes it harder to approach?

The Importance of Sustainable Software Expertise

The sad thing is that many software developers, software product managers and stakeholders don’t recognize the things that impede the sustainability of software because they are really Advanced Beginners with respect to building sustainable software. The Dreyfus Model of Skill Acquisition and studies since then have identified the different levels of expertise and the implications of each.

It is easy to find a Novice and many do. We are all Novices at something to which we may have been barely introduced. For example, if you have had an introduction to HTML or programming, gotten a degree in IT or Computer Science, or been to a “coding bootcamp” you are probably still a Novice software developer. You have not actually developed any software beyond the software equivalent of a simple dog house. If you have ever been involved in software that is actually used by someone else on a regular basis, you may have moved on to being an “Advanced Beginner” (whether or not you have spent much time actually supporting the software you were involved in creating). Novices and Advanced Beginners often hire Advanced Beginners at significant pay rates.

Unfortunately for a Novice, anyone who seems to know more than them looks like an expert. But this is just not the case. And an Advanced Beginner without the proper perspective of where they are on the learning curve may think they are farther along than they actually are. There is so much that goes into building sustainable software than just adding some new features. Every team member has different levels of skill with languages, tools, general problem solving, and the understanding of the specific domain. The implications of the application of those skills can have significant impacts, both positive and negative.

Luciano Passuello points out, “There’s much more to mastering a skill than just acquiring more knowledge. Just like adults are not simply bigger children, experts are not only smarter, more knowledgeable or faster than Novices. The differences can be found at a more fundamental level, such as in how they perceive the world and approach problems.”

In Andrew Hunt’s “Pragmatic Thinking and Learning”, he introduces the Dreyfus model and points out that many people never make it beyond Advanced Beginner. This resonates with my experience of 35 years in the software industry. I’ve often been amazed at the surface-level skills demonstrated by someone who has been in the industry for even ten or twenty years. I’ve also often been disappointed to see bright people who don’t shine in their early introduction to programming or a new software development skill who don’t put in much effort to really get it.

My hypothesis is that no one likes feeling clueless, which is where all Novices begin. Some stay Novices because they let their fear of looking and feeling clueless drive them towards activities in which they are more comfortable. But, if they get over that fear (whether through a nurturing mentor or inner resolve) they end up being productive at an Advanced Beginner level. If their new productivity level is readily recognized by others, they begin to feel comfortable again. This often keeps them from pushing through the next, and often larger, barrier to true competence… or at least broader competence.
It is like the Advanced Beginner carpenter who becomes a framer who has learned that if they “put enough nails in it and it will hold”, and then rely on the finish carpenter to cover it up. When I was building my house a master carpenter pointed out the saying, “a little putty, a little paint, makes that carpenter what he ain’t”. There are many good framers that you should never want to hire to do anything else in your house. As long as you recognize what they are good at and what they are not so good at, you will be fine.

In residential housing, the “inspection process” has two real steps. The first step is done (well or not so well) by the person in charge (supervisor, general contractor, et al) and the resulting quality varies by the skills and standards of the person in charge and those doing the work. They are held to a minimum standard by the independent building inspector who knows the rules that have been built up over the years to greatly reduce the amount of bad stuff that might happen in the longer run. Those rules have probably been produced by competent people so even Novices can follow them. If the framing job was done in a week by a novice who had to tear out and reattach every other board, or a couple of hours by an experienced framer, it passes as long as the end result “will hold.”
The rules rarely take into account the expertise a proficient or expert builder may have that may transcend the rules in a given context, but at least they help produce “competent” buildings. Unlike in the world of residential housing, the process of “quality inspection” in software is generally lacking. If the software seems to work, it often ships. The “weight bearing” nature of the code is not given much thought, and bad data entry, or the simplest perceived change might grind the system to a halt, though the root problem might be difficult for other Novices or Advanced Beginners to find and correct. This could be analogous to giving a certificate of occupancy to someone because the walls sitting on a shaky foundation currently seem to be holding up the roof. And when the storm comes, and the house sits in a pile of rubble, the root causes are many, but the poor homeowner has to deal with the consequences and the “professionals” have moved on to other jobs.

Using Advanced Beginners may be perfectly fine for putting together a quick and dirty demo. It can be disastrous for building a system that needs to constantly evolve to meet the needs of its eventual users and stakeholders. An Advanced Beginner doesn’t know what they don’t know. We often see people with 1–4 years of experience calling themselves “rock stars”. We wonder whether the “Rock Star” analogy is a good one for Advanced Beginners. At a superficial level, they seem impressive, but their experience is often shallow. They might focus on appearances and entertaining with the “magic” they wield. Perhaps they build simple demos at amazing speeds. Don’t confuse speed of coding with real progress.

I would challenge investors in start-ups to consider how much of the high failure rate has to do with bad business models, and how much has to do with the make up and approach of their development team. Often one leads to the other, e.g. not enough funding to hire the right development team. But in the infamous words of Red Adair, “If you think it’s expensive to hire a professional to do the job, wait until you hire an amateur.”

I’ve seen many start-ups whose development team was mostly made up of recent graduates of college or coding bootcamps, or retreads from other failed start-ups. In addition to this collection of Novices and Advanced Beginners, they may even have an experienced developer who is Competent or even Proficient. However, they are often so busy meeting with other principals or customers as the Chief Technology Officer or System Architect, that they actually spend very little time in the actual development of the software. These start-ups end up “shipping a demo” which couldn’t satisfy the demand of real users who could have benefitted from a more solidly built piece of software that adapted to the dynamic needs of the target market. Without real customers who realize the real benefit the start-up wanted to deliver, the funding dries up and the “pile of software rubble” is just as useful as a house built carelessly on a poor foundation.

And, by the way, this is not just a problem in start-ups. In some corners of the industry, it is even worse when it comes to internally built software. I know of one company in the insurance industry that has 95% or more of its developers having less than 5 years of development experience. Since management is rewarded significantly better, it is rare to find a Proficient developer anywhere in the company. The cost of maintaining software in that particular company is huge with the number of QA people far outweighing the number of developers. It should go without saying that this company is not known for its innovation in technology or customer satisfaction.

What really matters in building sustainable software effectively and efficiently can be read about in books, but must be proven by actually building, supporting, and growing software that can continue to be supported and grown by others effectively and efficiently.

There are patterns that have been proven to work well in various contexts, and the contexts have to be recognized in real time. There is rarely a single context in any software project. Although there are various catalogs of patterns, it takes a lot of discernment to know what the true context is and whether the pattern fits or the context requires a new or different pattern to be effective. There is no “required reading” in most places where software development is done. Even when there is, without a guide as to when and where to apply what is being read, the application is often unchecked. What might be a powerful technique in certain contexts actually introduces complexity in others. Unlike in most physical building projects, a software foundation can also be malleable and built up as the rest of the hopefully well-built, yet malleable software is built up. But that doesn’t happen when Novices and Advanced Beginners are the builders.

It has been acknowledged by many who have been involved in sustainable software that code is read more often than it is written. Depending on the longevity of the development, the amount code is read (in order to figure out what and where changes need to be made) is greatly increased. If the code is more complex than it needs to be, the impact is huge. If an expert can keep complexity in the code to only what is inherent (and managed well), navigating through the code is simple. But, if it is a jumbled mess, navigation can be a nightmare. And if it is navigated by someone who isn’t very proficient, they are most likely to either reproduce bad patterns or introduce new ones, continuing to introduce more complexity.

Just like poorly built physical buildings, the best thing to do with poorly built software is to demolish it, and start over. Very few people can stomach that. But woe to those who, instead of demolishing it and starting over, try to salvage it and “remodel”. There may be times it is the right thing to do, but there will never be a time that it will be an inexpensive thing to do.

Growing Expertise

At RoleModel, we recognize that producing software is more than just coding and getting cool looking stuff to show up on a screen. (Though, we certainly know how to do that). We know that someone with three years of experience, no matter how well-trained, has not had the opportunity to learn in enough contexts to become an expert in software development. There is a progression of skills that need to be learned and proven in order to become truly proficient or an expert in the context of building software assets. The basic skills range from adding well-defined features in a test-driven manner with intention revealing names to debugging difficult production problems and removing the root cause(s). The more advanced skills range from turning ill-defined requirements into helpful features that users and stakeholders love to determining how to navigate the politics of the company and industry you serve in order to provide real value to both. The level of expertise needed to tackle features or problems is dependent on the inherent complexity of the project as a whole.

If you have properly identified the level of expertise needed to complete a task without significant risk of introduced complexity, everyone does not need to be an expert. Instead you just need to identify the levels of expertise on your team, and assign tasks appropriately.

And, there is a level of expertise needed to identify and manage inherent complexity that may not be obvious to those who do not have the appropriate level of expertise.

Our core values of Character, Collaboration, and Craftsmanship have driven our development of a culture of continuous improvement and service to our customers. We recognize the value of staying humble, not believing our opinion is more important than user feedback. We learn the skills to extract useful feedback from users and stakeholders and only work on the things that provide the highest business value and/or delight the users who may not be like us. We also need to learn from the feedback of those who have produced software before and recognize good and bad patterns in code and approaches to code to avoid introduced complexity.

Only after our developers have mastered all the skills necessary, and proven themselves in real world development, do we recognize them as Craftsmen. This can be a process that takes five to fifteen years or longer. But time doesn’t necessarily make a Craftsman. We’ve made our Craftsmanship Levels Templates available to the industry, and update the scores of our team members every six months or so based on demonstrated results, not just potential. We don’t even call someone a Developer until they have shown competence in our best development practices on software projects (usually internal). It doesn’t matter what degree they might have, we want to see effective delivery. And we want to help them continuously grow in their expertise.

Agility

I was a pioneer in the application of agility and even co-authored the highly acclaimed book “eXtreme Programming Applied” with our own Roy Miller. If used well, agile practices provide feedback loops at all levels of a project to help continuously refine requirements, design, plan, results, and people! But, as Andy Hunt points out in Pragmatic Thinking & Learning, “Proficient practitioners can take full advantage of the reflection and feedback that is core to agile methods.” A corollary to that is that Novices and Advanced Beginners cannot. Although there is never anything wrong with reflection and feedback, two Novices don’t produce expert quality by pair programming.

Some think “agile” = “SCRUM”

But, many who claim to be “agile” are missing a lot of important feedback loops if they just use SCRUM. Some of the practices originally suggested by Kent Beck through eXtreme Programming and refined by many in the industry today are not being employed. These practices matter more, the more inherently complex and long-lived one’s project may be.
The Customer Feedback loop is so important, and I’ll address this in another article soon. But a team that doesn’t have the expertise to take that customer feedback and doesn’t use practices that build it into a sustainable software system is only going to be so effective.

But, many who claim to be “agile” are missing a lot of important feedback loops if they just use SCRUM. Some of the practices originally suggested by Kent Beck through eXtreme Programming and refined by many in the industry today are not being employed. These practices matter more, the more inherently complex and long-lived one’s project may be.

The Customer Feedback loop is so important, and I’ll address this in another article soon. But a team that doesn’t have the expertise to take that customer feedback and doesn’t use practices that build it into a sustainable software system is only going to be so effective.

Yes, there are times when Pair Programming is not the optimal solution to getting two sets of eyes on all production code. However, there are at least as many times when asynchronous pull requests, popularized by Github and its variants, isn’t the optimal solution either. And who should we rely on to know the difference? Certainly not a Novice or Advanced Beginner. The code will only rise to the level of the best developer involved in creating the solution. If you want Craftsman-level code, you’ll need a Craftsman involved in order to keep quality high, and especially to keep introduced complexity low.

A Craftsman Centered Approach

At RoleModel, we basically have three ways we approach projects:

• Craftsman-focused
• Craftsman-led
• Craftsman-supervised

These types of projects often correspond with the various phases of our proven approach of build-measure-learn each step of the way

• Conceptualize — count the cost before starting a project collaborating with stakeholders to make sure we are on the same page.
• Explore — identify key aspects of the system and mitigate high risks through various forms of prototypes and experiments and build a Test-Driven Walking Skeleton upon which we can start fleshing out the application with the most useful features.
• Craft/Rollout — build the software with a continuous delivery of business value getting feedback from users, subject matter experts, software craftsmen, and stakeholders all along the way.
• Sustain — when the desires and efforts to put in new features dies down and the full-time development team is moving on to other things, continuously monitor what is happening with the system and its users making important upgrades and adjustments.

Conceptualize & Explore

Craftsman-focused approaches occur when the inherent complexity and risks needs to be identified and a development plan sorted out. Sorting through this requires a high level of expertise to avoid introducing complexity or missing important challenges. We might put multiple Craftsmen and Sr. Designers/Developers on it. This is almost always true at the beginning of a project and, depending on the inherent complexity, it may continue to be necessary to have a higher percentage of Craftsmen into the Craft/Rollout phase, but usually, enough has been sorted out to proceed as a Craftsmen-led project.

Craft/Rollout

Once it is clear what we’re building, where the inherent complexity is, less expert developers with good sustainable software habits can be brought in.
Craftsmen-led approaches typically have one craftsman allocated full-time and other developers/designers of various levels. (The ratio of Craftsmen to less experienced developers will change based on the inherent complexity of the project). The development plan is typically fairly well sorted out, and the Craftsman is there to handle the hardest problems and make sure all the other contributors don’t unwittingly introduce complexity.

Craftsman-supervised projects typically have a small team of appropriate skill level with a Craftsman who checks in and has their back. These are typically projects that are not adding significantly complex features and the work often includes making minor adjustments.

At RoleModel, a new software system often starts as a craftsman-focused project and evolves into a craftsmen-led project and then possibly a craftsman-supervised project when the major features are in place. Proficient and Expert developers use the feedback they get throughout the software development process to refactor code to increase clarity, performance, quality, supportability, and extensibility. Doing it this way minimizes the amount of introduced complexity. As new opportunities arise, new or simplified features can be added with confidence. The cost/benefit analysis isn’t encumbered by an inordinate amount of “technical debt” that needs to be paid down in order to move forward.

However, we have seen that software systems are sometimes created in the opposite way. An Advanced Beginner may start a project and “get it to work” and the system that goes into production is full of introduced complexity and has not addressed some challenges. We’ve had potential clients bring these kind of systems to RoleModel hoping we can “finish it” or “fix a few problems” who are surprised to hear that they’ll need experts for an extended period of time to sort through the mess. Instead of being in a place where they can easily grow the system, they are in a very scary position of finding out their system is on a shaky foundation that needs to be carefully engineered to avoid breaking what appears to be working. The money “saved” up front is completely lost as the amount of “technical debt” that needs to be paid off is huge. Think of it as paying 30% interest on your credit card while you are struggling to make your minimum monthly payments and you are already at your credit limit.

Sustain

Our Supportability Scorecard is a tool we use when software we build goes into production and we continually revise it. We verify that we have all the important monitoring tools, tests, and documentation in place in order to get a good to excellent score. When new features are desired, we can move it forward if the original developers are not readily available. This can be done with a Craftsman-supervised approach for simple features or in a Craftsman-focused approach if managing the inherent complexity needs more expertise.

If someone brings us software that we didn’t create (or perhaps we created an earlier version and someone else took it from there with less care to important details) we would first score it and then give the client an estimate of what it would take to get it up to a passing (or better) score. Then, we analyze what the available monitoring tools are telling us (along with some manual inspection) and help the client understand their risks in both keeping the system going or improving it as they might come to us complaining about some problems their users are having.

We prioritize getting the system up to a sustainable score and determining a plan to help move the system forward in both sustainability and meeting new customer demands. The scariest situation is when automated tests are missing. The danger of breaking something (or a lot of things) are huge, and the effort to make sure no one does is very expensive… manual tests of the entire system or the chance that existing users will not be able to perform what the software was supposed to deliver. We’ll slowly build up automated system tests until we can reduce the number of necessary manual tests to a reasonable level of risk.

Agility and Expertise from Concept to Production

There is a wide variety of software and many ways to approach the building of it. Through years of honing our craft, building software systems that stand the test of time, and observing the consequences of poor practices or under-skilled software leadership we’ve come to recognize the value of both agility and expertise throughout the software lifecycle.
Using the word “agile” and even doing some of the accepted practices is not enough.

If you are looking to invest in what you hope will become a long-lived software asset, make sure you have both agility AND expertise. If your so-called experts haven’t supported software in production and don’t advocate a set of automated tests, preferably test-driven, be afraid. Be very afraid.

Agile Roots

In 2011, Venture capitalist Marc Andreessen famously said that software is eating the world. His idea is that software enables people and companies to do their jobs better and deliver value faster. These software-enabled companies are more agile than companies that don’t use software (or don’t use it well), and this agility enables them to move and pivot faster. As a result, software-enabled companies will win in the long run. Eventually, using software well will be a basic requirement of entering the marketplace. If you’re not doing software, you’re going to lose.

Just as software enables agility, developing software in an agile way outperforms traditional, planning-heavy methods such as the waterfall approach (as RoleModel Software’s founder and CEO, Ken Auer, lays out in his book). Agile responds better to change and change is almost always required. Agile methods such as Extreme Programming, Scrum, and Kanban are gaining mindshare among professionals and at many companies Agile methods are accepted as the way work gets done. At RoleModel Software, we believe that agile software wins and that an agile, collaborative approach will be “table stakes” for companies competing in the marketplace. In short, if you’re not doing software in an agile way, you’re going to lose.

What does this have to do with DevOps? Bear with me for one more context-setting excursion.

The System of Software

Have you ever thought about what software is? Or what is the essence of software? I think software by itself is inert: it’s just bits on a disk somewhere. It needs a system to make it run. That system involves many separate pieces all working together to animate the software. Most software systems, or at least most web applications, include:

• libraries written by other people
• frameworks written by other people
• programming languages and compilers
• web servers and web browsers
• database servers
• operating systems
• machines, whether physical or virtual, with all the associated hardware
• networking infrastructure, including load balancers, routing, SSL, firewalls, domain names, etc.

The point is that there’s only value in software when the broader system works together.

DevOps addresses this question: How do we apply the principles of agility not only to the development of the software, but also to the development of the system?

Development + Operations = Success

At RoleModel Software, we believe we are most effective when we work alongside our customers, understand their experiences and their needs, and collaborate with them on how best to solve their problems while recognizing their context and priorities. This is exactly the idea behind DevOps. Except with DevOps, the people who are collaborating are not consultants and customers, but software developers and IT people. That’s where the term “DevOps” comes from: it’s a combination of Development and Operations.

In many organizations, especially those that still think of software as a thing to be constructed, like a building, there is a divide between Development and IT Operations. Their idea is that Development should focus on the software and IT should focus on the system, including ongoing monitoring and management responsibility. Unfortunately, a strained if not outright adversarial relationship often results from this division. When things go wrong, it’s easy to point fingers across the aisle without understanding the other side. This breakdown of trust often results in setting up additional heavyweight processes, such as testing and quality assurance, on the pre-deployment side. Deployments become a rare and dreaded occurrence on a quarterly or even yearly basis.

The idea of DevOps is to bring the collaborative, agile software mindset to the IT department. Developers work to understand the problems that Operations faces and they then collaborate to build tools, automate processes, and solve problems. The developer gains an appreciation of the system and can apply software, the “world eater,” to improve it.

The goal is to improve the agility of the software system in the same way software has improved the agility of people and businesses everywhere. Then the DevOps-enabled companies can outperform their competition. They respond to changes in the marketplace faster, get feedback from experiments faster, and even fix bugs faster.

If DevOps is done well, the flow of work from development to production is unimpeded; there are no operational bottlenecks that constrain the flow. The only constraint is the number of developers working on the software. As a result, the number of production deployments can go from one per quarter to many per day. Deploying new code to production becomes a routine, everyday occurrence. A hallmark of effective DevOps practices is that the number of production deployments scales linearly with the number of developers, even with tens of thousands of developers. (This was an unreachable goal 15 years ago!)

Proof that DevOps Works

All the software companies that are household names already do DevOps; indeed, many of them pioneered these practices. That includes Google, Facebook, Amazon, and Netflix, each of which does multiple production deployments per day. In some cases the rate of change is staggering. In 2015, Amazon revealed that they were doing 130,000 production deployments per day. That’s more than one per second. And that was in 2015. Correlation doesn’t necessarily imply causation, but I believe DevOps is a large part of why they’ve been able to grow as big as they have.
Furthermore, many analysts have picked up on the fact that DevOps-enabled companies are outperforming the rest. Studies have shown that these companies tend to have much better key performance indicators, ranging from technical (reliability, security, mean time to restore service) to corporate (employee job satisfaction, profitability).

What it all means

If you’re not currently developing and delivering software systems in an agile way, you’re probably losing. The practices of DevOps can help. RoleModel Software has a history of agility and collaboration and we would love to help you. Consider us for your next custom software project! (And please leave a comment on this post!)

Thanks to Phil Puccio. 

• maximizing communication efficiency;
• maximizing code design quality; and
• minimizing rework.

The last two options on that continuum are flavors of pair programming (or “pairing” for short):

• Pair program with another person only at certain points while writing the code (opportunistic pairing).
• Pair program “full-time” with another person while writing the code.

We define pairing as two developers/designers working on the same code on the same machine at the same time. Yes, the same machine, at the same time.

You’ve probably heard of it, or you may have done it. Unless you’ve been asleep for at least the past decade, though, you’re probably aware that pairing is hotly debated among people involved with software development. You’ll find vocal detractors and defenders without looking too hard. Which opinion is right?

We frequently side with the defenders, with one caveat: Pairing only makes sense when it makes sense. We don’t do it all the time. We’ve had great results with it when it made sense, and we’ll gladly defend it as a practice in those cases. As the African proverb says, “If you want to go fast, go alone. If you want to go far, go together.”

The objections to pairing aren’t new. In fact, most are reasonable, given the perspective of most software development project managers. One blog post isn’t enough to cover every nuance, but we can address some of the most common objections and give our perspective on how accurate they are.

“It’s twice as expensive.”

Despite what vocal devotees of pairing claim, this is reasonable point. It makes sense for a manager to critique the additional cost of having more than one person work on the same code at the same time. The problem with the objection is that it ignores (or seriously discounts) the economic gain of pairing, and it exaggerates the costs.

The economic gain of pairing comes from four primary sources:

1. Two heads often are better than one, which improves your code design, which often makes code easier to change later with fewer side effects. That reduces the total cost of ownership of your software.
2. Pairing is like a constant code review, but with all of the necessary context to make that review excellent. This leads to fewer bugs, which often cost a boatload to fix later.
3. Sometimes (not always), having more knowledge spread across the team can make the entire team faster, which reduces the time to value ratio for the software.
4. Nearly all the time, having more knowledge spread across the team lowers risk by reducing the team’s “truck number” (the number of people who have to be hit by a truck before the project fails).

The challenge is quantifying that economic gain, because true comparisons aren’t feasible. How many companies do you know who are willing to do the same project twice, once with pairing and once without, and then compare total costs? We don’t know any.

Even if that comparison were possible, it still wouldn’t be entirely accurate, because you’d need the same team to do the same project twice so you could measure the independent effects of pairing. But the team would be smarter after doing it the first time, and the approach they used for the second try would benefit from that. It’s not comparing apples to apples.

Our experience tells us two things:

1. the benefits are real when we compare similar projects done with pairing and without it, or with more or less pairing; and
2. the costs of pairing can be, and often are, offset to some degree by the economic gains (i.e., a pairing project shouldn’t cost two times the non-pairing variety).

In fact, some empirical research shows pairing adds about 15% overhead cost (not 100%), but reduces defects by about 15%, which can lower overall cost of a system. You need to decide which costs more. It could be a wash, which would suggest that the other upsides of pairing could add up to a non-trivial economic benefit for your organization. (see https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF)

“It’ll slow down the team.”

It might, at least in the short term. Pairing takes time to get used to. Knowing how to be a good “driver” and a good “navigator” (the two pairing roles) takes some experience. With practice everyone on the team can be good enough at pairing to reap the benefits.

Many objections about team speed miss two important points:

• software development isn’t primarily about speed, it’s about quality and lowering the total cost of ownership of your software over time; and
• many teams aren’t going as fast as they think they are without pairing, because they kick problems (like bugs) down the road instead of dealing with them before they become issues.

In our experience, pairing can increase team efficiency and quality. We’ll trade that for a near-term speed bump while developers on the team increase pairing skills.

“Developers don’t/won’t like it.”

This depends on the developers.

There is no denying that some developers detest pairing. They’ll quit rather than do it. If you have enough developers like that, you can choose not to use pairing. You might want to consider, though, why your developers are so opposed.

We often find that opposition comes from two common sources: developer arrogance and fear.

Genius jerks are common in software development. They believe they’re better than others, and being forced to pair with developers of lesser skill damages the genius’s ability to produce. They may be right. Perhaps they really are that much smarter than the rest of your team. Then again, maybe they’re unjustifiably arrogant. Pairing should prove which it is. Nothing humbles a developer like having a pair point out something he missed, or hasn’t thought of, or is mistaken about. If you have arrogant team members, it might be time to encourage them to move on.

Fear is every bit as common. Writing code is hard. It can be challenging to keep current on everything you need to know. No one wants to be embarrassed, so developers often use solitude as a defense. If nobody sees your code, nobody can judge your code before you want them to do it. But do you really want terrified developers on your team, or do you want a team of people who build each other up and become more confident over time? We’d rather have the second one.

“Pairing on everything wastes time.”

Agreed, so don’t. Pair when it makes sense. Don’t pair when it’s not smart to do so. For example, pairing on research doesn’t make sense. Split up, research, then come back together to compare notes. That’s a good use of time.

We’ve never recommended pairing on every task. Sometimes you don’t even have to pair when writing code, although we very rarely release any code without two sets of eyes on it, either via pairing or code review after the fact. Objecting to pairing because it’s not a good activity for some tasks is objecting to pairing done wrong. We object to that, too, but doing it wrong isn’t the only option.

“We have developers with different skill levels.”

We’d be first to admit that a team with large skill disparities can have trouble pairing effectively. You’ll typically end up with essentially a driver and a passenger, or maybe a backseat driver (where the navigator tells the driver what to type). Neither situation is good in the long run.

This can be a temporary problem, though. Those with lower skill will raise their skill level over time. It doesn’t happen overnight, but pairing with those of a higher skill level can ramp up people’s skills rapidly, much faster than sitting in a classroom. That will pay off for the team, maybe sooner than you think.

Note that this assumes your higher skilled people are good teachers. That’s not a given. If they are, your team can probably handle the wide gap in skill levels. If they’re not, the team could suffer.

“We can’t force developers to pair.”

Managers often say this, and it’s true. Some people refuse to pair. Managers shouldn’t dictate pairing as “the way we’re going to do things from now on.” It probably wouldn’t work if they tried.
That said, a smart manager might drool over the potential benefits of pairing and wonder how to get folks to do it. The short answer is that you can’t force anything. Here’s where you face a decision, and what you do depends on your role:

• If you’re a leader with enough pull to make it happen, you can select people from your existing teams who want to pair and make a pairing team full of folks who like to work that way. Maybe their results will be so great that other jealous teams might make the switch.
• If you’re a manager without much influence, you can encourage developers to pair.
• If you’re a developer who wants to pair, but your team is full of people who don’t want to, you can try to change their minds, or you can change your team.

If you think pairing when it makes sense is the right way to go, you may have to fight for it.

Beyond objections

Pairing won’t magically fix what ails a team. It’s not the wisest approach in certain situations. It’s not something every programmer wants to do. It’s also not something management can impose on unwilling participants. No silver bullet here.

That said, we favor pairing over the other approaches because it tends to maximize communication efficiency, maximize code design quality, and minimize rework. If you’re interested in those things, try pairing when it makes sense (which might be more often than you think). The results might surprise you.

The Trouble with Upfront Estimates

When customers come to us and explain the problems they would like to solve with a custom software application, both parties need to make a number of simplifying assumptions to come up with a traditional estimate.
As a business owner, you are likely coming to a company like RoleModel because you aren’t yet an expert in world-class software systems. Without that background, it can be hard to understand why some things are easy (e.g. changing a page’s layout) and others that seem like they would be easy are more difficult (e.g. switching data source).

With custom software, there are many ways to approach solving a problem and it can be difficult in the early stages of discussion about a project to recognize what the flaws might be with the different approaches.

There will also be edge cases (things that are not part of the happy path through the system) which must be considered and estimating those can be very difficult. At times solving the edge case will be critical to the operation of the system and other times it’s a small preference, but not worth the cost to address immediately. Sometimes this means bubbling the edge case up as an error or building a new UI or workflow to address it. Another case might be leveraging external tools that can’t be fully customized, but address most of the problem rather than having to build the solution from scratch.

Allow for Learning

Regardless of the identified assumptions, made by both the client and us, we know from experience that customers will uncover and refine the business objectives for the application as they interact with initial iterations of working software. When you have first used a new version of a piece of software, you’ve probably experienced a “you know what would make this even better . . .” moment.
Even though software developers have many tools at their disposal for visualizing proposed solutions, some things can’t be simulated with wireframes or event prototypes. In order to refine the core workflows, a customer needs to interact with the application in the context it will be used to understand what is missing. This is why we work in an iterative style with short feedback loops.

But one question still remains: Is it our goal to steer a client toward the simplest and most cost-effective solution, or is it to rely on the customer’s goals to build what they believe to be a valuable solution?

Starting Small

Given this paradox, how do we navigate through this uncertainty?
Our proven approach at RoleModel is to start each project (and a new push for a project) with Planning and Exploration. During this initial phase, which could be days or weeks, we focus on identifying the areas of unknowns and biggest risks, while also focusing on delivering some spikes and functional prototypes of working software to help us and our client define the next steps in the roadmap.

We do this through User Story Mapping, Wireframes, Clickable Prototypes, Technical Spikes, and Functional Prototypes with the goal of defining a direction for the next phase of the project and building a Walking Skeleton (a rudimentary version of the system end to end). That direction may change as we learn more along the way, but serves as a basis for our collaborative decisions with our client.

With that baseline of rudimentary working software, we can better estimate new enhancements or features. It also allows us to mitigate the risk of building the wrong thing as we get feedback from the users and the Product Owner on working software along the way. In the end, this gets us to a solution that will provide value to users by leveraging our learning throughout the project.

Have a concept you’d like to pursue, but want to get a better handle on the scope of the project? Let’s talk about your project and see if a Planning and Exploration phase gives you the next step you need.

There’s a continuum of options. If you’re the person writing the code, you can do the following:

• Have an email conversation with another person about the code after you write it.
• Have another person review your pull request (PR) asynchronously.
• Have another person review your code synchronously after you write it.
• Pair program with another person at certain points while writing the code (opportunistic pairing).
• Pair program “full-time” with another person while writing the code.

So, which approach is best? There’s no single right answer, but we can trace some themes which will help us answer the question.

Generally, we favor a "two sets of eyes" approach, which:

1. maximizes communication efficiency;
2. maximizes code design quality; and
3. minimizes rework.

You might graph them like this:

The closer you get to the email end of the continuum, the worse it is for communication efficiency and design quality, and the more likely it is that you’ll be reworking your code. The “full-time” pairing end of the continuum wins for all three dimensions. It’s not hard to see why. (Our evidence is mostly anecdotal, but it’s consistent for the last two decades.)

The first three options have something in common: They are code reviews after the fact. It’s written already, then somebody else looks at it. That often causes problems.

First, it’s extremely inefficient communication. You’re writing the code, somebody else looks at it after the fact and renders an opinion. They missed every thought you had while you wrote the code. They have no idea why you did what you did, beyond the basic syntax you chose. A reviewer can ask you why you took the path you did, but then you have to spend time explaining what you already thought about, which might be fuzzy after the fact.

Email is the worst example of this. Years ago, Ron Jeffries used to say that his innate wit and charm doesn’t come across in emails. Neither does design intent, problem analysis, nor non-verbal communication. It’s hard to imagine a worse way to make sure code is well written. Maybe smoke signals.

Second, you had zero opportunity to talk to someone else when you were designing the code in the first place. Sure, you could’ve spoken to one or more people when you started, but they weren’t with you along the way. The reviewer might give you lots of good input about design, but then you run into problem number three.

Third, you’ll very likely have to rework your code. Potentially a lot. You might even have to start over.

How effective does this sound? Not very. The first two options suffer from all of those issues. The third option (synchronous code review) fares a little better, because at least you don’t have inefficient communication with the reviewer, but it’s still after the fact, which compounds the other problems.

The last two options fare better. They’re both flavors of pair programming. We’ll spend all of the next blog post talking about that, but in a nutshell, pair programming (or pairing, for short) is two developers working on the same code on the same machine at the same time. Them’s fightin’ words in some circles, so we’ll wait until next time to dive in. For now, consider how each flavor of pairing looks for communication efficiency, design quality, and rework.

Pretty good, we’d say, most of the time.

Your communication about nearly all code matters is instantaneous. No waiting for a reviewer to share thoughts after the fact, no rework once the reviewer gets done rendering an opinion. It’s like a constant code review going on, while you’re writing the code.

Your design quality is likely to be better, too. Two heads often are better than one. One person’s brain fog doesn’t necessarily stop his pairing partner from coming up with a good idea and getting the pair unstuck. One person can challenge faulty assumptions of the other, pay attention to details the other person missed, suggest creative solutions the other person didn’t think of.

Last, but not least, you’ll probably have to rework your code far less than if one person writes it alone. If a third person reviews code that the pair wrote (or fourth, etc.), that person might see a flaw they both missed, but hey, we have to draw the line somewhere. We still have seen a third reviewer find far fewer bugs than if one person wrote the code alone.

That’s why we favor pairing over other asynchronous approaches. It’s simply better at addressing the three things we want to optimize for. Opportunistic pairing is often a good approach if a problem is relatively straightforward, and a person writing the code needs help at strategic spots. “Full-time” pairing (remember those quotes) is often better when a coding problem is particularly hairy, or big. Either one beats email reviews six ways from Tuesday.

Next time we’ll talk about what pairing is, and is not. And we’ll evaluate some of the most common objections to the practice (there’s no shortage). Make sure to leave your comments if you agree/disagree?

Kevin Bridges

On May 23, one of those exceptions, Kevin Bridges, went to be with the Lord after a battle with cancer. Although I didn’t know Kevin well, he had a huge impact on me and many others I know. Allow me to fill in a few details.

In September of 2012, I was pleased to get a call from Kevin. Kevin was the Director of IT at CollegePlus and I was anticipating another great update about what was happening there with his young team.
I had met 2 of the 3 founders of CollegePlus years back in 2000 and we had several conversations about how to build their IT team. In 2011 they hired Kevin who, based on the founders’ input, contacted me for some advice. Kevin wanted to recruit some help to improve their PHP approach. When I challenged him on why he was choosing PHP, we had some great discussions about good software engineering practices. I was impressed by his humility and teachability. I have had far too many interactions with IT Directors and CIOs who aren’t really interested in learning what it takes to build good software.

A few months later Kevin called me up. He was excited about the fact that they were moving all of their new development to Ruby on Rails with a focus on TDD, had started an apprenticeship program, and they were already seeing great results. I was skeptical of what they would accomplish with such a young, inexperienced crew. But every few months after that, I’d hear more from either Kevin, or someone like Dave Hoover who had visited their team. It was amazing how this young team was revamping their IT and building a series of small applications, serving more and more of CollegePlus’ operational and customer needs.

Meeting Caleb Woods

In September of 2012, I received a call from Kevin that was very different from our previous conversations. It was brief and to the point. Kevin informed me that CollegePlus was undergoing a significant reorganization and that he had secured a new job with USAA. He was doing OK, but wanted to let me know that, “All the success we have had was due to one young man, Caleb Woods. Everything we’ve done was his idea, and he is the one who has made it all work. Caleb has decided he is moving on, and I think if there is any way you can create an opening at RoleModel, you should hire him.”

With that recommendation, I knew I should at least talk to the young man.

I got on the phone with Caleb and found out that his career goal was to help other people solve their business problems with technology. I was totally impressed with his poise, his confidence, but also his humility. Caleb wanted to work with a company where he could continue to grow both his understanding of software development and of business. He also wanted to learn how a software consulting services company operated. Caleb wanted a place where mentorship was part of the culture, and he could participate bi-directionally.

I decided to fly him and his fiancé up to North Carolina because I didn’t want to miss the opportunity that sounded too good to be true. We spent a few days together and I wasn’t disappointed. He was certainly unique.

Patient Nurturing Produces Accelerated Results

Last year, I wrote an article about Farming for Software Talent. I pointed out how one needed to find good seed and nurture it. Not only has it worked well for us in growing our software talent, but it worked in growing our leadership team. Caleb Woods was the quality seed with the potential to run a software technology services organization.

The most important thing is not the specific steps along the way, but the patient, steady and deliberate path of the nurturer(s) and the nurtured. Last year, RoleModel announced the promotion of Caleb Woods to Chief Technology Officer.

Like most people, I want to find great solutions for any of my challenges the minute I encounter them. But time and time again, I realize that the best things come from starting with a concept, taking deliberate steps, retrospecting, and continually improving. You don’t build industry-changing software overnight. You don’t build a great team overnight either. But with patient and persistent mentoring, you can accelerate the growth curve.

Contributions to our Sustainable Growth

RoleModel is at the beginning of its 22nd year. We have learned a lot over those years. A couple of times the company shrunk to the point where I was the only employee. The concept of what we wanted to be was there when we first started. We’ve built, measured, and learned. Last year we finally made the Inc. 5000 as one of the fastest growing privately held companies in the U.S. Our goal has never been fast growth, but sustainable growth. Caleb Woods shares that vision, and I’m thrilled to have him on our leadership team. I’m even more thrilled to work with him and the rest of our team to farm our talent and build our culture of character, collaboration, and craftsmanship.

But none of this would have been possible without Kevin Bridges. Kevin saw talent in a young man. Kevin encouraged him, mentored him, challenged him, and prayed for him. Caleb, and many other young men who were impacted by Kevin, went to his memorial service. They recognized the great privilege they had been given, the lasting impact of his mentoring, and Kevin’s encouragement to “be excellent”.
But Kevin was wrong about one thing. The success at CollegePlus wasn’t because of “one young man”. Caleb recently told me that although he has learned and done so much at RoleModel, the 18 months he spent under Kevin was something incredibly unique. They successfully built the foundation for the infrastructure that is still being used at CollegePlus (now Lumerit). It was all done by an incredibly young and inexperienced team, led by Caleb Woods, but gently guided, challenged, encouraged, and refined by one amazing mentor.

Though RoleModel has a culture of mentorship that raises up much of its own talent, we are blessed to have two of Kevin’s proteges in our ranks. Mark Kraemer joined us in 2016 and exudes our core values of Character, Collaboration, and Craftsmanship. I’d love to have more.

And the industry would be much better off if there were more Kevin Bridges.

RoleModel Software’s new Ruby gem — Marshgrass — is designed to address the challenge of finding intermittent test failures in Ruby code. This gem allows you to subject an intermittently failing test to a variety of circumstances in an attempt to discern what combination of events leads to failure. Using Marshgrass increases the odds of quickly finding the root cause of an intermittent failure, so that it can be fixed in a fast and cost-effective way.

The first step in fixing an intermittent failure is uncovering the set of circumstances that makes it fail consistently. In programming there is no such thing as a truly “random” failure. Under the right set of circumstances, every intermittent failure will fail consistently.

Marshgrass functions as an “add-on” to the Ruby Rspec test runner, boosting Rspec’s ability to more consistently cause intermittent failures to occur. Marshgrass can subject a test to any one of the specific conditions listed below:

• Repetitions
• Range of speeds in execution
• Execution at all times of day
• Execution in all time zones
• Execution at all the milliseconds surrounding a particular time of day

The gem is available as open source under the terms of the MIT License. See the README for usage instructions. Bug reports and contributions are welcome on Github at https://github.com/RoleModel/marsh_grass. We invite you to try the gem for yourself and let us know what you think.

Summary

Heroku recently announced their container runtime, which enables deployment of docker images to Heroku. The overall experience is on par in terms of features and ease with the traditional approach, which uses the slug compiler. It enables greater flexibility and control of your software system, but you assume the responsibility to maintain your system and keep it secure. This post discusses the tradeoffs and reasons to favor one approach over the other.

Background

At RoleModel, Heroku is our default choice of platform. We’ve found that it consistently saves us significant time in setting up, deploying, and managing the infrastructure that our apps run on. In our mission to deliver value to our customers via software, we’ve found it to be a net win in most cases: the cost of the platform is less than the cost of our time managing infrastructure with a cheaper provider like AWS.
We are also increasingly taking advantage of Docker in our projects, as it affords good isolation of development environments without sacrificing performance. Similarly, Docker Compose enables us to specify the entire software system context of one of our apps, making it easy for a developer to spin up on a new project and switch between projects, even those with different versions of tools such as Ruby, PostgreSQL, or Node.js.

When Heroku announced their container runtime in October, 2017, we wanted to take a closer look to see if this offering might be an excellent fusion between Docker and Heroku that would deliver value to our customers faster.

Heroku’s container runtime

The standard deployment to Heroku involves a snapshot of the code in a repository at a given commit. There are two approaches. First, you can use git to push a git commit to a git remote that Heroku owns. Second, you can use Heroku pipelines and Heroku review apps, which are associated 1-to-1 with GitHub pull requests and are aware of new and updated pull requests through GitHub integrations. In either case, Heroku learns of a commit and invokes the slug compiler to create a “slug” for the code at that commit. A slug is analogous to an image in Docker: it contains a static snapshot of everything that will be needed to run the app. The slug compiler identifies which language and framework is being used and invokes the appropriate buildpack to fetch language libraries and package everything together.

Heroku’s new container runtime offers an alternative: you tell Heroku which Dockerfile in your repo to use for build instructions. This approach will be familiar to Docker users, because Dockerfiles are the same mechanism Docker itself uses to build images. Heroku can then build and deploy your docker image instead of a slug.

Note that we are using the container runtime in conjunction with the Heroku build manifest (i.e. heroku.yml). The build manifest, which is currently in developer preview, is what enables Heroku to build and deploy the docker image itself. Without it, many features such as pipelines, review apps, and the release phase are not available with Docker-based deployments.

Comparison

We were interested to know how the container runtime compares with the more traditional approach of the slug compiler and language specific buildpacks.

Similarities

In many ways, the two approaches are identical. In both cases,you can see that “developer experience” or “DX” is a strong value to Heroku. Here is a list of things I tried that behave the same way, modulo minor differences like whether to specify a configuration setting in Procfile or heroku.yml:

• The Heroku CLI, including: heroku open to open the deployed app in a browser; heroku logs, which are as helpful as ever; and heroku run bash to run a shell in a production environment isolated from the “dyno formation” of running servers, for things like database migrations or access to a Rails console.
• Heroku addons, including Heroku Postgres, HoneyBadger, and New Relic, all of which we specifically tested.
• The Heroku dashboard, including configuration and environment variables.
• Pipelines, for a sequence of related apps from staging to production.
• Review apps, which are automatically provisioned and track 1-to-1 with GitHub pull requests.
• The Release phase, which enables things like database migrations to run whenever a new release is created for your app. (The postdeploy steps in app.json work too, although this is not recommended because the postdeploy steps will not be re-run in a review app when new commits are added to the corresponding pull request.)
• GitHub integration, so that review apps in a pipeline can be automatically provisioned and the production code can be continuously deployed from a branch.

Differences

When comparing the container runtime and the slug compiler, the similarities far outweigh the differences. Nevertheless, it’s worth mentioning the differences too:

• Assuming you want Heroku to assemble your code into something runnable, instead of the traditional Procfile, you use the new build manifest at heroku.yml, which is structured a bit differently.

Note: The build manifest documentation says that you can specify commands to run before or after compilation with pre and post keys under the build key. However, as of March 29, 2018, these commands are silently ignored when using a build -> docker key to specify docker-based builds. This behavior is not presently documented, so I wanted to mention it here.

• It’s possible with the container runtime to deploy code without creating a git commit by saying heroku container:push.
• One feature that the container runtime doesn’t currently have, even when combined with the build manifest, is pipeline promotions (we don’t often use this feature, so it is not considered a great loss). I suspect Heroku is working to make them available to container-based deployments too, however, so this may change in time.

Analysis of the container runtime

Advantages

The container runtime has two advantages over the traditional slug compiler and language buildpacks. First, if you’re already using docker in a development environment, you can achieve better parity between the development and production environments. Second, you can have better control over how your software is built.

However, the quality of the standard Heroku platform has eroded some of these advantages. Parity between development and production environments is valuable because it can avoid problems that only surface when deploying code to production. But such issues almost never happen with Heroku because the platform is designed and engineered well to avoid them. Greater control over the build process is not something we’ve felt a need for when using Heroku. The official buildpacks work sufficiently well that we have never needed to debug or customize them. If you have felt this pain and wrestled with Heroku to get your app deployed then these advantages might be compelling.

Disadvantages

The primary disadvantage of a container runtime is the classic tradeoff between increased control and increased responsibility. When you use the traditional slug compiler and default Heroku stacks, Heroku is responsible for noticing relevant security updates, upgrading their stacks, and migrating your app to the upgraded stack. When you use the container runtime, Heroku cannot do these things for you. The responsibility falls to you as the application maintainer.

For short-lived apps or apps where security is not important, this is not a problem. But at RoleModel many of our apps don’t meet these criteria, and we actively benefit from Heroku’s vigilance.

Recommendation

As we at RoleModel have learned from the Dreyfus Model of Skills Acquisition, the best course of action depends on the context and the goals. So, while the container runtime might not be a great fit for many of our projects, perhaps your situation is different. Consider using the container runtime when:

1. you have experienced problems or anticipate problems related to the disparity between your local development environments and the production Heroku environment;
2. you believe that there is enough value in available Docker images to forgo the conveniences of Heroku’s stacks and buildpacks; or
3. you spend time or anticipate spending time wrestling with the constraints of Heroku, for example in one of these ways: (a) you use an unusual language that has no officially supported buildpack, like Elixir (although note that there are many third-party buildpacks, including one for Elixir); (b) you need Ubuntu packages beyond what’s already installed on the official stacks (although note that the heroku.yml build manifest and other approaches can also solve this problem); (c) you use a combination of languages in your app (and you don’t want to use multiple buildpacks); or (d) you need to use a non-Ubuntu flavor of Linux for some reason.

However, if you choose the container runtime, remember that you must assume the associated maintenance responsibility. For this reason, if you don’t have a compelling use case for the container runtime, we recommend the traditional stack as a default.

Have you had any experience with using Docker on Heroku? We’d love to hear about it. Please leave a comment below.

Defining software quality is kind of like defining beauty — “it depends.”

Most people involved with developing software agree that “high-quality” means creating a system that does what it’s supposed to do without any strange side effects, and provides an experience that users rave about.

But how do you get there?

One option is to hire a phalanx of testers to check stuff after you’re done coding. That’s not a bad strategy. Testing after the fact certainly catches code bugs and glitches in the user experience. We recommend testing, even testing after the fact.

But there is a smarter strategy that helps you catch problems before testers ever put your software through its paces. This strategy saves time and money. We call it “two sets of eyes.” In a nutshell, it means to have at least two people look at the code to make sure it:

• is as simple as possible to get the job done;
• includes tests and passes them all;
• delivers on what it’s supposed to; and
• clearly expresses to a competent developer what it is trying to do.

It’s not rocket science. It’s more about discipline than super-human intelligence. And more than that, it’s a conversation about the code. The code that one person writes may work fine, but having a conversation about the code early in the development process often refines the system’s design. This process adds a nice layer of accountability too, encouraging the delivery of complete features (well written code, tests, documentation, etc.).

Code tends to be less than it could be when only one person looks at it. It’s often more complex than necessary. It’s often buggy. It’s often shortsighted. It may seem perfectly clear to the person who wrote it, but not so clear for the first person that reads it. Software code is read far more than it’s written.

We never release code “into the wild” unless more than one person has looked at it. (Okay, we do it sometimes in very rare cases). We are craftsmen. We take pride in our work, and our work is our best advertisement. Even if the only reason to use two sets of eyes was to increase confidence in what we create, we would embrace the practice. We simply won’t compromise on the two sets of eyes element of our craftsmanship. That goes for the software we make for ourselves and we produce for our customers.

We follow the two sets of eyes rule because it reduces business risk. Fixing bugs, or correcting misses in whatever form they take, is easier and cheaper the earlier it is done. We like to fix bugs as close to the act of writing the code as we practically can.

We also have good business sense and have found that code analyzed by two sets of eyes is very likely to cost less. It sometimes costs less to create (although that’s very hard to confirm), and it almost always costs less over time for these reasons:

• The code is better factored, so it’s easier to change (and what system doesn’t need to change over time?).
• The code is better tested, which means we can change it more confidently, knowing that we didn’t break anything in our system.
• More people on the team are familiar with the code, which means our risk of losing the “one person” on the team who understands the code drops significantly.
• Having a second set of eyes guarantees at least one other person on the team can read what the writer wrote and intended.

Regardless of the approach, having two sets of eyes on all code we write helps us reduce business risk, reduce system cost, and be more agile as systems we create change over time. Everybody wins.

That’s why we recommend this practice to customers and colleagues.

In two weeks, we’ll continue this 3 part series by discussing the forms that two sets of eyes can take, and why we prefer some forms over others.

Many in the industry want to mine talent. When one mines, one looks for a resource-rich place and starts digging. That doesn’t work very well when it comes to developers because the best talent is in places that:

1. appreciate what they have, and
2. can afford to pay them reasonably well.

There’s a better, less popular method: Farming for talent.

Farming has a few similarities to mining. It is the same in that you have to pick the right location or you won’t get good results. It is hard to farm on a rock, just like it hard to mine on a piece of ground that has no valuable resources under it. There is some preparation you need to do. But after that, it is very different.

A successful farmer needs good soil, good seed, and a way to provide nutrients. Then comes a lot of hard work, wisdom, patience, attention to what is happening with the crop, and a hopeful harvest.

Farming is hard work. It requires lots of risk, lots of patience, lots of know-how, lots of investment. But there is something significantly different about farming than mining. The fruit of farming produces both a result and seed for the future. If done well, it has a multiplicative effect rather than a subtractive one.

Because of our nation’s strong farming history, we enjoy an ample supply of food filling our grocery stores and restaurants.

But because the software industry has preferred mining to farming, there is not an ample supply of developer talent.

Universities and Bootcamp Mines

The software industry has recognized the talent issue slowly over the last 30 years or so. Colleges and universities seem to be even slower in adapting. Comparing computer science curriculum from 30–40 years ago to today will reveal few differences. While the foundations of software development were being developed, the universities relied on their previously defined Computer Science curriculum and a 4-year general education model mixed in with it. Software Engineering programs were added. It was not sufficient.

Coding bootcamps arose to fill the gap. But, they too had fundamental flaws. Claims that they could turn just about anyone from a novice to a professional software developer were ill-founded and based on wishful thinking rather than any evidence. However, they certainly can provide a more marketable starting point than your average “Intro to Programming” university course by immersing people in software development and introducing students to relevant tools being used actively in the industry. The best bootcamps had access to experienced software developers as opposed to a staff of many academic professors who rarely — if ever — “programmed in the wild”.

Though the bootcamps promised experienced developers as instructors, the reality is that the most experienced software developers were paid well to develop software, not teach bootcamps. Some of the bootcamps had (and have) talented teachers with real-world experience (though typically less than 3–5 years). But, pretty soon many bootcamps became victims of their own early propaganda: the “gold rush” happened. Early adopters in the industry looked to mine the bootcamps rather than the universities for talent, and some found gems. However, as the bootcamp industry grew, the average quality of bootcamps started decreasing. Soon, the quality of software companies willing to take a risk on these grads also began to decrease. Expectations of these graduates in the industry were adjusted. At the same time, many bootcamps started taking in lower and lower-quality candidates.

People who hired the bootcamp grads found that they either produced sub-par software that couldn’t stand the test of time, or they realized how much more they needed to invest in these graduates was more than they counted on. Many started questioning the value and sustainability of the majority of bootcamps.

Developing a Farm Program

In the late 90s, as pioneers in software craftsmanship, we recognized that universities were not producing people with a solid foundation and that solid foundations took time to build. For that reason, we decided an apprenticeship model to growing Software Craftsmen was the way to go. It took time , but we found that by intensely nurturing those who had already learned the basics and desired to build software well, we could produce really solid developers in 12–24 months. Our model produced results far better than what we saw of those who spent 4 years in a Computer Science program, even those with a couple of years of experience. It was an investment that paid off in the long run, with a lot of short-run challenges.

In 2002 we hosted a Software Apprenticeship Summit and invited a few prominent people in the industry. Only a few showed up. Micah Martin, future founder of 8th Light, was there. Now 8th Light has a long track record of growing their own talent. They didn’t take shortcuts.

Just like a good farmer can produce both sustainable farms farmers in a slow-and-steady-wins-the-race kind of way (like Joel Saladin’s farming techniques), good apprenticeship models can produce both Software Craftsmen (who in turn produce software) and a way to produce even more Software Craftsmen.

We started slow — an apprentice or two at a time. We were careful to find good seed — people with an aptitude for software development and an attitude to match their desire to grow. The best seed are those who had already taken some initiative in their own learning, recognized they had a lot more to learn, sought to serve others through software development, and showed willingness to work hard to become a Software Craftsman.

We recognized that the best seed needed a whole lot of initial attention, then more attention, then nurturing. We eventually came to group these into three phases:

• Immersion (giving a Novice a good foundation so they could begin the path to becoming a Competent software developer without a lot of stumbling blocks),
• Apprenticeship (getting them from Advanced Beginner to basic Competence) and
• Residency (watching for places that Competence hadn’t yet taken root).

Each of these phases would take 3–9 months depending on a variety of variables, but even the most talented under ideal circumstances would take at least that long.

We never misrepresented what the apprentices could do to them or our clients. On any project, there are simpler tasks that need to be done under supervision, so we charge much less for the apprentices to do them to make it cost effective. Once they had the foundation, they could produce value… and as they learned with supervision, we built on that foundation to produce more and more value.

Eventually, we announced our Software Craftsmanship Academy in 2011. We figured we could do the Immersion Phase for a fee that could come close to paying for itself. Then we would pick a few for our Apprenticeship phase, and pass the others on to a few key places that understand what apprenticeship is like. We didn’t spend much on marketing and we didn’t make any radical claims. We didn’t get many students., Meanwhile, we watched in amazement as bootcamps making radical claims sprang up across the country and filled their classrooms.

Even though we had many years of success (and some missteps) with apprenticeship, we continued with the “build-measure-learn” philosophy. We knew that taking several through an immersion phase at the same time would be different than our original apprenticeships in some ways — but we had a pretty good track record of seeing what talented and hungry people could learn. Our hypothesis was that we could do Immersion in three months. We found there were those who could absorb what we were teaching at that pace, and those who could not. We watched as several eager candidates washed out in the first week or two and it was painful. We knew we had to get better at screening our “seed”.

Screening the Seed

There are many ways to learn the basics of programming. You don’t need a 4-year degree to learn the fundamentals of programing get the basics — we’ve seen that many times — but an 8–12 week tutorial on some modern framework doesn’t do it either. We don’t teach the basics of programming. We teach how to craft quality software, this requires the basics and much more.

To be set up for success in our program, candidates must have a firm grasp on the fundamentals and problem solving. We developed a basic programming skills assessment and we put all serious applicants through it. It clearly separated those who had some introductory programming (and got it) from those who didn’t. Our assessment is live and interactive so we can look past whether they got the right answers and focus on how they approached problems they had not seen before. We have found that those who do very well also make it through the immersion phase well. We haven’t automated the process, and don’t plan to.

When we run into bootcamp graduates, our experiences consistently affirm that what we are doing through our Academy results in a better foundation than either computer science programs or bootcamps produce. Sadly, one recent bootcamp grad did miserably on our basic programming skills test.

You can’t reliably mine software developers from the general population by using a bootcamp any more than you can expect to mine gold from the average person’s backyard.

Start Your Farm Program for Sustainability

At RoleModel, we’ve determined that sustainable growth of 20–50% per year is healthy. We try to start a new Academy every 18–24 months and we train our own farm team that way. And when they become competent developers, we continue to mentor them.

Clients have been consistently amazed at the quality of the people from RoleModel and keep asking us whether they can have some of the people we trained or if we could do some short-term training to produce talent for them. The answer to both was and is “NO.” There are no shortcuts to farming. There are better ways and worse ways, but the hard work is still there.

We are happy to help our clients screen potential developers. We are happy to help them develop their own farm program. We’ve offered to do so for several clients (or potential clients), and they say they can’t afford the time to train them. Yet, they seem to think they can keep doing the same thing they’ve always done and get different results.

The Challenge of Continued Growth

I’m sure there are other approaches to finding new talent. We know people who do blind programming tests — that can screen people, but what happens when they pass the test?

When we hire some people who have experience elsewhere, we often find that they have holes in their foundation that we need to fill. That’s why we have been developing our own RoleModel Way training for those coming in through channels other than our Craftsmanship Academy. Also, every developer in our company is assigned a mentor, whether they have been here one year or ten. We are always challenging and refining our best practices based on the experience of those we bring in and the experience of crafting software on a daily basis.

If you are building sustainable software and a sustainable company, what else do you do?

From what I can tell, they have done a decent job of introducing people to some modern tools of the trade. I suppose many other "Code Schools" or "Boot Camps" do the same.
I've not talked to the folks running Iron Yard enough to figure out what their "job placement" entails. One of my clients hired a graduate who seems to be a bright young guy, but he definitely has a lot of holes… some of which would have been filled by our different approach to immersion, others can only be filled in a different context. It is something that no "boot camp style code school" can do.

I have been one of the first to point out that becoming a software craftsman does not require a college education.

But, to do it well, one needs more than a bootcamp.

I've seen no better path than apprenticeship.

I have been pointed to The Apprentice Programmer post by several people over the last few years. Many boot camp's marketing might lead one to believe that they will turn you into a professional software developer in 12 weeks. If what they mean is that someone might hire you, they are correct. You might be hired. In my circumstantial sampling of 3 recent Iron Yard graduates, 1 had a job. I'm sure my sampling does not represent their placement rate, but it clearly is not 100%. All of the factors that feed into why some have jobs and some don't are far beyond what I want to tackle here.

The one hired by my client is in a pretty good environment to learn a lot… and they have brought me and my team in to help it be even better for inexperienced developers like him. But many are hired by naive employers who have no idea how to mentor these folks and it will be a lot of trial and error learning with very little guidance. Many seem to be hired by startups.

Startups are full of optimism. They have to be or they wouldn't ever get started considering the success rate of a startup is around 10%. (Google startup success rate for some interesting reading). In my experience, the ones who are so optimistic that they think they can build their product with cheap, inexperienced programmers have a much lower success rate. Most startups don't make it, and most solid, experienced developers won't take the jobs that are being offered to these boot camp graduates. (NOTE: Sometimes there is an excellent software craftsman at the startup who will do a good job mentoring the newbie… then the newbie has hit the jackpot whether or not the startup succeeds).

In my experience, those who have been apprenticed like Tobi Lutke (the author of the aforementioned blog post), or the folks who have come through RoleModel Software, achieve a depth that very few achieve who just enter the field and take whatever jobs they can get.

We only take a few into our Academy. If you don't get in, I'm sure that Iron Yard and others are a great place to learn some very useful things.

But seek apprenticeships, not just "fast tracks to a job". The difference to your career will be significant.

_{Photo by Bernard Hermant on Unsplash}

Walt was fascinated that Tom and others at Taylor have set up a Software Studio for their students.

This reminded me of a paper that Nathaniel Talbott (currently founder and CTO of Spreedly) & I wrote in 2000 that was submitted and published by the ACM as part of the OOPSLA 2000 Educator's Symposium. Nathaniel was RoleModel's first official apprentice, though Ken had learned a lot about apprenticeship through various means at his previous company and other venues in life. This paper was based on our reflections of our experiences at the time. Nathaniel & I also gave an "Invited Talk" at the Symposium and a few people were enamored with what we were saying and others said, "He's going to ruin that poor kid".

Well, in spite of what some of those educators' thought, I think Nathaniel has done pretty well in his career… and he still doesn't have a college degree. For those that decide to pursue a college degree, I hope that the type of environment that Taylor University has set up is the beginning of a trend. A recent study showed that roughly $59M will be spent in 2014 on "Developer Bootcamps".

Though it seems like learning about Software in a studio environment has gained some traction, unfortunately, many of these bootcamps and "higher institutions" are not "wisdom based." There is still so much to learn and wisdom to be gained in how to best impart wisdom. Very few have been at it as long as we have, and I think the wisdom we have learned over the years sets us apart from many of the rest, but no matter what our claims - or anyone else's claims - are, we must all be careful how we walk. There are still too many who ignore true wisdom which shouts in the streets.

_{Photo by Alex Shute on Unsplash}

Though not a perfect approach to software development, it is a vast improvement over many of its successors.

RoleModel Software was one of the pioneers in the application of the principles of Extreme Programming (see Extreme Programming Applied), and we have continued to evolve the way we apply these principles and others every day.

The heart of Extreme Programming is to diligently apply, examine, and refine, best practices of software development. The heart of the Craftsmanship Academy is to train up craftsmen who diligently apply, examine, and refine best practices of software development.

As one of his assignments during his Residency, Braxton Plaxco read Extreme Programming Explained. Below he has shared his insights into the application of the principles as he is learning to put the theories into practice.

Extreme Programming - My Experience Thus Far

Extreme programming (XP) is best described by Kent Beck when he says, “When I first articulated XP, I had the mental image of knobs on a control board. Each knob was a practice that from experience I knew worked well. I would turn all the knobs up to 10 and see what happened. I was a little surprised to find that the whole package of practices was stable, predictable, and flexible.” A few of the practices he described are: The Planning Game, Short Releases, Metaphor, Simple Design, Testing, Refactoring, Collective Ownership, Continuous Integration, 40-Hour Week, On-Site Customer, and Coding Standards. Working in a studio that strives to implement the principles behind these XP practices in their daily operations has given me the opportunity to experience and grow from each of these in one form or another.

The Planning Game

The Planning Game consists of defining a scope for the project in light of business priorities resulting in estimates for each task. While working at RoleModel I have had the opportunity to work directly with customers in determining which new features should be implemented in the next release. I've had to learn how to give estimates for a variety of tasks, while also assessing the value that certain features will add to the project. Often a feature is started with a general concept in mind. Refinement of the feature takes place as it is being developed. Refinement comes in the form of questions and input from the client. The project continuously evolves as direction is defined to meet the needs of the clients.

Short Releases

The concept of Short Releases is to put as simple of a system into production as possible and to release new versions on a short cycle. Short releases help to continually add value to the project as well as reduce code conflicts. In most of the projects I have worked on with RoleModel as soon as I am finished with a task, the tests are run, the code is reviewed, and then the feature is deployed for customer review on a staging server. Once the customer is content with the feature and all of the final tweaks have been made, it is deployed to production.

Metaphor

The Metaphor for the project is a narrative explaining what the system does. The metaphor guides the development process and helps the developers to keep the project's overall goal in mind. I've worked on projects that have had a strong, clear metaphor. I have also worked on projects where the metaphor was not clearly defined. Projects with strong metaphors were fun and enjoyable to work on. I knew the direction of the project, and this increased my motivation for completing tasks. It helped me to take ownership of the project and to want to do everything in my power to see it succeed. On the other hand it has not been as enjoyable to work on projects with out a clear metaphor. In those projects I often find myself wondering what the purpose is of the feature I'm working on. This usually leads to frustration. It is hard to take ownership of a project when you don't know exactly what it is that your project is trying to accomplish.

Simple Design

This is one of my favorite parts about XP programming. It is designing a system as simply as possible, while removing unneeded complexity from its components. When writing code I try to break the task down into its basic elements, figure out how each element might be approached, and then see what the language has to offer to solve the problem. I am not a fan of overly 'creative' and 'clever' solutions because they can be difficult to maintain. I like code that is easy to read at a glance, and I love when I have the opportunity to clean up existing code, making it more maintainable.

Testing

This was one of my least favorite parts about XP programming. Programmers are supposed to write unit tests for each part of their code and all tests should pass for the project to progress. Also, customers can write high-level feature tests. Note that I say that it was one of my least favorite parts. I've actually grown to enjoy TDD (Test Driven Development) quite a bit. It allows me to code with more speed, confidence, and precision. The speed and confidence are because I am less fearful that I'm going to break a part of the app. With good coverage, I know things are working properly. If I do make a change with unexpected side effects, a test will fail and I will know that I affected more than I meant to. I haven't actually had the chance to have a customer write the feature tests yet, but I usually take the task card and turn it into a feature test, so that I know that when my feature test is passing then the task is complete.

Refactoring

Refactoring is going over code again, removing redundancy, simplifying it, making it more flexible, etc… without changing its behavior. I love this part of coding as well. It's a fun challenge and helps me grow as a programmer. There have been times in projects where I got it working but it was only so that I could wrap my brain around the concept. The code was never intended to go into production (at least not in its current state). It still needs to be refactored. We were brainwashed… I mean indoctrinated… I mean taught the phrase "RED, GREEN, REFACTOR!" while in the Craftsmanship Academy. This phrase means you should always have a failing test, then make it pass, and finally refactor the code ensuring higher quality.

Collective Ownership

This is the concept that no one person owns the code in a project and therefore anyone is free to make changes anywhere in the code. With good test coverage, it is nice to know that if anything needs to be changed to meet the changing needs of the customer, it can be. In every project I have worked in I have had to change someone else's code, I couldn't imagine how tedious it would be to have to get permission from another coder to make those changes.

Continuous Integration

Continually integrating your code into the project makes it very easy to see who introduced a bug, therefore who should fix it. After working on each new feature I run my entire test suite. The goal is to have 100% of the test pass 100% of the time. So when I start working on a feature the test should be passing both before and after the feature is implemented. Continuous integration also helps to reduce collisions making deployment an easier process.

40-Hour Week

The 40 hour week is a concept of XP stating that you should come in fresh in the morning and leave exhausted in the evening. Constant overtime can be a sign that something isn't going very well in the project. I don't always get exactly 40 hours on my timer, due to parts of the day that are not exactly billable to the customer, but I do manage to spend that much time in the office learning or putting effort into some project. It is increasingly more difficult these days to divide home life from work life. I have had calls from clients asking me to deploy features on the weekend. I will do it of course, but I do try very hard to keep a clear division from home life and work life, so that I come in feeling refreshed and ready to go each day.

On-Site Customer

An On-Site Customer is exactly what it sounds like. A customer sitting with the team answering questions and resolving disputes about the functionality of the application and its interface. We very seldom have this opportunity, but we do our very best to keep an open line of communication between the developers and the customer. I usually use technologies such as Trello, Skype, conference calls, and GoToMeetings to keep that line of communication open. An On-Site Customer would be better, but leveraging technologies efficiently is the next best thing.

Coding Standards

Coding Standards ensure that code is uniform and concise. It should be difficult to tell which one of your team members wrote a specific line of code. A good coding standard should include DRY code (DRY means Don't Repeat Yourself) and Intention Revealing Names at a minimum. The key is that the code communicates. The rule at RoleModel is that two sets of eyes see (and approve) all production code. I love when good coding standards are in place. When the code follows a set order it is usually easy to add new features and functionality. I was surprised when coming to RoleModel with how high the code quality is. Seeing these high standards has helped me to become a better developer.

Conclusion

It is not the merit of the individual practices that makes XP so great, but rather the combination of them. If you tried to focus in on only one of these practices, parts of your project would fall through. When each is applied appropriately, it creates a certain synergy. I am very pleased to have been introduced so early on in my development career to a studio that implements XP principles, and I look forward to learning and applying everything I can from this experience.

Source: Extreme Programming Explained (Embrace Change) by Kent Beck, Pages 53 – 70.

_{Photo by Web Donut on Unsplash}

Apprenticeship Patterns: Skillset Expansion

I've been reading Apprenticeship Patterns by Dave H. Hoover and Adewale Oshineye. I was recently able to apply a few patterns: Confront Your Ignorance and Breakable Toys. I'm hoping I will also get a chance to apply The White Belt through how I'm applying the other two patterns.

My friend Braxton and I recently took on an internal project for RoleModel that we're building using Node and CoffeeScript. This is allowing us to apply each of these patterns.

Confront Your Ignorance

If there are some gaps in your skills, work to fill in those gaps, one by one. One good way to do this is to build Breakable Toys.

My main project at RoleModel is mostly client-side JavaScript. Thus, I found a very obvious gap in my skills when it came to server-side programming.

Meanwhile, Braxton had done more server-side than I had, but not as much client-side, plus he wanted to learn CoffeeScript.

To fill in these gaps, we took on this internal project which we decided to build in Node using only CoffeeScript. Our plan is that Braxton will work on the client-side, while I work on the server-side.

Breakable Toys

Attempting things that may be beyond your skills, things you may fail at, is a great way to learn, but when you're in a situation where failure is not an option, you need to build a "toy" project where failure is safe.

The deadline for my main project is coming up soon, which puts more pressure on everyone involved, creating an environment where failure could easily cause a lot of harm. Working on this second project, since it's very low-pressure, gives me an environment where I don't have to be afraid of failing.

The White Belt

When approaching new situations, while still retaining your previous confidence, intentionally set aside what you already know and force yourself to learn the solution, rather than relying on your previous experience to provide the solution.

I expect that building the server-side portion of this project and working in CoffeeScript will give me plenty of opportunities to set aside the experience I've gained through client-side programming over the past few months.

_{Photo by Robert Keane on Unsplash}

Apprenticeship Patterns

The book Apprenticeship Patterns by Dave H. Hoover & Adewal Oshiney is a wonderful book for any aspiring software craftsman. It teaches the patterns needed to get a solid foothold in a world that is always changing. Working at RoleModel has allowed me to apply many of these patterns throughout my apprenticeship. Three of these patterns have been quite useful so far and they are: Find Mentors, Kindred Spirits, and Sweep the Floor.

Find Mentors

"Whether a beginner starts out with a training course or is self-taught, the first step on the path to software craftsmanship is finding a craftsman to apprentice himself to."

– Pete McBreen, Software Craftsmanship, p. 96

In the pursuit of becoming a software craftsman there are many blind alleys that one could go down. The guidance of a master craftsman can help the aspiring young apprentice, such as myself, to navigate these alleys and grow in their craft. At RoleModel I was blessed with the opportunity to work under one of its Senior Software Craftsman, Tim Irwin. He has helped me to improve in many areas in my life spanning more than just that of code quality. He has helped to ask the correct questions such as 'How would I go about figuring this out on my own?' and 'What resources do I need to complete this task?' instead of 'Can you help me do this?' (i.e. can you do this for me?) He has taught me how important it is to have strong soft skills. Soft skills are the ability to communicate well with clients and others, and are often neglected in the software development world. By guiding me through interactions with our clients I feel that my soft skills are steadily improving.

The ability to work with a good mentor has given me a definite edge in my growth as a craftsman and has been a great encouragement in my growth as an individual.

Kindred Spirits

"Nothing is more powerful than a community of talented people working on related problems."

– Paul Graham, Hackers & Painters

It can be intimidating at times working solely with a mentor, that's why interacting with other people within my skill range has been very beneficial while exploring new avenues. It has become quite a source of enjoyment in my side projects. Kyle, Jeremy, and I have our own Skype channel (dubbed CowChat because every message posted has been piped through cowsay first) in which we talk about our ideas for pet projects, as well as posting an occasional pun. It has been very encouraging to have colleagues to share ideas and grow with. I am also looking into contributing to an open source project. I think it will give me a chance to expand my skills and join a part of a larger community.

Sweep The Floor

"In the craft tradition, newcomers start as apprentices to a master craftsman. They start by contributing to the simpler tasks, and as they learn and become more skilled, they slowly graduate to larger, more complex tasks."

– Pete McBreen, Software Craftsmanship.

In the book, Apprenticeship Patterns, the author retells a story of an apprentice who, in trying to find his place on the team, took on the menial task of sweeping the floor. When first joining a team it is good to find ways to begin providing value immediately. The way to do this is often not through actually sweeping the floor, but by taking on tasks such as: test automation, refactoring code, removing technical debt, and that task, "who shall not be named", that has been put on the back-burner for so long because no one wants to do it. It's funny, at RoleModel I actually did end up sweeping the floor. I was given the opportunity to take on some of the DevOps and SysAdmin tasks. The server room was in need of attention so I removed all of the excess material, swept and cleaned it, had shelves ordered, and organized the equipment. It was humbling to take on this task, carrying boxes up stairs while everyone else was sitting together in the main room coding, but I also felt a sense of accomplishment that I was able to improve something in the company.

In Conclusion

"I have no special talent, I am only passionately curious"

– Albert Einstein

Apprenticeship Patterns is filled with many patterns for tackling the tough situations craftsmen will face as they begin their journey. As you quickly learn you can not throw all the patterns at a given situation, but rather you have to apply and adapt the relevant patterns to fit your needs. That being said I would recommended this book, for anyone regardless if they plan on pursuing a career in software development. It has patterns applicable to all areas of life, and I plan to seek opportunities to apply them as I continue to nurture a healthy sense of curiosity in my life.

_{Photo by NIKHIL on Unsplash}

I'll write more later about the apprenticeship phase that the Academy participants are in the middle of now, but I want to first summarize the immersion phase.

On the last day of the immersion phase, I asked them to describe what they could do before and after the immersion phase. This is what we ended up writing on the whiteboard:

Perhaps you can't read my writing. Well, here's the stuff on the left which they say summed up what they knew before the immersion phase:

And here is the middle, where they described the architecture of what they built during the immersion phase and what they know how to build now:

Using these tools:

(I understand you still might not be able to read my writing.) Well, I'll let one of our participants, Greg Tarsa, describe his experience:

Back in December, 14+ weeks ago, I entered an Immersion Training program in the Craftsmanship Academy of RoleModel Software in order to refresh my programming skills and get a leg-up working in the world of Web application programming.

It has been quite a ride.

I came into the program after losing my job as an Operating System Software Development Manager. Twice! While I loved building teams, I missed being hands-on. I wanted to re-boot with some new skills and get acquainted with a whole new field of software development. RoleModel's Academy looked like an outstanding way to do this. I applied and was accepted. The class included two of us "re-booters" and 4 younger high school graduates from various parts of the country.

This will be a looooong article if I try to describe play-by-play all that we covered. There are a lot of moving pieces in web application development. But a short laundry list of things we learned is in order. Besides basic HTML and CSS, there are also implementation languages (Ruby, Objective C, JavaScript), templating languages (Slim, ERB, SCSS), domain-specific languages, server frameworks (Sinatra, Rails), and development methodologies (TDD, OOP, R-G-R). Oh, and databases (SQL, Postgresql), let's not forget databases. Or git. Or–nevermind. The list is too long.

After completing the course, I have a solid exposure to a wide variety of these tools and concepts, but more importantly, I have come to understand many of the key relationships between and among them along with solid development approaches that help keep things simple while also creating running code early in the process.

First the development principles.

At the core of the process would be Test Driven Development and Red-Green-Refactor. R-G-R puts a priority on writing tests that fail (i.e., Red) before writing code that works (Green) before writing code that is clean or even straightforward. "Make it run, make it right, make it good." was a mantra here.

Test-Driven Development works hand in hand with this. TDD in its best form, has you writing tests before the writing of code. Using tools, like rspec, capybara and spinach we essentially learned to write specifications incrementally. Write a test, watch it fail. Write the code to make it pass. Write another test, etc. Very quickly we had three useful things:

1. A working body of code that was making visible, incremental progress toward usefulness.
2. A robust set of tests that exercised most every line of that code, making refactoring and on-going development more straightforward since there were always significant tests that would verify that the changes did not have unforseen side-effects.
3. Well chosen test phrases in a test framework, like rspec or spinach, results in a reasonably worded specification of program operation. Spinach for high level descriptions and rspec for low-level descriptions.

Coming from an OS development background it was challenging to let go of the long practice of not writing code until the specifications are completed and completely understood. But I learned…

In the area of Object Oriented Programming, we learned three languages: Ruby, Objective C, and Javascript. Each had its sweet and bitter features. All of them allowed for basic practices of encapsulation and provided objects and the ability to send messages to them. Ruby seemed the most comfortable with its object-ness, but Objective-C brought more clarity to the message passing involved with good object orientation. Javascript was trickier to use, but shed light into the "guts" of an object system via its "prototype" orientation towards objects (i.e., instead of using explicit classes).

All these concepts, languages and tools came together in the week we started to learn Rails. This exposure to Rails came via the Ruby On Rails Tutorial by Michael Hartl. Ruby, Slim, client-server, database, rspec, capybara, spinach, SASSy CSS, Model-View-Controller. Everything we had learned, experimented with and wrote code for came together here.

Carefully meshed into all the classroom instruction, project assignments, daily reviews, etc. was the growing application of Agile development principles. We learned the value of moving forward without knowing all of what we were doing at any given point in time. We saw first-hand how plans never go as written and so investing in their core elements and pushing the details off to later works well in creating a cadence for for development. We were doing weekly reviews of what we had been learning and experiencing in our class projects from the start, this turned into weekly iteration meetings for our final project.

The core beauty of this training was how the techniques and practices taught preclude a great deal of the heartache and grief that comes from learning a tool, technique, or framework out of context and then learning how to use it wisely. Ken Auer was our guide through a Labyrinth filled with pits, snares, and energy-sucking death traps; any number of which would have greatly delayed our learning the critical mass of skills needed for web programming. However, through careful leadership, we never had any real scares, much of what we know as the only way to do things are industy Best Practices. We were not simply guided through the course, we were molded into into apprentices with principles that will make the path ahead more productive, more fun and a great learning experience.

Now these folks are ready to be apprentices, sitting with our Craftsmen to learn and help. They don't have to ask why we're writing tests first, how to use Git, or many of the basics of the way we do things. They'll be taking all the things they learned and working on real projects, observing the craftsmen as they expertly work through a myriad of challenges, and contributing as they can on their journey to become craftsmen in their own right. It may seem like a long way to go, but they've taken some great first steps.

_{Photo by Green Chameleon on Unsplash}

The Craftsmanship Academy will definitely be teaching Data Structures and some other things taught in typical Computer Science, Software Engineering, and/or Information Technology curriculum, too. But, there will be major differences.

A typical Computer Science curriculum at a university will have about 40 credit hours in Computer Science. If each credit hour means roughly 50 hours of student time (class plus outside study/work), that equals about 2,000 hours. However, there are many things discussed during Computer Science courses that will never be used outside of the course in the real world, and the student never gets very in depth on any topic. If a single 4 credit hour class were dedicated to a single project, that would be one 200 hour project. Few, if any, courses do this. Most projects in computer science classes are 5-30 hours. If concepts and techniques are taught without useful context, they are often lost. Additionally:

• Most classes are taught by instructors who haven't (or have rarely) ever programmed in the wild. They are not master craftsmen. They have mastered teaching Computer Science in a university.
• Few courses teach best practices.
• Most universities barely touch on object-oriented programming, which has been the standard approach to most application programming in the industry for two decades.
• The curriculum for Computer Science hasn't significantly changed in thirty years. And it was somewhat out of touch with what was done day in and day out then.

There are some universities offering Software Engineering degrees which, in our opinion, are far superior to a Computer Science degree for those who want to build software. Some of the better ones have two semester-long senior projects. However:

• They rarely teach agile development.
• They don't teach test-driven development.
• They take four years.
• They are often taught by people who haven't done much development in the wild.
• Students rarely get individual attention.

Neither of the above is an attempt to be exhaustive.

We could talk about the college lifestyle, the political agenda at many universities, and so much more. Some may like these things. Most people we know who have gone to four years of college who have any moral compass look back at those days with much regret.

Our Craftsmanship course of study assumes coming into the program with up to several hundred hours of some programming under your (yellow) belt. The 24 weeks of 50 hours or more in a wholesome atmosphere with a craftsman on hand every day to instruct and review your work should keep you from becoming corrupted (and, we pray, encourage you to walk in the ways of righteousness) while learning best practices, underlying concepts, and gaining real-world agile software development experience. This includes talking to actual clients and users (not theoretical people, but real ones). The one-year internship plus further study (around 2000 hours or more) before the final black belt will give a taste of what the profession is really like. The instruction is by real-world practitioners where concepts and theory are applied just in time, in context, and in-depth. After 1.5 years, the participant will have 3200-4000 hours mostly in the context of building software as a profession.

Yes, you will be "missing" instruction in some advanced math, humanities, etc. We tend to look at it as relieving the encumbrance of having to juggle multiple things out of context while learning to be effective in your profession. Ask most professionals in any field how much value all of those things they learned in college helped them in their daily profession. In the real world, people spend all day on their profession and the skills it takes to be effective at that profession. Even in the software profession, this includes communication (written, oral, and several others), analysis, understanding people from different cultures and worldviews, etc. But since it is done in a specific context with real people, it goes from theoretical head knowledge to practical heart knowledge.

Students can get that instruction elsewhere (perhaps an associate's degree, a BA or BS, self-study, or other means), if they think it is necessary. We'd love to take students who already have a degree and teach them all of the stuff they didn't learn. The degrees do not directly prepare people to be a professional software craftsman. We will.

_{Photo by Tasha Lyn on Unsplash}

I have received many questions about what working on real-world projects during the second 12-week session means.

Having worked with many apprentice-level people in the past, I know that their first real-world project is a great awakening. As Corey Haines stated in his keynote address at Software Craftsmanship North America, (paraphrased) "Programming is not that hard. Software Development is hard." The first 12-weeks will get the apprentices ready by giving them some fairly well-paced projects that I can somewhat predict how they will go and what they will learn. But that's not the way most projects I've ever been on in the real world go. Though I'm getting more and more comfortable with projects after close to thirty years, and get surprised by their turns less and less, there is still a lot of unpredictability.

I've found that the first "real project" an apprentice gets on is often a huge shock to them. They don't run like the textbook says... or at least not like their interpretation of what the textbook says. And, quite frankly, most apprentices don't have a clue how to handle it. They need instruction on how to extract what a client really wants, how to prioritize, when to ask for help, when not to ask for help, how to figure out the missing pieces, when it is OK to experiment (and how), and ...

As I designed the Academy based on all of the other apprenticeship experiences I had, I really thought a "real-world project" needed to be part of it. They needed to see how I handled a new project that was thrown at me, not just one I have already done, giving them pre-digested instructions. When I thought about where to get these sorts of projects, just like I benefited from the world of Farriers for parts of the structure, I benefited from looking at other types of schools for hands-on projects.

Dental and Cosmetology Schools

Some people go to dental schools to get dental work done or cosmetology schools to get nails or hair done. The expectation is that the procedure may not be efficient or at the highest standard of quality as it might be if they paid a professional full price, but

1. The customer doesn't pay full price
2. The customer doesn't tend to go there for work where risk is incredibly high if something goes wrong or where specialized, advanced skills are required without assurance that a highly-skilled professional is actively doing all the work himself.
3. The price you pay really covers the overhead of the school, and what you are paying for is the sign-off by the licensed professional that a professional-level job was done.

All of this is a win-win-win.

The customer wins because they save money

Whether going this route allows them to afford something that would otherwise be difficult to purchase, or just use the savings for other purposes, they made the choice to go this way.

I don't have much hair so, for several years, I went to a hairstyling academy that was conveniently located close to where I was working. A student would give me a haircut, and an instructor would check it out before I left. Sometimes the student was a little slow and methodical (usually the newest students). Sometimes the student seemed pretty confident and moved fairly quickly. Sometimes the instructor would say, "good haircut" after running their fingers through my hair. Other times the instructor would do some touch-up and instruct the student as they did.

I got pretty decent haircuts and used the savings for other things.

The student wins because they get to practice their craft on real live examples

As Jared Richardson points out, "How many books do you have to read about riding a bike before you can ride a bike proficiently?" We all know the answer is "none." You need to have the prerequisites (basic balance and ability to move legs and arms appropriately), some instruction in the basics, and then practice. It is best to make your initial attempts in a safe place with some safety equipment and oversight from a person who can prevent costly consequences for incompetence. If you have an experienced coach, they can help you recognize what you are doing wrong, correct your mistakes, and slowly introduce the techniques that only masters would know as well as the context(s) in which the technique(s) apply.

The students at the hair salon and the dental schools are getting experience with an experienced coach on their way to becoming competent enough to practice by themselves or with a larger professional team.

The school wins because they can recover some of the cost of running the school
Most people don't consider what it takes to run a school. There are marketing and recruiting costs. There is the overhead of the buildings and equipment. There is the time of the instructors, both while they are teaching and the hours of prep work before and during a course.

People wonder why most "private schools" are generally more expensive than "public schools".
Often, they aren't, it is just a matter of where the funding comes from. When funds come from a government subsidy, private donations, or other ways that a school can get cash flowing in, they can lower the tuition of their students while still covering their costs and/or making a reasonable profit.

Most colleges don't just get income from tuition, but money comes in to fund research and other activities by the "professors". In the best case, that work helps the professors learn more deeply so they have more to share with the students, and allows the students to do some work alongside the professors.

The Academy's Win-Win-Win

We are seeking candidate projects for the second 12-week session that meet the win-win-win criteria of being good for everybody.

RoleModel Software often has potential clients that have a bigger vision than budget. Perhaps they have a project that would cost $50,000 if the professionals at RoleModel took it on, but they only have $25,000 they can spend. If we feel the project is something that can fit into the timeframe for an Academy project, we might take it on.

Instead of paying full price and getting the fastest turnaround, we offer them an alternative that can get them where they want to go for less money. We will bill the instructor's time at a deep discount (40% of normal rates) knowing that he will be working on the project at a slower rate as he teaches apprentices and that some of the work will be done by the instructor via the apprentices' hands. If there are areas that others at RoleModel need to be brought in on either because the skills needed (e.g. UX design work) are not the primary instructor's strong suit, or he is being spread too thin, that work will also be at a significant discount.

The academy wins because the expenses of the academy are offset by the client's paying to have the project completed as an academy project. It also gives us a real-world project with a real-world client which is more challenging than one we just make up. We get to teach apprentices how to help clients work through trade-offs, the benefits of delighting them, the cost of disappointing them, the challenges of communication and expectation management, and so much more. Our instruction wouldn't be as good if we only gave them the theory of what might happen in a real-world scenario.

The apprentices win by seeing an entire project from concept to deployment. They will experience the difference between programming and software development and realize there are a variety of skills needed that go beyond learning a language. They also benefit from the lower cost of the academy.

We already have a couple of candidate projects but are always looking for more. As we know in our business, candidate projects don't always turn into real ones. We'll be looking at which of the candidate projects will become the real ones at the beginning of June. Just like we're being selective about our intern sponsors, our instructors, and our apprentices, we want to be selective about the projects used in the academy.

If you have a project you would like to save some money on that could benefit from the expertise of RoleModel, and think it might be able to be done in the 12 weeks between August 13 and November 2 using this model, please contact us.

_{Photo by Hunter Haley on Unsplash}

At the welcome reception, one craftsman or journeyman after another greeted me (whether they knew me or not) and congratulated me on the opening of the Craftsmanship Academy. They all stated in one way or another that the universities weren't preparing people for the realities of software development and didn't seem to care. Many asked how I was going to approach their education and nodded approvingly when I told them what and why I was going to do. I probably told the story about teaching data structures in context, a half dozen times to people whose collective response seemed to be saying "I always suspected how much easier it could be to teach theory in the context of practice."

Corey Haines gave a great keynote at the opening of the conference. He started out saying that he was a little bit worried about the future of software development. He was concerned that we might be "doing it again." Doing what? Making the mistakes the industry did in the late 90s... Hiring anyone who had a particular language on their resume, and producing a lot of disappointing results.

One of the reasons was that the universities weren't preparing their graduates for the realities of software development.

Corey said that though learning a language is not trivial, it is also not that hard. (This was echoed by Zed Shaw and others later at the conference). Software development, especially the kind that provides real value for business, is hard. No one in the industry who actually does software development for a living would tell you that the majority of their job consists of typing code into files that will eventually compile. There is so much more to software development. Corey feels for the many unfortunate business people who don't know enough to tell the difference, so they often hire people who know a language but don't know how to develop software, and they waste a lot of money because they don't get the value they need.

Corey also pointed out that he had a lot of hope. He listed RoleModel Software's Craftsmanship Academy as one of the reasons for his hope. He was not only pleased with our offering but also pleased that the community attending this conference and beyond was intent on training up the next generation.

Shortly after Corey's talk, Chris Parsons from the UK gave a talk entitled, "Universities: Who Needs Them?" He challenged the value of teaching theory without much practice while ignoring all the things that actually make for success in software development. He challenged the audience to begin figuring out how to get entry-level folks from high schools before they spent too much money learning a lot of theory out of context. One thing he said that a university might be good for is teaching theory after they had more practice under there belt, but that it would be better to get "just in time" theory that could be pulled as it is needed in smaller chunks. He, too, mentioned our Craftsmanship Academy by name as a much better solution.

Though I must admit all the free publicity was great, that really wasn't the point. It seemed that about half the sessions at the conference at least mentioned the fact that some sort of apprenticeship model was absolutely necessary for training up software craftsmen and, either explicitly or implicitly stated, the universities were not even beginning to prepare their graduates for real-world software development. There was a very well-attended panel on software apprenticeship, the theme of which pointed out that taking on apprentices was hard but necessary work, and openly shared the lessons learned from trying. Interestingly, this panel, hosted by Michael "Doc" Norton wasn't led by those who were just experts on the theory, but who had actually had practical experience with apprentices. Though they acknowledged that the theory taught at universities had some value, it was easier to fill in the theory in the context of practice than to teach those who were taught the theory how to effectively do the practice.

There was a lot of excitement about our program because it made it much easier for those wanting to take on apprentices/interns to find qualified people. As of the moment I write this, I have two qualified software craftsmanship shops who already signed up to pay for the privilege of interviewing the program's graduates, and a bunch of others who told me they were planning to apply when they got back to their office.

I talked to people in several shops who told me how hard they have been looking for sources outside of college graduates. Some used local tech colleges to search for people who were on top of the class and hired them in the summer, trying out summer students and hoping that one would stick. Others would just look for young people who had done some programming and spent a long time interviewing them. Though they found better success with these methods than hiring university grads, they just swallowed hard about all the things they had to teach these entry level folks that they had not picked up elsewhere. No one even mentioned recruiting from any of the several week certificate programs. Though I did not discuss it at length, I believe that they recognized that many "certificate programs" just taught enough to pass some test and get a certificate, They don't teach very deeply and often prey on people who were just looking for an easy way to get a job and did not realize how thin a slice of training they were getting and how limited their opportunity might be afterward.

The industry is crying out for better and deeper training, but it seems like the offerings are quick-hit certificate programs or four (or more) years of your life and a bunch of money getting a lot of theory, much of which is not very practical or appropriately framed, with gaping holes.

I was recently pointed to the article What They Don't Teach Law Students: Lawyering in the New York Times. It seems that software development isn't the only field with this problem.

We need more programs taught by people who are good in their field and really care about teaching. It is a hard balance to strike. Those who are good at their craft want to practice it and get better at it. Even if they love to teach, they have to limit their time at it so they don't become academic and lose their edge. I was asked about starting a school for years but couldn't come up with a model that I thought could work until I finally heard about the farrier model of teaching craftsmanship and Chris Gregory's approach at Heartland Horseshoeing School. Chris only keeps his school open for part of the year. He uses the rest of the year to keep on top of his trade in a variety of ways. That's what we're doing.

Though we are encouraging others to do the same, it is still a hard thing to set up. In the meantime, I'd encourage parents and young people and anyone looking to switch careers to heed what the best professionals already know. Universities teach theory (and some certainly do it better than others). Those who are best at their practice are looking for those who are prepared to practice. Theory is only a piece of that and needs to be placed in context.

Look for alternatives. Create alternatives. You will stand out from the crowd.

By the way, people who care about being good at the practice of their craft are rarely out of work. There are up times and down times, for sure. The folks in the software craftsmanship movement are hiring, but only the kind of people who, like them, care about the practice of their craft.

_{Photo by Annie Spratt on Unsplash}

In the mid-90s, I was working on a very large Smalltalk project at Nortel. One evening when I was about to leave, a young man who had just joined the project several weeks earlier after graduating college with a BS in Computer Science caught my attention. "Ken, can I show you what I've been working on?" Though I wanted to go home, I knew taking a few minutes to encourage this new guy was the right thing to do. "Sure," I said.

He proceeded to show me how he had implemented a binary tree in Smalltalk and had converted a piece of the application to use it because he had noticed that they have been using a linear search to find certain objects.

As he showed me the code, I exercised self-control before speaking... well, as much as I could muster. The code did not follow any of the conventional protocol of the well-established Smalltalk Collections. In order to make use of it, he changed a huge amount of code in the existing system when he could/should have merely changed a couple of references to class names (and isolated that further with some careful refactoring) had he employed the standard collection protocols to exploit the concept of polymorphism. But polymorphism wasn't taught in his Computer Science courses. So, I gently pointed out to him that it would be better to follow the traditional protocol.

Since the young man wasn't on my sub-team, I asked him whether the other more senior people on his team had seen the code he was writing. I was fearful that these "senior" people either didn't know what the young man was doing or, worse yet, that the more senior people didn't have very good practices either. He said, "not yet."

I asked him whether they had assigned him this task, and he told me that they just told him to look over the code (for about 4 weeks without supervision/explanation?!?) and, when he did, he noticed the "sin" of a linear search being used (as it was implemented in the standard Smalltalk OrderedCollection class). I asked, "Was there a particular performance problem in this area of the application?".

He responded, "It was doing a linear search and a binary search is much faster."

I said, "I know that, but was there a particular performance problem?"

He again responded, "They were doing a linear search!" speaking with a bit of annoyance that the respected Smalltalk guru didn't seem to understand the horrors of linear searching.

I said, "How many objects were in the particular collections that you replaced with the binary tree? A few thousand? Tens of thousands?"

He said, "No. I think it was typically about 15 or 20. But the size doesn't really matter because a binary search is always better."

I asked, "Do you know how fast a computer can do a linear search through 15 or 20 objects?"

He stared at me, not knowing what to say.

I decided to turn this one back to the team leaders who let the kid waste 4 weeks of the company's money. "Why don't you talk to Lee tomorrow and see what he says. However, I think that if you want to keep the binary tree, you should make it more like the protocol of the other Smalltalk Collections, but I'm not sure you'll need it."

I went home shaking my head about how he had been taught the data structure theory well, but out of context of so many other important concepts of software development. He had been given the knowledge but no wisdom to guide him as to how, when, and why to use it.

Fast forward 5-ish years.

Nathaniel Talbott, RoleModel's first apprentice, is working with me on another project with Organon Teknika, whose team we are trying to teach how to apply Java and Extreme Programming. The project was fairly large and, though we rotated who paired with whom at least once/day, there were parts of the system I hadn't had my hands in for a while. During a stand-up meeting - where everyone at least checks in on what others are up to so a NOOB doesn't end up thrashing on his own for several weeks providing no value to the project - someone brought up that as we were adding more data, part of the system was taking a very long time to respond. Several others said they had noticed the same thing. I said that I had some guesses as to the source of the problem and I could go over my theories with whoever was interested after the stand-up.

Just about the entire development group decided to follow me to the whiteboard. Most of the development team had Computer Science degrees or some other form of college training besides Nathaniel. So, I started scribbling on the whiteboard and describing the data structure behind the scenes and how I suspected it was growing and copying elements from the old buffer to the new buffer. I pointed out that because the collection started out small, and was being added to one at a time in a linear fashion, I suspected that the result was a proliferation of creating new buffers and copying the elements to the new buffers from the old buffers. I also shared a couple of other theories I had about this particular section of code that would make it worse. Included in my theory was the idea that this was a sorted collection and the sort criteria was being applied in a fashion that added a relatively inefficient linear search. I then proceeded to point out some solutions to the problems that would avoid so much unnecessary processing. In the midst of the discussion, I mentioned that most collections in Java were simple collections of buffers, but you could use linked lists, or hashed collections at times. Nathaniel, who had been working with us for about a year said, "I've heard the term hash before, but I don't really know what it means." I then explained the concept, having just explained linked lists to him and the team a few minutes earlier.

This entire discussion took about 45 minutes. Most of the others in the room learned a lot, too. Though some of them had heard a lot of the theory I presented while they were in college, it was years earlier and out of context so they hadn't recognized the applicability of these concepts that had been tucked in the back of their minds. Now that I had just brought it back to the forefront, they were ready to apply it for the first time. I confirmed that they all understood what to look for and how to fix it if they found it. They all acknowledged their understanding, were dismissed, and went back to their desks... all but one.

Jeff Canna, one of the more experienced developers on the team, just sat at the end of the table shaking his head.

I asked, "what's the matter, Jeff, did I say something wrong?"

"No," he responded. "I was just marveling that you just taught an entire semester of data structures in less than an hour and the kid absorbed it all."

I objected, "I didn't teach the entire data structures course..." I then paused to reflect on whether my reactionary statement was accurate. I then realized, "Well, I guess the parts I left out were the exercises we were taught in the class that were out of context. He's been using the data structures for more than a year very effectively and learning how to write good clean code using them without knowing the theory behind the structures and algorithms supporting them. I guess this was the first time he really needed to know... just in time learning."

At that moment, I was reminded of the earlier newbie who had been taught all of the theory first.

I was thankful that I hadn't paid a lot of money for a college grad with a Computer Science degree, but had invested in an apprentice who was a less expensive and more productive developer at the ripe age of 19, and who already had a year of experience with object-oriented and extreme programming practices as well as learning how to work well with a team.

Object-oriented programming, design patterns, extreme programming, and other agile practices are not taught at any depth, if mentioned at all, in just about any college in the country. Almost no colleges offer "Working With A Software Team 101". One person at the reception said that a college professor he knew said that test-driven-development shouldn't be taught at the university because it is just a passing fad. At least that professor has heard of it. I know others that haven't. But at least they all teach data structures.

Where should data structures be taught? In college, or in context?

_{Photo by Fatos Bytyqi on Unsplash} 

So what kind of school is the Craftsmanship Academy?

We would call it a school of Lean Craftsmanship. Take the principles of the Agile Manifesto, make sure you practice them with people committed to the values laid out in the Software Craftsmanship Manifesto, and recognize that the best way to know that you are building software of value is to get feedback from real customers as proposed by the Lean Startup movement.

There is the kind of software craftsman who is a Solo Virtuoso. We admire and respect such individuals, but we believe that we are created as social beings, and that we have much to learn from each other. Isolationism can feeds one's ego. Working with a great team can feed one's ability, while keeping the individual humble as his mistakes and shortcomings are not hidden. Those that see his shortcomings can help him overcome them. Agile Software Development includes practices that help people work together effectively, and make constant course adjustments.

However, you can do a lot of "best practices" of agile software development, and still not be very good at creating software. A bunch of people with good tools can't build a beautiful piece of furniture just by cooperating and agreeing to what they think might be the best approach to building it. Somewhere along the line, they have to learn the techniques for working with the materials they have in an effective way. The Software Craftsmanship Manifesto acknowledged that the principles of Agile Software Development were not enough.

One can learn these techniques and apply them to build things only for themselves. If he does, only he gets the benefit. Unless he can eat what he builds, in the end, even he does not really benefit. People are ultimately paid for providing something of value to others. The Lean Startup approach to customer development in step with product development attempts to make sure that happens. It does not completely succeed because every venture has some inherent risk including some that can only be found by moving forward, but it does put the emphasis on talking to customers as if they mattered.

At RoleModel Software, we declare that we are focused on software craftsmanship with an emphasis on serving customers over being part of the “mutual admiration society." We strongly believe that true software craftsmanship. Software is primarily built to be used, not admired. (I.e. although we respect and admire those who are good at their craft and are not satisfied until every line of code is beautiful, we believe that we need to provide value to our customers through our work, and have an attitude of service to them rather than an attitude of elitism due to our power to master the computer and impress our peers).

• A Craftsman is going to invest in his tools
• Someone who wants to be part of a team invests in the team and what the team/business is doing
• The customer is the most important part of the team

These values are reflected by RoleModel's Core Team who are focused on software craftsmanship in the context of making RoleModel and its customers more effective, profitable, and forward-looking:

• Continuously striving to improve our craft
• Continuously striving to serve our customers
• Continuously striving to meet commitments to each other
• … in context of “a healthy Christ-honoring life”

What was that last bullet item? Did he really say that in a public forum? Yes, he did.

If it is really important to you to live in a world where God is kept out, and no one around you acts as if there could be someone bigger than you or any person, you may not like our academy.

He has told you, O man, what is good;
And what does the LORD require of you
But to do justice, to love kindness,
And to walk humbly with your God?
(Micah 6:8, New American Standard Bible)

When Jesus walked the earth and was asked, “What commandment is the foremost of all?” Jesus answered, “The foremost is, ‘HEAR, O ISRAEL! THE LORD OUR GOD IS ONE LORD; AND YOU SHALL LOVE THE LORD YOUR GOD WITH ALL YOUR HEART, AND WITH ALL YOUR SOUL, AND WITH ALL YOUR MIND, AND WITH ALL YOUR STRENGTH.’ The second is this, ‘YOU SHALL LOVE YOUR NEIGHBOR AS YOURSELF.’ There is no other commandment greater than these.” (Mark 12:28-31, New American Standard Bible).

You don't have to believe that to come to the academy, but we believe it. You don't have to sign any statement of faith, but you do have to agree to our code of conduct. The training is about how to become a great software craftsman, but you'll hear what motivates us to do our work heartily. I'm not sure why anyone would have a problem with us striving to love our neighbor as ourselves, even if you have a different object of your faith. We believe we are created in the image of God, which is what gives us the ability to create. He gave us that ability to reflect His glory. We aren't always true to His purpose, but we strive to be, and believe this is the standard that He has set, whether or not we consciously achieve it.

By His grace, we will teach you how to eventually create great works of software that serve others well. But there is a greater work.

This is the work of God, that you believe in Him whom He has sent.
(John 6:29, New American Standard Bible)

Again, you don't have to believe that now to come to the Craftsmanship Academy. You don't have to believe that in order to graduate. There are greater consequences to what you believe than that.

_{Photo by Ivan Aleksic on Unsplash}

On Friday night, I had dinner with the family of a dear brother who has been in construction for years and has been thinking about making a change to the software field. He has built his own web sites on multiple occasions and when he was younger "spent too much time on the computer". He's always loved it but it has always been a distraction to what he thought he needed to do to make a living.

He took my advice and looked at the Learn To Program book and has been breezing through it as I suspected he would. I've seen him work and know that he is tenacious. I know he can concentrate for hours at a time and do incredibly fine work (his specialty in the construction field is trim work, and he's done a lot of it in very high end homes with very elaborate trim). He has run a business and strives for customer satisfaction. He already has the mindset of a craftsman in many ways. If he decides to dive in completely to the software field, I'm confident he could be an excellent Software Craftsman.

Early this morning, I ran across a blog post, It’s Not Too Late to Learn How to Code.

Later this morning, Mitch Amiano, an independent software developer who has done some work with RoleModel, dropped me a note,

Are you looking for anyone in the 30s age range?

There was a guy at the RDU BarCamp this year, [name deleted], who is looking to get into a more technical field. He seemed a little self-effacing but from what little I know about his past history he doesn't shy away from hard work or long hours.

He currently works in a position that will be changing in the next 10 months. He is their "tech guru", but (according to him) that was because of how little the others know about technology. I would imagine he would be somewhere at a beginning apprentice level from a software standpoint.

I was very fortunate that I had my first taste of programming when I was 17 and liked it. I went to college at a good engineering school and had co-op jobs starting my sophomore year that confirmed that I was both good at it and loved it. After a second co-op job, I had seen enough to know that I wanted to work with smaller teams doing innovative work rather than at larger companies doing work that many people did to support the infrastructure at the large companies.

However, I remember listening to some of my peers at college in their senior years saying, "You know. Now that I've started getting a feel for what a {fill-in-the-blank} engineer does, I really don't like it. But after paying for 4 years of school, I don't think I have much of a choice but to grin and bear it for a few years, and hope that I make enough money and find an opportunity to do something I'd really enjoy. I'm certainly not going to tell my dad that I want to go back to school for another few years to try out something else."

It takes a lot of courage to make a job change and go back for training to do something you only think you might love. Perhaps there is a stigma that making a career change, or going back to school, points to some sort of failure. Perhaps it is just the financial risk that would keep you from doing it. The price of a four-year degree is not just the money, but the time… four years of your life before you really get to try it! (Or, it could be even more if you are doing it at night and on weekends). We've tried to make it easier than that with our immersion approach, but we are certainly not going to imply that the cost in time or money is insignificant. It is not an easy decision to invest in a change of careers.

On the other hand, although it is far from a scientific study, I would venture to say that the majority of people I have met who have

• really committed to changing their careers,
• sought counsel from those in other fields who knew them and knew their character qualities and personal bents until they found a field that they were excited about and had their natural abilities confirmed, and
• were realistic about how much time and work it would take to do so and tackled it,

have been very successful.

I recently extended a job offer to have someone join us on the RoleModel Software core team. He had only been programming a few years after getting a couple of degrees in mathematics, gaining a couple of years teaching experience, and earning a seminary degree, before getting his first job working with software and design in his late 20s. He cared about doing his work well, and learned a lot in those few years, and is well worth hiring.

Some of the best software craftsmen I've ever worked with didn't have any sort of degree related to computers. Many of them started programming in their mid-20s or later. I've met some who started much later. Every single one of them learned things when they weren't programming that made them better software craftsmen. In fact, I would assert that most software craftsmanship is about making the computer do things to make life better for someone who is not a programmer. A programmer who doesn't have empathy for those they serve is rarely a software craftsman. Though he may call himself a craftsman, he is merely a geek. Someone who has lived a life away from a computer may have actually picked up some very useful skills that other geeks never pick up. These skills help the former become a software craftsman while the latter never leaves an isolated life of geekdom.

Software craftsmanship is not about the "mutual admiration society" of geeks. If a programmer only programs in ways that can only be appreciated by other programmers, there is a problem. We all know of so-called "art" that only impresses the so-called "artist." Michelangelo never had to point out that his work was a piece of art to anybody. Some would give anything to have watched him work. Others would rather watch grass grow. All would appreciate the final result.

Software Craftsmen ship. They ship software to others who need it. Those who need it appreciate it when it actually meets their needs and feels like it was designed and built for them. I was recently interviewing some of a client's end-users as we explore how to build their next-generation system. When I asked one of them where his pain points were, he said, "The system feels like it was designed by a programmer."

If you have ever been the beneficiary of software that you loved, and the victim of software that you have hated, and have a feel for what makes the difference, you have an asset that many geeks don't. If you have ever done something out of the norm to satisfy a customer on their terms, rather than redefine the customer's problem to something you thought was more interesting, you have an asset that many geeks don't.

If you can concentrate long enough to figure out a problem, wrestle it to the ground, and fix it, you have an important quality that can help you become a software craftsman. If details matter to you, but you don't let details that don't matter yet keep you from recognizing the bigger problem (and the next problem) you are trying to solve, you have another quality that it takes to be a software craftsman. If you are more than 24 years old, you don't have the quality that it takes to become 18, but I hope you will have the courage to overcome the presuppositions of others if you want to become a software craftsman.

• Do you have the ability to reflect on what you've done, learn from it, and make appropriate adjustments before you take the next step?
• Did you do well at word problems in Algebra or excel in other areas in which problem-solving using abstraction was necessary?
• Have you already done some programming, and enjoyed it?
• Does the idea of building software that other people value, use, and love, get you excited?

Whether you are 18 or 45, we'd love to have you apply and let us determine if you have what it takes to join the others striving to be software craftsmen at the academy.

_{Photo by Rémi Jacquaint on Unsplash}

HOLLY SPRINGS, N.C. OCT. 11, 2011 — Heeding the call for more skilled software craftsmen, North Carolina-based RoleModel Software has just unveiled a new training model for educating the next generation of developers. Built on the premise that the best way to get a software craftsman is to grow one, the RoleModel Software Craftsmanship Academy is now accepting applications for its first semester, beginning in May 2012.

Led by well-respected instructors, the academy offers an immersive six-month course of study that launches students on the road to becoming proficient software developers. Due to its intensive nature, the course is only for the dedicated. Successful learners will master the basic building blocks of the software industry, culminating in a one-year paid internship at a software company.

The RoleModel Software Craftsmanship Academy is ideal for dedicated high-school graduates — including homeschoolers — who already have a firm grasp on the basics of computer programming. The academy also is tailored to college graduates, those who wish to switch careers, or those who realize that college hasn’t prepared them to become expert software craftsmen.

“Anyone who considers themselves a craftsman would take someone trained this way over someone trained in a university setting, every time,” said Ken Auer, a 25-year veteran of the software industry and creator of the academy. “In addition, you can’t argue with the economics of this model versus the college approach.”

The program is limited to eight slots — meaning the entry process is highly competitive. At the close of the 18-month training, internship, and final examination, successful participants will be “certified journeymen” capable of becoming well-paid and sought-after software craftsmen.

The RoleModel Software Craftsmanship Academy already has won praise from top leaders in the software industry: Daniel Steinberg, trainer, author, and CEO of Dim Sum Thinking: “Ken’s unique approach immerses the novices in real-world problems that provide the opportunity to achieve specific goals and gain a broad understanding of their craft. As the students gain more experience, they are consistently asked to do more. When they finish the program, they’re ready to begin.”

Micah Martin, co-founder of 8th Light: “We’ve been training apprentices for five years and the results are undeniable. Students learn far more about developing software far faster than any other means of education. Apprenticeships with institutions like RoleModel Software Academy are the absolute best way to enter the software industry.”

Bruce Anderson, software educator, consultant, and pioneer of software design patterns: “Ken is able and conscientious. He ‘walks the talk’ in all aspects of his endeavors. Attending the academy will be a life-changing experience for attendees. It will prepare them for productive work in the software business in a way that no purely academic program can do, and make them ready for lifelong learning.”

ABOUT ROLEMODEL SOFTWARE Auer, an accomplished master software craftsman, founded RoleModel Software, Inc. in 1997. His goal — helping clients “turn innovative concepts into reality.” To learn more, visit RoleModelSoftware.com.

_{Photo by AbsolutVision on Unsplash}