Profile cover photo
Profile photo
Max Kanat-Alexander
Google, YouTube, Code Simplicity
Google, YouTube, Code Simplicity

Max's posts

Post has attachment
New Blog Post! "When you clean up code, you are always doing it in the service of the product."

There’s a point that I made in the book but which I have had to point out to people a few times since then, and so I wanted to emphasize it a bit more. When you clean up code, you are always doing it in the service of the product. Refactoring is…

Post has attachment

Post has attachment
Almost as long as I have been working to make the lives of software engineers better, people have been asking me how to measure developer productivity. How do we tell where there are productivity problems? How do we know if a team is doing worse or better…

Post has attachment
New blog post, in response to the discussion between +Kent Beck, +Martin Fowler, and +David Heinemeier Hannson yesterday. I noticed an underlying principle between all of the development methods they discussed, which actually seems to underlie almost every senior developer's process.

Post has shared content
Really enjoyed reading Code Simplicity by +Max Kanat-Alexander
A concise, clear look at how to design and develop software and really gels with my own views which is a nice confirmation.
I think it could be good for non technical folk too as there's no lumps of code. Shall be waving it around at work.

Available digitally and physically from the usual places

Software development can essentially be summed up as "taking the right actions in the right sequence." That sounds simplistic, but actually it's somewhat profound if you realize that it's the basic fundamental behind how we should think as software designers. Very often, we know the right actions to take, but if we take them in the wrong sequence, then a disaster results.

The easiest examples of this are in the field of code quality. "Write a lot of messy code and then clean it up" is a set of good actions in the wrong sequence. A better sequence is "write some code, then redesign while writing the next piece, and so on," as I cover in the chapter on Incremental Design in Code Simplicity.

This principle also explains why "launch and iterate" sometimes works and sometimes doesn't. It's about the sequence of features to implement, at what point you put user feedback into that sequence, and so forth. Saying "launch and iterate" is not enough, because it doesn't describe a whole development sequence.

This is similarly true with other common development philosophies--they work only so far as they produce the correct actions in the correct sequence. And since the correctness of actions depends on the specifics of a situation, the more "rigid" a philosophy is, the less likely it's going to work everywhere. That's one of the reasons I focused on helping people think rather than telling them what to do, in the book.

Anyhow, in general I suspect that all of software development can be summed up in one word, and that word is SEQUENCE.

Post has attachment
I discuss Incremental Development and Design with +Google Developers.

Post has shared content
Here's me discussing the Third Flaw--I find this one hits senior engineers from time to time, in particular.
3 Flaws In Software Design: Part 3: Being Too Generic
#design   #developers   #software  

In part three of the series, +Jeremy Walker & +Max Kanat-Alexander  discuss the third Flaw in Software Design, "Being Too Generic," from Max's book Code Simplicity: The Fundamentals of Software.

Link to presentation:

Post has shared content
Here's part 2 of my talk with +Google Developers.
3 Flaws In Software Design: Part 2: Not Making the Code Easy to Change

In part two of the series, +Jeremy Walker and +Max Kanat-Alexander  discuss the second Flaw of Software Design, "Not Making the Code Easy to Change," from Max's book Code Simplicity: The Fundamentals of Software. Also see the full presentation:

Post has shared content
I did a series of talks recently for +Google Developers on the Three Flaws of Software Design. Here's the first in the series: Writing Code That Isn't Needed.
3 Flaws In Software Design: Part 1: Writing Code That's Not Needed

This week, we'll be sharing a four part series on software design flaws, featuring +Jeremy Walker and +Max Kanat-Alexander. Today, in part one, they discuss the first Flaw of Software Design, "Writing Code that isn't Needed," from Max's book Code Simplicity: The Fundamentals of Software.

You can also view the full presentation:
Wait while more posts are being loaded