Episodes

  • Lowering Developer Onboarding Costs- Episode 34

    Lowering Developer Onboarding Costs- Episode 34
    Apr 17 2023

    You can find the code used in this video at the Clear Measure github

    In this episode, Jeffrey shares how to lower developer onboarding costs

    Situation

    Custom software is inherently expensive but there are plenty of easy things that your team can do to reduce those costs. I'm going to talk about one of them that aids tremendously when it comes to adding or replacing a developer on your software team. That is the one click build.

    Mission

    Anyone overseeing a software team cares about quality, efficiency and productivity. These are important because they translate directly to labor costs. Software teams are already expensive. What really hurts is when the team has suboptimal processes that balloon already high costs. When a new developer joins a team, many spend days or weeks onboarding until he can start working on the code and contributing code changes. It doesn't have to be this way. You should expect a new developer to be able to contribute code changes on the first day.

    Execution

    Let's go through a scenario. A new developer is ramping up on the team and he is eager to start making contributions. He wants to get the code up and running on his computer quickly. So, what's the first thing we do? We clone the repository from source control and then try to run the application. Invariably this fails. Why? Well, first off, there's plenty of dependencies that the local developers workstation doesn't have.  Namely, the SQL Server database and then probably several other dependencies that must be installed or must be set up in a certain way. The experienced members of the team have these steps memorized in their heads but of course, this is super secret tribal knowledge to the newcomer. Maybe there is a documented list of things that are necessary for proper developer workstation setup. If the list is kept properly then the new developer can follow the steps and get the application working. What invariably happens every time is that a more tenured member of your software team takes time out and helps the new developer get the software running on his workstation. You're always going to have the overhead of explaining to the new developer what the application is and how it's put together and the thought process behind it, but the time that is wasted is just the mechanics of getting the application running on a new workstation. This cost also exists when an existing team member is setting up a new computer. When setting up a new computer for the first time, the same setup has to happen.

    It's all unnecessary. What you should expect from your team is that the new computer or new team member experience is quick and automatic. The process should be two steps. First, clone the source code. Second, run a single command and then the application works. The one click build, as it is called, is a very simple script that checks for the needed dependencies on the local computer and installs them. If it's a dependency that does not have an unattended install, then it can prompt the developer with a clear error message with what software needs to be installed. But in today's day and age, most developer dependencies can be installed automatically. The most basic of these is the SQL Server database that all net applications connect to. Even small microservices are responsible for their piece of data and require some type of data store to be set up. 

    Conclusion

    To conclude, expect new software team members to contribute code changes immediately. Equipping them with the right onboarding process is your key to this reality. And a one-click build is a tool no software team should be without.

     

    Thanks to Clear Measure for sponsoring this sample and episode of Programming with Palermo.

    This program is syndicated on many channels. To send a question or comment to the show, email programming@palermo.network. We’d love to hear from you.

     

    To use the private and confidential Chaplain service, use the following:
    Gentleman: 512-619-6950
    Lady: 512-923-8178
    Show More Show Less
    13 mins
  • How to Measure a Software Team- Episode 33

    How to Measure a Software Team- Episode 33
    Feb 23 2023
    In this episode, Jeffrey shares how to measure a software team. Situation  Many software team lead architects don't implement management practices that are standard in other parts of the business. Whether it be OKRs (Objective, Key Results), EOS, Scaling Up's Scoreboard, or Kaplan's Balanced Scorecard, business measurement has long been a staple of ensuring that a part of a business was functioning well. But executives overseeing software teams often don't have a tool for measuring the effectiveness of a team or an entire software department. Mission Anyone overseeing a software group of any kind needs a way to measure the effectiveness of that group. Let's zoom down to a single software team and look at what must be measured at a minimum for a single software team. Once the measures are identified, the team can then report them weekly to the appropriate layer of management. And just like every other department, if the measures are aligned with business objectives, then the reports can be relied on to know that the objectives are on track to be accomplished. Execution The tool you need in order to measure a software team is a good, old-fashioned scorecard. It's not high-tech. Every business methodology in the last 3 decades has employed some format of the scorecard for the purposes of measurements that are tracked over time and given thresholds of acceptable values. We'll go over the Clear Measure Way scorecard template and how to use it. Mental Model From cash flow forecasts to sales pipelines and order shipping, most businesses are used to tracking numbers weekly. Some numbers are tracked monthly, but in software, weekly is better aligned with the normal flow of a software team. You can obtain the Clear Measure Way scorecard template for free from the Clear Measure website. It's a Microsoft Excell worksheet. The first tab is the scorecard itself. The next tab is instructions for how to use the scorecard. It comes prepopulated with the minimum suggested measures for a software team. As you become more comfortable with it, you'll undoubtedly add more measures to it. The researched DORA metrics are part of our minimum, so you'll find those on the scorecard. At the top of the scorecard template, you'll find a link to a tutorial article that explains how to use the scorecard and how the Excel template is put together. Each week, you'll have the team populate the numbers in the column that represents the current week. Over time, you'll probably choose to hide the rows in the past so that you can glance at the current week and probably the trailing 12 weeks, thereby getting a good glance as a rolling quarter of performance. Team Alignment The measures on the scorecard are divided by the pillars of the Clear Measure Way but are preceded by a Team Alignment section. We suggest that the software team's scorecard include the top-level business measures that are managed by the executive overseeing the team. Without tracking the impact the software team is making in the business, it's easy to become misaligned with business objectives. If you don't already have these quarterly targets, I'd invite you to use the free Team Alignment Template, also provided by the Clear Measure Way. We have plenty of information about how to align a software team to become effective. Once it's clear what the team is trying to accomplish, add those few measures to the scorecard. If the measures have an acceptable threshold, add that into column F. This will cause the auto highlighting to work, coloring green for numbers within the thresholds and red for numbers outside the threshold. Establishing quality The first pillar we suggest you measure is quality. This should be the first priority of any software team. Without it, a team cannot be effective. Without consistently high quality, the team will constantly be circling back to diagnose, analyze, and fix defects. This tends to accumulate, and teams without quality end up having little time left over to actually work on new features or valuable changes. We recommend a few essentials when it comes to measuring quality. - Defects Caught - Defects Escaped - Defects Repaired - Mean Time to Resolve Ultimately, you want zero defects to escape into production. But you also want to track the defects caught before production. Think about it, every time to move a card to the left on your work tracking board, that signifies a problem that has to go backward in your process to be corrected. That's a defect. Track it. Achieving stability The stability pillar looks at what is happening with software running in a production environment, serving customers. Two of the DORA metrics live here as well as a couple of others. Our goal is to empower our team to deploy changes frequently to production and at any time during the week, all without business disruptions. Additionally, we want to know that the software runs in a way that supports the users, again, without business disruption. Software spends ...
    Show More Show Less
    14 mins
  • How an Executive Oversees a Software Team- Episode 32

    How an Executive Oversees a Software Team- Episode 32
    Feb 9 2023
    In this episode, Jeffrey shared how an executive oversees a software team Situation Our industry struggles mightily with failed software projects. On average half of the projects still fail. Failure is defined as the executive who authorized the budget wishing he hadn't. The project is so over budget and so over schedule, that the company would be better off having never started it. Even in the middle of these projects, executives can feel powerless to abort it for fear of sunk costs. And without knowing the right questions to ask or the right reports to demand, the executive in charge doesn't feel in charge at all. He's left choosing between trusting the team still longer or the nuclear option to scan the entire thing. Mission Right now, if you are an executive overseeing a software group, I want to equip you with the tools to do that well. If you work in a software team, use this video to give your software executive the information he needs to know the project is on track or the insight to know what the team needs to do a good job. From here out, though, I'll call you the software executive. Even if you've never programmed any code, you are running a software team. Their success will steer your future career, so this is important. Don't keep going on faith. Don't proceed merely trusting that someone else reporting to you knows how to do your oversight job for you. Lean in. And I'll give you the questions to ask, the tools to use, and the practices to deploy so that you can safely guide your software project to success. And most importantly, if your current software project is veering toward failure, I'm going to empower you to stop the bleeding and get it back on track. Execution Before diving into the guidance, I want to paint a mental model for you. Think of every other department in the company. Think of every group. Think of every team branch on the org chart. Each one of them is responsible for delivering some output valuable to the business. And each of these teams also needs some inputs in order to deliver those outputs. And if the outputs are not delivered, the team's leader is typically replaced. And the leaders who excel are the ones that can set up the team members for success. Mental Model The factory is arranged well and operates efficiently every day in a safe manner. The assembly line flows at a good speed with incoming materials being delivered at the right cadence to keep going. Quality issues are prevented and detected very early. Hourly and daily throughput measures are tallied and reported up the management chain. Quality and throughput measures are paired with acceptable thresholds and established as a standard with better numbers as stretch targets. Then, the executive in charge ensures that the factory or assembly line is organized in a way where each team member understands the job and what activities it will take to meet the targets. What we don't do is declare a building to be a manufacturing plant, ask a team to come to work inside it, and then come back to check in a month later. The people we staff on the team are typically not the same people needed in order to design the process for how the team should work. And Scrum has done the industry a disservice by spreading the notion of self-organizing teams. Even the certified ScrumMasters are trained to ask the team what they want to do and then work to remove blocking issues to what they want to do. This isn't leadership. Only when a team is working in an efficient manner can the lower-level details be turned over for self-organization. An appropriate leader (you) is always necessary to put the overall structure in place for the team so that real measurable throughput can build momentum. I started out with a factory and assembly line analogy. And many knowledge workers will rightfully object that the nature of the work is different. And it is. Earlier in my career, I was one of the self-organization promoters, and I was banging the drum about knowledge work being inestimable or unmeasurable. But speaking for myself, what I liked most about that message was that it gave me space to dive into the work without having to report up as much. It gave me more space as a programmer. But what it didn't produce was less risk for the executive who authorized the project budget in the first place. This challenge exists in all the fields of knowledge work as well. Managerial accountants and CPAs also have tough problems that don't have rote solutions. The rote solutions have been automated away by good accounting software. But if your CPA takes forever to figure something out and then bills you twice as much as what you budgeted, you still have a problem. Sales is another area that has some similarities with the "magic" of software development. You want a certain pace of sales. And the staff just wants to get to work. But seasoned sales executives know that without a good sales team process, closed sales won't happen. And even enterprise...
    Show More Show Less
    46 mins
  • The Architecture of GPT-3 and How to Think About it in 2023- Episode 31

    The Architecture of GPT-3 and How to Think About it in 2023- Episode 31
    Feb 2 2023
    In this episode, Jeffrey discusses the architecture of GPT-3, the technology behind ChatGPT, and how you should think about this technology in 2023. Situation- ChatGPT is getting a lot of press because it's the first freely available implementation of GPT-3 that has captured the imagination of the masses. Many are pointing out the awesome and surprising capabilities it has while others are quick to point out when it provides answers that are flat-out wrong, backward, or immoral. Mission- Today I want to raise up the conversation a bit. I want to go beyond the chatbot that has received so much press and look at the GPT-3 technology and analyze it from an architectural perspective. It's important that we understand the technology and how we might want to use it as an architectural element of our own software systems. Execution Introduction- GPT-3, or Generative Pretrained Transformer 3, is the latest language generation AI model developed by OpenAI. It is one of the largest AI models with over 175 billion parameters, and it has been trained on a massive amount of text data. GPT-3 can generate human-like text in a variety of styles and formats, making it a powerful tool for natural language processing (NLP) tasks such as text completion, text summarization, and machine translation. Architecture of GPT-3 The GPT-3 architecture is based on the Transformer network, which was introduced in 2017 by Vaswani et al. in their paper “Attention is All You Need”. The Transformer network is a type of neural network that is well-suited for NLP tasks due to its ability to process sequences of variable length. The GPT-3 model consists of multiple layers, each containing attention and feed-forward neural networks. The attention mechanism allows the model to focus on different parts of the input text, which is useful for understanding context and generating text that is coherent and relevant to the input. The feed-forward neural network is responsible for processing the information from the attention mechanism and generating the output. The output of one layer is used as the input to the next layer, allowing the model to build on its understanding of the input text and generate more complex and sophisticated text. Using GPT-3 in a C# Application To use GPT-3 in a C# application, you will need to access the OpenAI API, which provides access to the GPT-3 model. You will need to create an account with OpenAI, and then obtain an API key to use the service. Once you have access to the API, you can use it to generate text by sending a prompt, or starting text, to the API. The API will then generate text based on the input, and return the output to your application.   To use the API in C#, you can use the HTTPClient class to send a request to the API and receive the response. The following code demonstrates how to send a request to the API and retrieve the generated text:   ``` using System; using System.Net.Http; using System.Text; namespace GPT3Example { class Program { static void Main(string[] args) { using (var client = new HttpClient()) { client.BaseAddress = new Uri("https://api.openai.com/v1/"); var content = new StringContent("{\"prompt\":\"Write a blog post about the architecture of GPT-3\",\"model\":\"text-davinci-002\",\"temperature\":0.5}", Encoding.UTF8, "application/json"); content.Headers.Add("Authorization", "Bearer API_KEY"); var response = client.PostAsync("engines/davinci/jobs", content).Result; if (response.IsSuccessStatusCode) { var responseContent = response.Content.ReadAsStringAsync().Result; Console.WriteLine(responseContent); } } } } } ``` End of demo From the start of this explanation, the text was generated by chat.openai.com. It can be pretty impressive. But, at the same time, it's very shallow. GPT-3 is a machine learning model that has been trained with selected information up to 2021. Lots of information, but selected, nonetheless. Here is the actual ChatGPT page that generated this. Notice that it admits that it doesn't have information past 2021. Let's dig deeper, though on what GPT-3 is and how it came to be. Let's look at the theory behind it so that we can see if we should use it as an architectural element in our own software. - Let's go back to 2017. Ashish Vaswani and 7 other contributors wrote a paper called "Attention Is All You Need". In it, they proposed a new network architecture for their neural network. Simplify that and think of a machine learning model. They create a method that could be significantly trained in 3.5 days using eight GPUs and be ready for a complete transition from one spoken language to another. They tested it using English-to-French and English-to-German. Vaswani and other contributors were from Google Brain, four from Google Research, and one from the University of Toronto. - In 2018, four engineers from OpenAI wrote a paper entitled "Improving Language Understanding by Generative Pre-Training". They lean on Vaswani's paper and dozens of others. They ...
    Show More Show Less
    22 mins
  • Why is my software team moving so slow?- Episode 30

    Why is my software team moving so slow?- Episode 30
    Jan 26 2023
    In this episode, Jeffrey discusses why so many teams are not happy with the pace of software delivery. Situation Most software teams we see are not moving at the pace their companies would like. One of the Clear Measure Way tools is a self-assessment. It's easy to find on the Clear Measure website. One of the subjective questions included is "are you happy with the pace of delivery of your software team?". Most respondents are not able to answer YES. We're going to talk about that. Mission- Many businesses have decided to have internal software development teams. Companies that are tech companies, have to. For others, it's a judgment call. Over the last 25 years, many non-technical companies have outsourced the creation of software. They lost a lot of money, didn't get what they thought they were going to get, and they have shifted to operating software engineering teams in-house. They still consider custom software to be strategic for them, but they want more control by hiring their own employees. But they are then frustrated that they don't actually have more control. They might have more visibility, but many are frustrated that having the in-house team doesn't actually increase the pace of delivery or solve every problem. The goal of this video is to go over the common categories of time suck that saps the capacity of software teams everywhere. My hope is that once you understand where all your team's time is going, you can make decisions to change that and redirect the effort to justify the progress you want. Execution- There are five categories of work for a software team: - Working on new software - Diagnosing or fixing or reworking past work we thought was done - Diagnosing or fixing the software as it runs in a production environment - Administrative, non-software work - Time off Working on new software This is where we want to maximize the effort. We want all of our team to be working on new software. This is where to build new features, make important changes, and enhance features so they work even better. This is all our internal and external customers ask for. They think our team spends all of its time in this category. In reality, some teams struggle to get time to work in this category.This category includes everything in the software development lifecycle. Talking about the vision for a new feature is part of this category. Doing architectural prototypes for options for new changes is in this category. Doing routine maintenance on our software is in this category. Yes, renewing a security certificate is in this category. It's expected important work. It's work we can see and work we can forecast. This is the type of work that software engineers and architects sign up for. The other categories are work that the team has to do in order to get back to work in this category. Diagnosing or fixing or reworking past work we thought was done This is the first type of waste work. This is where we realize that something is broken. Something we thought was done is not actually done. Software that was supposed to work in a certain way doesn't. Something is missing. Or we are surprised that now that thousands of users use our software, our computing performance in some areas is terrible. We didn't count on some database tables growing to the size they have grown to. We are spending time figuring out why we have a problem. Then, once we have reproduced the problem, we are trying to redesign something in the software so that we fix the problem. We lament that we didn't catch this problem earlier. Or perhaps we just made a change and something else in a seemingly unrelated part of the software just broke, and we don't understand how they could possibly be related. Diagnosing or fixing the software as it runs in a production environment This category is all about production issues. No feature bugs or build breaks or bug reports from UAT testing. This category is for all the time spent investigating an issue in production. A user submits a trouble ticket. Or a piece of our software system goes down and has to be restarted. Or a user has a question that was escalated to second-level support. Not only do we need to spend time to figure out if it's just user education that accidentally made it to the software team's queue, but we also have to spend time learning about the part of the issue that may be a genuine defect. Part of this category of work is properly equipping our own company's customer support team with a better knowledge base so that they can handle more basic customer issues. Not all of them should be coming to the software team. Part of this alerts that the production environment is sending to the ticket queue. Also part of this is when executives or salesmen call for special support because they want to do a customer or investor demo and they need some extra data pushed into a production or test environment so they can do the demo. In general, this is the category for any time spent because...
    Show More Show Less
    12 mins
  • Aligning a Software Team For High Performance- Episode 29

    Aligning a Software Team For High Performance- Episode 29
    Jan 19 2023

    In this episode, Jeffrey discusses how to align a software team for high performance. Recognizing that the team's architect is the leader and has a big job to do, a tool called the Team Alignment Template facilitates the documenting and teaching of the team's purpose, values, and other strategic decisions so that all engineers can work and pull in the same direction.

    • Situation At the beginning of a project, when a new team is formed, or when the staffing of an existing software team changes, all team members need to align and get going in the same direction. Without intentionally achieving this, each team member will have a small or large difference in the vision for how to proceed. It's the job of the architect to make clear the path and to align all team members on that path in order to establish quality, achieve stability, and increase speed of delivery.

    • Mission The goal of the Team Alignment Template is to:

      1. Help the architect clearly communicate the purpose, values, and strategy of the software team
      2. Team and align the software team in the same direction, working toward the same goals, and thinking in the same manner.

    • Execution The Team Alignment Template is a simple, 1-page document. After filling in the blanks, gather your team together and discuss the contents. Invariably, there will be discussion around some items in order to gain understanding. Any time the staffing of the team changes, and at monthly or quarterly boundaries, review the Team Alignment Template again.

    • Summary Without intentionally aligning a software team, each team member will have a small or large difference in how to proceed. This will result in reduced quality, stability risks, and missed opportunities for increasing speed of delivery.

    Download the Team Alignment Template

    Thanks to Clear Measure for sponsoring this sample and episode of Programming with Palermo.

    This program is syndicated on many channels. To send a question or comment to the show, email programming@palermo.network. We’d love to hear from you.

    To use the private and confidential Chaplain service, use the following
    Gentleman: 512-619-6950
    Lady: 512-923-8178
    Show More Show Less
    21 mins
  • Designing New Applications for Automated DevOps- Episode 28

    Designing New Applications for Automated DevOps- Episode 28
    Jan 12 2023

    In this episode, Jeffrey discusses how to design new applications for automated DevOps. Automating the DevOps process from Day 1 is part of the "Achieving Stability" pillar of the Clear Measure Way.

    • Situation Once a software project or new application gets going, the focus tends to be on features. And once code is being written but not being deployed frequently, the team starts to slow down right from the get-go. It might be tempting to think that you don't need devops automation just yet. But choosing not to put in a particular process is implicitly deciding to put in a manual process. The first bit of code you have will end up being manually built, manually tested, manually deployed, and manually monitored. Then the team will work on more code and more code, and bug reports will start flowing in, and there will "never be a good time" to put in the devops automation.

    • Mission The purpose of this video is to show you how simple and clear automated devops can be and how straightforward it is to put it in at the beginning when you don't yet have any code. Then, you never have a point in time where you have to "stop the bus" and "stop delivering features" in order to catch up with technical infrastructure that would have been so much easier at the beginning. Because along the way, automated devops causes you to design features just a bit differently. And if features are designed without devops automation, you'll have to retrofit later.

    • Execution At the beginning of a new application, you need to think about 7 different areas of your DevOps environment

      • Infrastructure
      • Source control
      • Private build
      • Continuous integration build
      • Release management
      • Deployments
      • Runtime observability

      What you see on the screen is a DevOps architecture poster from Clear Measure. Lots of companies have used it. It clearly lays out the architecture of your DevOps automation.

      • Poster can be requested from www.clearmeasure.com

    • Summary Companies that have adopted the measures and practices in the Clear Measure Way know the importance of DevOps automation and putting it in place on Day 1 of any new software application. I hope this helps you in your journey to establish quality, achieve stability, and increase your speed of delivery.

    Sample repository

    Thanks to Clear Measure for sponsoring this sample and episode of Programming with Palermo.

    This program is syndicated on many channels. To send a question or comment to the show, email programming@palermo.network. We’d love to hear from you.

    To use the private and confidential Chaplain service, use the following
    Gentleman: 512-619-6950
    Lady: 512-923-8178
    Show More Show Less
    18 mins
  • Empowering Software Teams Using the Clear Measure Way- Episode 27

    Empowering Software Teams Using the Clear Measure Way- Episode 27
    Jan 4 2023

    In this episode, Jeffrey discusses how to empower software teams using the Clear Measure Way.

    • Context

      • For engineering teams serious about delivering software

    • Achieving rare success

      • Resolve to be in the rare 17% of projects that succeed
      • The team rises and falls on leadership
      • Work for clear understanding & wisdom
      • Measure actuals & progress

    • Establish quality

      • Prioritize quality over speed
      • Prevent defects (escaped defects -> process failure)
      • Always working (first do no harm)

    • Achieve stability

      • Minimize undeployed software
      • Prevent production issues
      • Correct production issues quickly

    • Increase speed

      • Be honest about where you are & where you want to go
      • Assess team's speed capacity
      • Shift bottlenecks upstream
      • Break down work to issues the size of 1 man-day of effort
      • Simplify: minimize work needed to deliver the feature

    • Lead your team

      • Form your team
      • Equip your team
      • Design the environment your team works in
      • Set vision, targets, and process for your team
      • Establish priorities and show them the right direction
      • Measure your team. "A" players want a report card.
      • Monitor and adjust your team
      • Strengthen & adjust your team.

    • Exhortation

      • You have what it takes to lead your team. You can do it. By implementing these principles, leading your team with a scorecard of relevant measures, you will emplower your team to establish quality, achieve stability, and increase speed.
      • I know you can do it. And we are here to guide. May God grant you wisdom as you lead your team.

    Sample repository

    Thanks to Clear Measure for sponsoring this sample and episode of Programming with Palermo.

    This program is syndicated on many channels. To send a question or comment to the show, email programming@palermo.network. We’d love to hear from you.

    To use the private and confidential Chaplain service, use the following
    Gentleman: 512-619-6950
    Lady: 512-923-8178
    Show More Show Less
    25 mins