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.
by Ovidiu Mățan
by Mihai Șerban
