Marco Valtas

Who's going to review AI code?

2026-03-05T00:00:00.000Z

This question popped into my head back in November 2025 when I noticed that more and more of the code I reviewed and created was being generated with the help of AI tools. While four months feels like an eternity in this day and age, the question still remains: who's going to review AI code?

Disclaimer

These days, writing about AI without a two-week expiration date attached is quite the challenge. However, I believe there are some more stable topics and questions we can explore related to the subject, without the risk of becoming outdated by the time we finish this post. I use "AI-assisted programming," "AI," and "agents" somewhat interchangeably, and in all cases, I'm considering the LLM type of AI tooling and not others.

Each generation raises the floor

Grady Booch cites that the history of software is a story of increasing levels of abstraction, and I find this quite an accurate description. And when discussing the topic of AI assisted programming this represents yet another jump in abstraction.

The abstraction framing is excellent because it provides parameters for assessing how previous jumps in abstraction occurred. When transitioning from assembly language to C, from C to C++, or even from punched cards to magnetic memory, there's a period where both the current technology and the future abstraction coexist. This transition period isn't just about porting existing systems; it’s also meant to provide enough time for the new technology to be adjusted and proven viable.

Who's on the hook?

Before diving into viability, let me jot down a few lines about liability. I’m not referring to it in the strict legal sense but in the context of "Who did this?" Most software development isn't highly risky, so I wouldn't assume that all software engineers out there have had the chance to think deeply about the topic of responsibility. However I think I can frame it in a way that most software engineers can relate.

A new library has been released for whatever purpose you find most interesting. The library promises to solve common issues that arise from not using it, and it also makes the case that it will abstract parts of the routines you need to work on, freeing up time for more important tasks. When you start experimenting with this library, there's an implicit expectation that it does what it claims, at least in terms of functionality. This isn't about subtle bugs; the library works. After experimenting with it for some time, you decide to bring it into your codebase.

This whole process depends on the cost of integrating the library into your codebase, making it worth the hassle of learning it, as well as the risks that come with it. If the library is not stable from the start, you can still include it, but you're taking on a larger risk since you might not be sure about its overall stability or where it could leave you stranded. Note, you are, as the engineer responsible for the system, ultimately responsible for the overall codebase, even if you didn't review every line of the library.

Over time, the library has proven to be useful, stable, and reliable, so at this point, there are few concerns about any defects arising from it. The library's abstraction was successful, but more importantly, the liability of having it was balanced well enough that its use doesn't create a sense of imminent failure in the system. Adding a new tool, language, or build system, whatever it may be, all of these have a common trait: they absorb the liability of what they were designed for. If they don’t, your options are to either choose another technology or create one yourself.

The trust problem

I’ve chosen a liability framing for this argument, but we can ultimately reframe it as a trust challenge. Every time the topic of trusting what an AI agent says comes up, this old joke always pops into my mind:

All the professors from a university's engineering department win an all-expenses-paid trip to the Bahamas. They board the plane, and the flight attendant announces a warm welcome to the professors, mentioning that this airplane was designed by their very own engineering students. All but one professor stands up and leaves the plane. The flight attendant asks the remaining professor, "Aren't you afraid of flying in this aircraft?" He replies, "If it were my students who built and designed this thing, I'm confident the engines won't even start!"

Some of you might know that for certain applications, software can't be designed and programmed in the same way most systems are created. From formal specifications to considering bit flips caused by cosmic rays, minimizing uncertainty is crucial depending on the required reliability of the system. This process involves specific development patterns and verifiable testing gauntlets that ensure the system is within its risk margin.

Within our enterprise corporate systems, the bar is far lower but it is not non-existent. One cannot break production every other day because the changes were not reviewed. Which brings me back to the key point of this post:

The adoption of AI-assisted programming depends on how well it can absorb the liability of its use in the first place.

The point is that it's not about whether AI-assisted programming can be applied, but rather what degree of risk it can absorb. If we can develop processes and tools that create a better liability shift, then its adoption can grow until those techniques are no longer sufficient. In other words, the adoption and use of AI-assisted programming hinge on our ability to trust the artifacts produced; otherwise, the "gains" in productivity will be limited by our capacity to verify. More succinctly, if you have to review all line changes made by an AI agent, then its output is capped by that.

The verification gap

There are several efforts underway to create "better" ways to provide context to AI tools. However, all of them face one or more significant limitations of the current technology, along with another constraint: complex systems can seldom be specified without incurring unacceptable costs for most organizations.

Back at my previous job at Thoughtworks, we used to say that our consultants wrote a significantly larger amount of test code than production code. This statement was a direct result of Agile software development, the iterative process, eXtreme programming, and the fact that consultants would join ongoing projects with tight deadlines to modify complex systems that could be decades old without breaking everything else.

Testing frameworks, continuous integration, continuous delivery, and other techniques stem from our understanding that larger systems are complex. Software is mostly grown rather than designed, and having situational awareness of the current state of the system under change are key factors for most software development.

I believe that the pressure AI-assisted programming puts on the input side, by generating and altering larger amounts of code, along with the non-determinism of these technologies, heightens the need for verifying these changes. Unfortunately, I still find that not all software engineers are adequately trained in testing, as there have been few innovations in verification technologies. This often results in complex test codebases, slow builds, and high maintenance costs.

So, while innovation is advancing on one side, investment in verification technologies, techniques, processes, and other methods that engineers can rely on is essential for successfully shifting the liability of adopting these tools.

So, who reviews the code?

I hope I've shown that a successful adoption of these new AI tools into software engineering isn't just about how well or better they perform. Given the non-determinism and complexity of software-intensive systems, we won't be able to harness all this innovation without also advancing our verification technologies and modernizing our testing techniques. An engineer can't just overlook the risks of changing a system; doing so isn't engineering, it's gambling. Engineers use tools and processes to build safely.

First thoughts on coding with AI

2023-06-07T00:00:00.000Z

What is it like to code with AI? GitHub Copilot promotes itself as "Your AI pair programmer." A catchy phrase, isn't it? But can it actually live up to the title? And can it give our programming productivity a real boost?

Copilot is not a pair programmer

First things first, labeling "GitHub Copilot as a pair programmer" somewhat misrepresents what pair programming is all about. At best, it confuses people, and at worst, it could lead managers to discourage real-life pair programming sessions because, hey, we now have GitHub Copilot, right?

If your only exposure to pair programming has been a scenario in which a partner rapidly dictates the next few lines of code for you to type, without providing a rationale for their chosen implementation, without contemplating how their selections mesh with a future design, and without enlightening you about a novel function you've never encountered before, it's no surprise if you equate this with pair programming.

However, let's get this clear: that's not how a pair programming session should pan out. While this post isn't about the intricacies of pair programming, we need to be clear that AI assisted programming is something different, and making shallow comparisons between the two is not helpful.

Intrusively valuable

Upon my first encounter with GitHub Copilot, my reaction was a blend of "Wow, that's impressive!" and "Hold on! Let me complete my thought first!" This tool has an eagerness to help that can be a tad intrusive. To handle this, you can disable the "auto" part of its suggestion and trigger it manually via a shortcut. But should you do that? I believe not.

An AI system is there to suggest what it deems relevant or the logical next step. If you manually control when it gives a suggestion, you may miss out on some real gems. One feature that seems missing from GitHub Copilot's available plugins is a set time delay before suggesting. A controllable delay would help manage the interruptions while you're in the flow of typing.

Deceptively wrong

Let's acknowledge that there are many repeating patterns in programming. The main word here is patterns. I've found myself debugging an application due to some strange behavior, only to discover that the AI had inserted a line of code that seemed to follow a pattern but was actually incorrect.

Sure, we've all encountered code blocks with repeated patterns and thought, "This needs refactoring." But then, we often stumble upon tiny differences between similar lines. So, one must ponder a bit before extracting methods or carrying out other refactoring activities. AI makes similar errors—it recognizes patterns but sometimes gets the variations wrong.

Suggestions versus lookup

AI code assistants typically operate in two modes. The first is auto-completion as you type, and the second is generating code based on specific instructions. Unfortunately, the AI doesn't seem to distinguish much between these two modes. It suggests completions based on what you're currently writing, whether you're in the middle of a function or just beginning one.

The downside here relates to the length of the generated code and its context. The auto-completion feature can sometimes suggest entire functions, which are more often than not riddled with errors. The onus then falls on you, the programmer, to spot and correct these mistakes or reject the suggestion entirely.

This brings me to an important point: the impact on workflow. Accepting a ten-line code suggestion only to have to go back and correct it does not feel like a productivity boost. I wish there were a way to limit the size of the AI's suggestions. I'd prefer it to suggest a limited number of words while I'm typing, so the coding process could continue moving forward rather than backward.

Productivity

Whenever we talk about productivity in software development, we cannot overlook Martin Fowler's iconic article Cannot Measure Productivity. So, do the current AI systems make developers more productive?

To be brutally honest, I don't know. Claims like "It made my team 10x more productive" seem misleading. We've only had access to these tools for a short while compared to the time it takes to develop and maintain a large system. Is this apparent productivity boost creating technical debt? If so, at what rate? And will the AI be capable of paying off this debt?

Despite these looming questions, I can say from personal experience that AI can be a boon if used judiciously. Consider the omnipresent Google and how it affects software development. Despite its widespread availability, there's a learning curve to using it effectively. If used without some understanding, you might end up losing more time than gaining. On the other hand, if you know how to use it, you can save a lot of time.

Reading, debugging, and learning with AI

A significant part of a developer's life involves reading code more than writing it. How does AI affect these other crucial software development tasks?

A few weeks ago, I had to comprehend a piece of TypeScript code, a language I'm not very familiar with. I fed the code to ChatGPT piece by piece, asking it questions along the way. The AI was incredibly helpful, particularly when I used the "Explain like I'm 5" option.

However, there was a catch: the code was well-tested, and I used the tests to supplement my learning. Having unit tests helped the AI to segregate cases and implementation details, which facilitated my understanding. This experience resembled a pair programming session more than simple auto-completion.

Final thoughts

As I was writing this blog post, GitHub announced Copilot's new Chat feature, which now focuses more on comprehension rather than completion. Who knows, by the time I finish writing this, there might be another announcement. This field is developing at such a dizzying pace that I've questioned the relevance of this post several times.

Is there a way back from AI-assisted software development? Will it prove to be inferior to the good old Google search? I don't think so. Although we need to address numerous issues, such as copyright, the early results indicate that AI offers an upgrade. The technology may need fine-tuning, but the demand it has generated ensures it will be a staple in every software developer's life.

Remember when IDEs and auto-completion were sneered at, with the popular belief being that "a real developer uses a bare text editor!" There's no such thing as "real developers" or demand for it, but there's definitely a need for working code. AI definitely could help us to get there faster; for this reason, I don't think AI help in software development is going away anytime soon.

Build your own carbon intensity monitor

2022-10-29T00:00:00.000Z

While the Carbon Hack 22 is happening, I decided to create my own hacking project, a carbon intensity monitor. In this post, I'll describe how to put the monitor together, but you can just go directly to this project code on GitHub.

What's carbon intensity?

Carbon intensity is the rate of carbon emitted per energy produced. The power we consume at home will be on the scale of grams of CO₂eq per kilowatt/hour, or gCO2eq/kWh. So, if you have 100 gCO2eq/kWh carbon intensity and 1 kW in an hour, the power grid emits 100g of carbon into the atmosphere.

What's the purpose of knowing the carbon intensity?

Carbon intensity is not constant. Throughout the day, different energy mixes are present in the power grid. During the day, you have solar power, while at night, you don't. Here's an example of renewable sources in California throughout the day.

What that means is that the carbon intensity during the day in California is lower than at night because, at night, to cope with the absence of solar energy, natural gas enters the mix. If you want to emit less carbon while using power, you should use it when the carbon intensity is at its lowest.

Materials you will need

Raspberry Pi Pico W etc., are relatively cheap, but if you add tax and shipping, it would add to approximately 40 dollars.

Note on soldering: You will need to solder the Header Set into the Pico W; If you do not want to do that, you can purchase a Raspberry Pico W Pre-Soldered on amazon.com ($14.49)

Note on prices: These prices are from the time I'm writing this post; They certainly can vary.

Note on USB cable: You probably have a micro USB cable. I've listed it just as a reminder you need one.

Soldering the Header Set

If you bought Raspberry Pi Pico W Pre-Soldered, you could skip this part

Soldering the Header Set is easy if you know how to solder. If you don't know, I recommend watching some tutorials on YouTube. It should be simple. You need to find a way to hold the thing together while you solder. In my case, a breadboard did the trick.

Assembling Pico Display with Pico

Join both, taking care of aligning the USB icon on the display with the USB on the Pico.

Preparing the Raspberry Pi Pico W for your code

We're going to use micropython for our code. So the first step is to add it to our brand new Raspberry Pico W.

Because we're going to use Pico Display, we are going to use its micropython image. This image contains everything you need, plus the graphics libraries we will use. So, we will follow the same steps described here. But we will download the image from Pimonori.

Adding micropython to Raspberry Pi Pico W

From Raspberry Pi's official documentation:

The instructions are simple:

Download Pimonori's micropython image
Press and hold the BOOTSEL button on the Raspberry Pi Pico W and connect it to the USB while holding the button
The Pico should now show on your computer as a mounted drive/folder
Copy the image you downloaded in 1. to Pico's folder; it will automatically unmount and reboot.
Start using your Raspberry Pi Pico W

Writing and deploying your code into the Pico

The easiest and most friendly way to code in micropython for your Pico is to use the Thonny IDE. It has everything you need to write your code, plus it has a Python REPL, which is very helpful.

I suggest you try some tasks before diving into the final code:

1. Make the Pico led blink

This is the equivalent of Hello World in the world of microcontrollers.

import machine
import time

LED = machine.Pin("LED", machine.Pin.OUT)

while True:
    LED.on()
    time.sleep_ms(500)
    LED.off()
    time.sleep_ms(500)

2. Use some printing for later debug

Keep this at hand; you might need to inspect some values if things don't work as expected. I'm also showcasing that micropython supports f-strings.

import machine
import time

LED = machine.Pin("LED", machine.Pin.OUT)

for i in range(10):
    print(f'{i=}')
    LED.toggle()
    time.sleep_ms(500)

3. Connect to the Wi-Fi

The Pico has a 2.4GHz antenna, so you need a 2.4GHz Wi-Fi connection. Most routers are capable of 2.4Ghz network unless you explicitly disabled yours.

This code is from Connecting to the Internet with Raspberry Pi Pico W section 3.6. Don't use it for production. This code is missing handling connection errors.

import network
import time

wlan = network.WLAN(network.STA_IF)
wlan.active(True)
wlan.connect('Wireless Network', 'The Password')

while not wlan.isconnected() and wlan.status() >= 0:
print("Waiting to connect:")
time.sleep(1)

print(wlan.ifconfig())

4. Play with the Display

Now explore the capabilities of the display, Pimonori's picographics has an excellent API. You should check at least these demos:

Getting access to CO2signal API

For our carbon intensity data, we'll use CO2signal. It provides very convenient data for us with the intensity and percentage of fossil fuels in the power grid. Note that this API has rate limits, 30 requests in an hour and 1 request per second. So, be careful to not overwhelm their servers.

You will need to find the longitude and latitude of your home; you can use GeoNames for this.

After obtaining your API token you can test it like so:

% curl 'https://api.co2signal.com/v1/latest?lon=6.8770394&lat=45.9162776' -H 'auth-token: myapitoken'
{
    "countryCode": "FR",
    "data": {
        "carbonIntensity": 93.0727344671727,
        "datetime": "2017-02-09T08:30:00.000Z",
        "fossilFuelPercentage": 12.032514442152996
    },
    "status": "ok",
    "units": {
        "carbonIntensity": "gCO2eq/kWh"
    }
}

You can check the CO2 Signal documentation for more information.

Setting all up and deploying the code

Go to GitHub pico2eq and download this project code.

You will need to create a configuration file called config.json for pico2eq to work. Here's the template:

{
  "wifi": {
    "ssid": "YOUR_WIFI_NAME",
    "password":"YOUR_WIFI_PASSWORD"
  },
  "co2signal": {
    "token": "YOUR_API_TOKEN",
    "longitude": YOUR_LONGITUDE,
    "latitude": YOUR_LATITUDE
  }
}

You need to replace any YOUR_ with the appropriate information. This is sensitive information; take caution to not upload this file to the internet.

Once you have your configuration file, you can open Thonny and navigate to where the code is. You can now select everything and right-click to Upload to /.

After uploading your files, you need to restart the Pico by selecting the Menu -> Run -> Send EOF / Soft-Reboot. Click on it and, the Pico should restart.

After rebooting, you should see a connecting... on the screen, and after some seconds, you should see your carbon intensity reading.

That's it; you now have your own Carbon Intensity Monitor.

For more information about the code, such as error codes, button functionality, etc., please go to the pico2eq project on GitHub.

This website's 5th gen release

2022-09-11T00:00:00.000Z

This website went through another transformation. It began as a page on Blogger, then went to WordPress, to Jekyll (post in PT), to my custom engine in Clojure, and now in my custom engine written in Python. I'm rewriting it again because I'm using more Python than Clojure these days. Also, things started to break with the new releases of JVM.

Reduced page weight

Pages are slimmer now, partly by removing images I don't use anymore and by removing Google Analytics from the website. This website has too little traffic and no ads and does not cater to a particular audience. Which made me question why having the analytics in the first place. Moreover, I use a browser extension to block site trackers, so why do I have Google tracking on my website?

An excellent side effect of making the pages lighter is that they produce less carbon. According to the Website Carbon Calculator, the home page went from 0.06g of CO2 to 0.01g of CO2 per visit. It still feels like a lot, but it is better than 99% tested by the tool. I know that this is not an impressive achievement for a small website, but what caught my attention was that I could lower the emissions by a factor of 6.

Will the code for this blog engine be open-sourced?

That is a good question. Unfortunately, I'm not considering releasing the code. Not because it has any secret sauces in it, just because it is not in a releasable form. Since I'm a beginner in Python, the code is a bit messy, and it has some hardcode stuff I'm not planning to extract into configurations. Maybe in the future, if my Python improves, I can release it.

There’s one thing I can share, though. Writing code in Python is delightful. There is elegance and power in its simplicity. Listed down is part of the code I use to start a local HTTP server and rebuild the site if I change any file.

def preview():
    build_site()
    with PreviewServer.serve(4000) as httpd:
        try:
            log.info("starting file watcher")
            observer = Observer()
            observer.schedule(DirWatch(), str(RESOURCES_DIR), recursive=True)
            observer.schedule(DirWatch(), str(BLOG_ROOT_DIR.joinpath('layouts')), recursive=True)
            observer.start()

            log.info("serving at localhost:4000")
            httpd.serve_forever()
        except KeyboardInterrupt:
            log.info("interrupted")
            observer.stop()
            httpd.server_close()


class DirWatch(FileSystemEventHandler):
    """watch directory for changes, rebuild site if detects one"""
    INTERVAL = 2  # interval in seconds for a rebuild
    TRIGGERED = time.time()  # track time between builds

    def on_modified(self, event):
        # several events are triggered for each change,
        # we ignore them for INTERVAL seconds
        if int(time.time() - self.TRIGGERED) > self.INTERVAL:
            log.info('rebuilding...')
            try:
                build_site()
            # do not stop because of an error
            # just wait for the next file change
            except BaseException as e:
                traceback.print_exception(e)
            self.TRIGGERED = time.time()
        else:
            pass

One external library is in use here, watchdog, and the rest is out-of-the-box. There’s not much happening here; we serve our pages from our build directory and watch for changes in the sources’ directories. If a change is detected, then we rebuild the site.

Conclusion

I’m taking the opportunity of revamping this website and learn more Python, which is a delight to write. You should try it too.

Project Euler script help

2021-02-21T00:00:00.000Z

During this pandemic we get bored. Staying at home prompted me to find programming exercise routine. For years I know about Project Euler but I never attempted myself. It is a series of increasing difficult Math/Programming challenges which you answer one to get to the next one. After you get the correct answer you might look at others answers in the forum.

It's a simple concept and a powerful one, given the years it has being active the project has already seven hundred plus challenges. Which is definitely more than I will be able to do in several months. Check it out if you want practice our problem solving.

Helper script

Of course this was another opportunity to automate something thing out. I'd guess that most attempt to solve the problems in one programming language. In my case I saw the opportunity to also practice languages I already know and ones I want to learn.

Adding new languages presents a problem, you got to run the solution for all of them. You need to keep track of how your run, the ones that you already solved and etc. So I made a zsh script that helps you on that.

Euler is a simple script that given a certain configuration will run exercises in the languages you defined. Here's how it looks like if you run for a simple Hello World!.

There are more options which allow you to run an specific language, show the solution instead of running and so on. Please check the README.

By default, or the languages I'm working on, are: Clojure, Wolfram Language, Lua, Java, SQL, Zsh, Ruby, Raku and Python. You can add or remove as many as you like.

Birr - Simple URL shortening using WSGI

2019-11-28T00:00:00.000Z

For sometime I used several of the URL shortening services, while useful I rarely used them for a long lasting web link. Most will charge you for a mnemonic redirection and there's always the lack of control of the hosting, analytics and so on.

So I decided to write my own and Birr was created. It is a very simple redirection code written in Python which takes a configuration file and redirects a URL into another. Check it out in https://mvaltas.com/birr.

2018 a year of bureaucracy learning

2019-05-05T00:00:00.000Z

If you ever visit to this blog more than once a year you notice that not much happened here in 2018. The truth is that a lot happened and because of that I was unable to write. In a nutshell we moved to the US. And to get here was a year of planning and executing different things from getting the VISAs to research about the public school system.

Here's a list of topics I learned about:

Deductables in health insurance
Flexible Spending Account (FSA) and/or Health Savings Account (HSA)
W-4 form and W-2 forms
401(k) savings program
Credit Rating (FICO) / Secure Credit Cards
Zelle and/or different ways to electronically transfer money
Cashier's Check / Money Order
Social Security Number (SSN)
Public school enrollment rules and processes

This list is what comes to mind when I think about the differences between Brazil and US. Truth to be told these are not of unattainable understanding and certainly there are parallels between the two countries bureaucracy. It just that you do not think much about it until all names change and you need a refresh course on all.

Cheers.

Nothing like a bee sting to get you moving

2017-12-11T00:00:00.000Z

Writing this post fees like cheating, I’ll tell you why in a few lines. Sometime ago somewhere I heard about Beeminder, but never had courage to use it. This changed a couple weeks ago after an unfortunate online psychological quiz that told me I work best when held accountable.

I’m an honest procrastinator, by honest I mean I know what I am and I’m always working to mitigate the problems caused by it. I keep revising goals, maintaining tasks lists, alerts, checklists, ... but one ingredient was missing; of all methods I use none hold me accountable if I fail, but Beeminder can.

For those who don’t known what Beeminder is I will sum it up. Set a goal, commit money to reach it and track it. There’s two possibilities after this or you meet your goal or you do not. If you accomplish what you set out to do you are fine, if not, the money goes away the committed amount rises and the cycle restarts. Sounds tough?

Let’s check, this is my progress chart on blogging from Beeminder.

After analyze this chart you’ll see I’m on the hook to publish a post on my blog or I lose ten bucks. And that’s why this post feels like cheating. But this post is the whole point.

When I mention to colleagues about it most of them tremble with the thought of losing money by not fulfilling self-imposed commitment. I relate to that as this was my reaction when I heard about Beeminder. But as the more I think about this the more this fear of commitment makes little sense. Why should us be afraid of pursuing our own goals? What drives us to assume we have no control? If not by thoughts like this, the fear of committing is unjustified. I leave you to think about it as I’m thinking about this too.

Cheers.

Magic Quality Gates

2017-11-24T00:00:00.000Z

How much quality is enough?

This is a tricky question, sounds like we can find a storage to pick quality amounts until we get enough. We know this is not it, still we struggle to talk about software quality in the context of its development, and the struggle leads companies to create magic quality gates to protect themselves.

A quality gate is something that somehow decides if the software is worth to go to production.¹ Test coverage is a classic number from where to build a quality gate. High quality software usually has high test coverage, but the catch is that coverage is a necessary but not sufficient condition to high quality.

“Testing shows the presence, not the absence of bugs.” Dijkstra (1969)

Coverage makes a bad gate. Just a quick math on the amount of conditions and combinations of inputs and states in a piece of software should be enough to discourage testing everything. Even a 100% coverage is a line execution metric and not all combinations were tested.

Someone somewhere in your company had an epiphany and uttered: “Software created here should have no less than 80% test coverage.” What about the 20% left untested? It can fail? And what if in this 20% there’s a crucial piece of code? You get the idea and also check this post for more discussion on test coverage. No magic creates correlation that does not exist, such incantations result in rule beating.

What’s happening is that people worried about software quality want to solve this problem exclusively in the domain of software development. Meanwhile the quality manifests itself in live working software. Without observing the software in its running environment there’s so much information we can obtain.

For that you need DevOps. No, you can’t buy it or create from nothing. You need to engage in practices which will approach the development people to the operations people and from this mix DevOps happens. Unless DevOps manifests itself through collaboration of development and operations, the quality of your software will be suboptimal. Start by measuring anything and everything and cultivate a curiosity for a lot of other interesting metrics which helps operations and development to find ways to improve quality.

The gates should be self-imposed by the teams from metrics that matter to them. Not by some general rule disregarding the context in which the software will be created and run.

Returning to our first question ”How much quality is enough?” The only answer is: the most we can get in this context. There are practices which improve the quality, or better, the absence of problems in software. But there’s no magic number from which enough quality magic gates can be built.

Build pipelines are quality gates created by the team. These “magic gates” are outside of the team’s control. ↩

On boarding new team members

2017-11-18T00:00:00.000Z

Teams change and Software Development Teams are no different. When this change is about bringing someone new to the team, we call this process an on-boarding. This process involves tasks to integrate this person to the team and the project, but misconceptions and unrealistic expectations make this process challenging for the new person and for the team itself.

Belief newcomers manage alone a successful on-boarding creates these misconceptions. Some teams spend time with the new person presenting topics and instructions; but deep down the belief remains. “We need a fast learner, are you one?”, “We are in stressful times; we will need you to be productive right away,” “Here is the code and docs, ping me if you have any doubt,” and so on; these phrases reveal who in fact is responsible for a successful on-boarding.

A view which promotes certain indoctrination must occur before new teammates can help. An on-boarding period, “He’ll be on-boarding next two weeks,” is also a bad sign; it makes people ignore the newcomer for the next two weeks. A waste for a good opportunity for the team.

The team is accountable for the on-boarding

A cascade effect happens when the team assumes an accountable position. Documentation, if exists, needs to be effective to explain how the application works and why it works like that. Tools for automation need a “—help” option. Understanding of domain concepts need to be clear to all. And the team must ensure everyone can explain the project to anyone.

Software Development Teams need to develop teaching capabilities. The problems they solve as a group need to be communicated in different levels of abstraction and details. Project progress, challenges, negotiations with other teams, and finally the on-boarding of new members will benefit if the team knows how to teach. And the best way to learn and perfect these capabilities is to practice them.

New team member collaboration from start

Someone new paying attention to what the team has to teach is a golden opportunity. Did this person understood what this project is about in the first few hours? Can any team member answer a basic question about the project? Commitment to understand the project is an excellent counter measure to the Curse of Knowledge; forgetting how is to not know something once you already know it. Here is an incomplete list of things a new person on the team can help from start:

Create a safe environment for learning
Review the software architecture
Train business analysts and team members to explain the business
Review documentation
Domain design
Identify gaps on path to production knowledge and process
Improve automation tools
Improve secret sharing and revocation
Exercise presentation skills (creating and presenting)
Review tests and pipeline for clarity
…

Setting it up

To work the new person needs a safe environment on which to ask questions and know, as simple these might be, are expected. Creating the safe environment is crucial for this to work, if someone feels insecure they will refrain from asking questions, communicate failure in understanding, and other behaviors that hinder a successful on-boarding.

Assessments on the on-boarding process should be done through measuring outcomes and not pure definition know ledge. Often on-boarding spreadsheets list topics such as “Know what is X,” “Know what is Y,” “Do Z,” “Do W,” and variations. These measurements can be improved by assessing abilities and not just definitions and repetitions. Examples “Can deploy head to production.” “Can destroy and recreate local environment.” Abilities are more decoupled from tools, last longer, and can drive the improvements the team want to focus on.

To ensure team members perform all tasks during the on-boarding is good to track these tasks and rotate individuals on each on-boarding. Always bring the newest on the team to help.