Posted on by

Design by Contract

Design by Contract is a software design approach that is helpful when we are building solutions from small building blocks that interact with one another through interfaces or APIs. The “contract” is the definition of how an interface or API is meant to be used. There’s a good description on the C2 Wiki, a reasonably good article on Wikipedia, and concise explanations in the Microsoft .NET documentation and on the Java Practices site.
Continue reading Design by Contract

Posted on by

Refactoring the Hard Way, Part 2

This is a continuation of an exercise to learn how difficult it is to add refactoring support to a text editor. There’s no intent to produce a fully-featured and robust solution, but just in case it proves to be useful I want to focus on a couple of tools that don’t already have satisfactory refactoring support for widely-used legacy languages.

To be clear: This isn’t a “lesson”. I’m not teaching you something I already know how to do. I’m writing down what happens as I try to teach myself how to do something that’s new to me. Others already know how to write refactoring logic and how to write extensions and plugins for editors and IDEs. Fair warning, in case that sort of thing doesn’t interest you.
Continue reading Refactoring the Hard Way, Part 2

Posted on by

Where does all the bad code come from?

Some of the top people in the software field spend a good deal of their time examining and improving the quality of existing code bases, and showing developers how to keep their code bases habitable.

Brian Marick kindly filled in a historical gap for me in response to the initial version of this post. He writes: “‘habitability’ was probably coined by Richard P. Gabriel in an article for Journal of Object-Oriented Programming. The article (‘Habitability and Piecemeal Growth’) is included in his 1996 book Patterns of Software (available at https://dreamsongs.com/Books.html). Thanks for the history lesson, Brian!

It’s worth noting that “legacy” doesn’t automatically mean “bad”. Code that is currently used by numerous people, companies, and government agencies to support activities that are important to them clearly brings value. That value is part of the legacy of the code. But we need a shorthand way to categorize code whose internal design could benefit from improvement, and the word “legacy” has penetrated the market in that sense.

One might expect that after all these years of harping on “code quality” and “clean code” and “software design principles” that the problem of poorly-designed code would have faded into the background by 2020. Sadly, the problem is more profound than ever.

Why might that be the case? I think there are four main reasons.

Continue reading Where does all the bad code come from?

Posted on by

Refactoring the Hard Way, Part 1

Many developers these days praise the refactoring support in Microsoft VisualStudio and JetBrains IntelliJ IDEA, as well as Eclipse variants. Those who enjoy working with other tools, like VSCode or Sublime Text or Vim often lament the limited support for refactoring in those tools.

What if we tried to roll our own refactoring support? What would be difficult about it and what (if anything) would be easy? Let’s try, and see where it leads us! Worst case, we’ll gain an appreciation for how much help refactoring tools are giving us. Best case…well, let’s not get ahead of ourselves.
Continue reading Refactoring the Hard Way, Part 1

Posted on by

Live online training: What’s different about it?

No one can predict when the virus situation will pass; but we all know it will pass. The question is, what will we have done in the meantime to position ourselves for new opportunities when the economy rebounds?

This is not a time for us to roll up and hide in our shells like frightened armadillos. It’s a time for us to build our knowledge and hone our professional skills, to prepare for the new opportunities to come.

I suggested recently that companies need to use this time to regroup, reset, and get ready for the economic upturn that will surely follow the present crisis, rather than just shutting down and hoping things will get better soon.

Hope is not a plan, and neither is releasing your most valuable and hardest-to-replace assets: Your people. On the contrary, this is the time to enroll technical staff in training, so they will be ready to meet the challenges of the new economy that will emerge from the present downturn.

Continue reading Live online training: What’s different about it?

Posted on by

Refactor Anyway

Have you heard or read statements like the following?

  • “Tests are the wall at your back. You gotta have tests or you don’t know what you’re doing.” ( Sandi Metz video; time index 9:35)
  • “Not using an IDE with refactor tools like the ones discussed above is a waste of time.” ( Brian Ambielli)

I’ve seen a lot of people paralyzed by this advice. But why? It’s good advice, after all.

I think the problem is advice like this assumes the listener has a certain understanding of what software development work entails, and an ability to synthesize information and apply new techniques in context and with the benefit of substantial experience that includes particular activities and skills.

Absent those conditions, advice like this can scare people. They assume they literally cannot or must not attempt to refactor code unless the code is already well covered by a comprehensive and meaningful suite of executable checks, and they have the privilege of using very specific tools that verify the refactoring is completed safely.
Continue reading Refactor Anyway

Posted on by

Remote Mob Programming: Lessons from This Week

A lot of people are doing remote Mob Programming sessions now that most of us are working from home. I participated in a few and hosted one in the past week. It’s been a good learning experience. I feel as if we (as an industry or community) are rapidly learning how to make this approach work for regular work, virus or no virus.
Continue reading Remote Mob Programming: Lessons from This Week

Posted on by

Handling Unplanned Work (Webinar)

Most software development teams today are using a process based on the idea of iterative development and incremental delivery.

Exactly how long the iterations are and how big the increments are may vary. Whether the iterations are treated as time-boxes or are used to establish a cadence may vary, too. But in general, teams are no longer using an end-to-end linear process for software development and delivery.

The details of various process models and frameworks differ, but the overall shape of the process is that teams carry out planning in waves or stages, zeroing in on near-term work close to the time they will start on it. Then they plan to bite off a reasonable chunk of the planned work and deliver it within a certain time frame.

We want to get in front of risks and external dependencies so that we will not stumble over them at the last moment, but on the whole we defer detailed planning and design until close to the time we will implement the software. That way, we avoid investing a lot of time in details that are subject to change.

We all know the mantra, “Plans are useless but planning is essential.” We all know that our plans are a best guess at a point in time, and nothing more. And yet, we all feel stressed when our plans are disrupted.

We know that unexpected things happen in the normal course of work. Priorities change. Urgent requests come in. Production issues occur.

And the processes we use – Scrum, Kanban, “Scrumban”, or some customized variation of these – include mechanisms to handle unexpected work gracefully.

Despite all these things, we still tend to react to unplanned work as if it were an emergency.

Is everything really an emergency? And what should we do when the unplanned work pushes our planned work aside?

In the context of software development, what’s an emergency, really? Is every unexpected occurrence a genuine emergency? How can we tell the difference in the heat of the moment?

Is it realistic to think a development team can take on more work than their capacity, just because the new work is deemed more important than other work in progress?

Is it sensible to gloss over software engineering principles, testing, refactoring, and general attention to detail in order to push code to production in a rush?

What are the mechanisms built into processes like Scrum and Kanban to handle unexpected, urgent work that wasn’t planned?

Why do people react as if they are required to complete everything that was planned in addition to every urgent, unplanned item?

What are practical ways to respond when an unplanned item comes up, that ensure we are delivering the maximum possible business value – with emphasis on the word possible?

Join us in the next First Monday Webinar to explore these questions and to consider the unique problems you are facing in your own organiztion. Two sessions with the same content are scheduled:

There’s limited participation, so that we’ll have time and capacity to explore your real-world situation. See you online!