The Mind of Steve

The reason for the detour is gone,  but you'll be taking those extra steps forever!  Our new CTO does not believe in Technical Debt. If you are not familiar with the concept, Technical Debt is a metaphor first proposed by Wade Cunningham in the early 1990s. In an Experience Report for OOPSLA 1992 (the annual conference for Object-Oriented Programming, Systems, Languages & Applications), he wrote: Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. ... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise. As a manager of teams responsible for maintaining apps built upon legacy code, I see the impacts of that technical debt on a regular basis. Some business logic got buried in...

3 C's: Curiosity, Care and Context Like surely every team of software engineers in the world, my team has been discussing, exploring, integrating, benefiting from AI over the past year. I am working on a series of posts for the coming weeks, exploring our successes and lessons. As their manager, I have reassured countless times that their jobs are not in danger, that we need their intelligence, insights and skills to make the best use possible of the new AI power and direct it toward our many system challenges and company goals. Almost as an aside in our meeting the other day, one team member summarized what the Human Dev brings as: Initiative, Diligence and Wisdom. His almost-throwaway comment in a larger discussion stuck with me and got me thinking. Today, I want to rephrase and slightly broaden his terms in this reflection. Why are none of the Devs on my team at risk of losing their jobs to AI? Because they bring at least three key traits that the team and the company needs, and...

QA Strategy part 2 - Q.U.E.S.T In Part 1 of my musings on a QA Strategy , I described my new assignment, with a QA team added to my direct reports. Since I had never had to lead and manage such a team before, I set out to craft a QA Strategy document, both for my team and ideally to be adopted by the whole company. I wrote of my possible pillars and the process of distilling them down into a more concise and workable set. As a reminder, I emerged with these five general principles to guide my QA decisions: (1) Quality is a shared responsibility (2) All quality activities should produce information that is measurable, visible, and actionable (3) Automate repetitive verification; use people for exploration and critical thinking (4) Test according to business and technical risk (5) Learn from production and feed those lessons back into development My whimsical streak emerged at this point. These guiding principles are fine, but can I shape them into a fun acronym to help them stick in my ...

    I recently had our QA team added to my managerial responsibilities. In my 8+ years as a Software Development / Engineering Manager, I have guided a variety of teams, projects, tech stacks. I started with a Desktop app team. Next were some MVC-patterned web app teams. A Platform and micro-services team.  A front-end team. Newly formed teams and well-established ones. Even an international team with everyone in a different time zone across 3 continents.  But what they all had in common was this: everyone was a professional software engineer. A developer. A programmer.  Now, for the first time, a QA team has been added to my role. An early impression was that there is a different approach, a different mindset, different skillsets in a QA team compared to a team of engineers. To help guide and inform my decisions in this new responsibility, I drafted a QA Strategy document. But to give it coherence, I started by discerning and defining the guiding principles of ...

Steve sporting his Buffalo Bills toque My Buffalo Bills were eliminated from the NFL playoffs last weekend, a sad day for me and for all my deeply devoted fellow fans of this long-suffering football team. Co-incidentally, just days earlier, I had watched the ESPN documentary Four Falls of Buffalo , about the team's singular achievement of reaching four consecutive Super Bowl games in the 1990s, only to lose every single one of them. The show took me back to my younger days. It was enthralling to hear the stories of the stars of those Bills teams - quarterback Jim Kelly, running back Thurman Thomas, all-world defensive superstar Bruce Smith and the cadre of talented receivers. I have vivid memories of those seasons; at the time, I had so much invested in the outcomes of those Super Bowl games. I remember sitting on the floor of my girlfriend's apartment - she had a better TV than me! - wearing my team's colours and holding my breath at every twist and turn in the action. But...

 SDM Insights: Protect Your Team In celebration of my fourth anniversary as a Software Development Manager (SDM), I've written a series of reflections on some lessons learned. See the full list  here . My team has been 100% remote from day one, with developers in multiple countries and time zones around the world. So we communicate a lot with online tools like Slack and Skype and Zoom. This lets the team better collaborate, and also gives a direct connection between Support and Development. Too direct, it turned out. Often Support would encounter an issue with a Client and ping the Development team. If no developer responded quickly enough, or if the issue piqued her interest, the Product Manager would regularly jump in and assign a developer to investigate the issue immediately. Everyone would then wonder, at release time, why the Development team was only able to deliver a fraction of the expected new features and fixes. The problem was in part a process that was too open to...