Numărul 142
Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
Numărul 118
Abonament PDF

Interview with Mark Seemann

Ovidiu Mățan
Fondator @ Today Software Magazine


Congratulations for your latest book, Code That Fits in Your Head: Heuristics for Software Engineering! A lot of great software engineers like Robert C. Martin, Kevlin Henney, Adam Ralph and may others are saying good words about it in the preface. It also makes me happy to see a such "family" and I think we might contribute also due to conferences like IT Days or The Developers.

Your book is under the umbrella of Robert C. Martin series, tell us what this mean?

Addison-Wesley, they publisher, have various different book series headed by a well-known figure. In addition to the Robert C. Martin series, there's a Martin Fowler series, a Kent Beck series, and so on. Typically, these authors also publish their own books as parts of those series, but the intent it always to include other voices that are congruent with the themes of the series editor.

Apart from Robert C. Martin's own books, the most famous book in the series is Michael Feathers' Working Effectively with Legacy Code.

As I see it, being part of the Robert C. Martin series is a stamp of approval. It didn't impact my writing in any way.

The first chapter starts with a comparation between building a house and a software project. You are right, even if looks the same, we are not building software in the same way. Which do you think are the best steps for building a project, if any considering CD, and how should look a house built in this way?

I consider the house-building metaphor fundamentally flawed. You can't build a house by starting with the roof, or by completing only the kitchen.

One idea I discuss in my book is the notion of a vertical slice of functionality. Complete one fully functioning feature at a time, in sequence. Imagine building a house where the first thing you do is build a fully functioning kitchen, and nothing else. The kitchen must have roof, floor, walls, a drain, running water, electricity, appliances, refrigerator, stove top, pots, pans, knives, cutlery - everything. And yet, that would be the only room in the house. There would be no bathroom, no dining room, no bedrooms, no entrance.

That's not a practical way to build a house, but it is a practical way to develop software.

This is because software is intangible and malleable in a way the physical world is not.

Anyone insisting on treating software development the same as building a house is fundamentally misunderstanding how it works. And a lack of understanding is hardly a recipe for success.

Software developers vs. software architects. Do we still have this difference, or any developer should know a little of software architecture as he/she should know about DevOps too?

I think it'd behave all developers to understand software architecture.

It's often said that programmers should understand the 'next layer down' in terms of abstraction. I believe it's also important to understand 'the next layer up'. If you don't understand the context in which you work, you can't make good decisions. And in programming, you make decisions all the time.

There are various kinds of software architects. Enterprise architects should concern themselves with strategic questions. I don't think all programmers need to involve themselves at that level of thinking, but I think that they should understand the architecture of the code base in which they work.

One major problem, however, is that most code bases have no architecture - or rather, they are examples of 'the unarchitecture', as Vaughn Vernon and Tomasz Jaskula calls it.

Someone who is working for the same company 10 years or someone that changes them frequently, which one do you think will be a better programmer?

You can change role within a company, so who employs you doesn't have to be a limiting factor. Moving from team to team, from code base to code base, perhaps even from language to language, is what enables you to learn from others and grow. If you stay with the same team on the same code base for ten years, you run the risk of becoming specialized to a degree that you can't easily transfer your knowledge to any other place.

Programming as an art is the topic, we like here at Today Software Magazine. I remember your presentation from IT Days 2019 What I've learned about software development from the ancient Greeks. How do you see the relation between arts and programming today?

That title was always quite tongue-in-cheek. I used to see programming as mostly a craft - applied art, if you will. You can apply plenty of creativity to programming, and you can keep honing your skills until you retire.

In my darkest years, as it were, I viewed programming as little more than that. The implication to that kind of thinking is that there are few shortcuts to become a master of your craft. You have to put in the time, learning from existing masters. In that worldview, every new situation is unique, and there are few rules that apply outside of narrow contexts.

I've now, however, spent more than a decade coaching software development teams, and I began noticing that I would motivate various programming techniques with heuristics. I often noticed that such heuristics, or rules of thumb, would be helpful to teams because it gave them a vocabulary and a framework they could use to discuss coding decisions.

That experience, and encountering Hillel Wayne's investigation of what 'real' engineers do, has renewed my belief that it's possible to apply a more engineering-lke approach to software development.

Not that I think that this view eliminates the art in software development. I originally wanted to call my bool 'the art of software engineering', but reviewers and the publisher didn't like that.

Tell us few words about your presentation that you will have on the stage at The Developers.

The presentation is called Fractal Architecture, which is a concept from my book Code That Fits in Year Head. It posits that it's not enough for code to execute correctly. Assembly code can do that, yet that's not a language that people program in. Code must be readable in order to maintainable, and in order to be readable, it must respect the brain's cognitive constraints at all levels of abstraction.


NUMĂRUL 142 - Robotics & AI


  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • Yardi
  • P3 group
  • Ing Hubs
  • Colors in projects