PotD 2: Yago Hortal (September 6, 2010)
Pp32 by Yago Hortal (2009)
Getting to “bare metal” (September 2, 2010)
Have recently finished reading Peter Seibel’s “Coders at Work”. If you haven’t heard about this book yet, it’s a very well-written collection of interviews with some of the most influential people in our industry; the names of those author talks to vary from Crockford and Bloch to Norvig and Knuth. Apart from being a very inspiring read, the book gives a very interesting perspective on some questions Peter keeps asking over and over. “Do you consider yourself a scientist, an artist, an engineer, or a craftsman?” “Should all progammers be able to deal with low-level things even despite that this ability is rarely needed nowadays?” “Do you still write code?” The question on low-level programming is among the most interesting ones. Are there any differences in one’s performance with and without that knowledge?
I guess there are. Without having a big desire to fall back to the original topic of my blog, I want to point to a recent issue we had with our biggest SLEE-based project. This is the first project where we are using big branchy trees of SBBs in our application and the first one that showed such a bad results during the initial performance tests. What is happening? Why is it so slow? After several nights and weekends spent staring at the CPU profiler and thread dumps and a help from our vendor, the root cause of the problem became clear.
When the event flow is being delivered to the SBBs in the same tree, event router thread does not have any choice except for locking the whole tree. After all, there’s a SLEE transaction ongoing and the state of the SBB tree should be kept consistent. Other event router threads at that moment are waiting for the tree to be freed, even if they try to deliver the event to another SBB in the tree. More blocking time, higher latency, lower performance.
Interesting is that JAIN SLEE just like any similar event-driven framework tries to isolate the developer from threading almost completely. But it’s clear that a developer can’t even diagnose a problem like ours without resorting to knowledge about thread states. So personally I have no doubts about the necessity of this knowledge. And I think our playful age of Mongrel and Cucumber gives more opportunities to learn low-level things with less pain. Ruby folks seem to discover fibers lately (green threads whose execution is controlled programmatically) so there will be a lucky few who will master the art of its scheduling. I myself had a chance to play with the Java emulator of x86 PC — seriously, having the possibility to compile your C program, take the binary, and see how Processor.processProtectedModeInterrupts() is executed in your Java emulator is astonishing.
I’m excited to read about other people thinking the same.
David Heinemeier Hansson in Jason Calacanis’ This Week in Startups (March 22, 2010)
A video of the most recent This Week in Startups episode with David Heinemeier Hansson started some heated discussion on the web lately. Even if you have not been a part of the debate, I strongly encourage you to watch this video (the interview starts after some 47 minutes of discussion; the video below skips them.)
The reader might be familiar with the David’s philosophy of doing business: it emphasizes profits (they are more important than market share, investments or anything else) and simplicity (minimalistic approach to products is the way the company could stay focused on delivering it and being frugal.) He sees the way chosen for 37signals as universal. When he evangelizing it, he is fastidious in his choice of words.
While it’s easy to fall for his “bad boy in the startups world” charisma, the interview gives a stark contrast between David’s tendency for overgeneralization and genuine experience of Jason. David is thirty and his interview host, Jason Calacanis, is ten years older. When placed together, they reveal the most attractive traits of each other’s personalities.
What I have enjoyed most in this video:
- How masterly Jason leads the discussion of some sorts of business models to its culmination, and how he ends this with a strong counter example like “Oracle might disagree”
- A discussion of work ethics. David: I always take Friday off. I prefer to work smarter, not harder. Jason: do you know what kind of schedule Steve Jobs enforced in Apple in the early days of PCs?
- How Jason constantly repeats “interesting” on almost all David’s remarks, and after somebody tweets about that in the middle of the show, and Jason reads the tweet aloud, he never repeats this word again. This is what I call a brilliant speaker.
This line is a signal to scroll up and click Play. Enjoy.
Wrapping-up the architects topic (March 17, 2010)
The previous post on software architects gained enormous amount of views and comments. I guess I hit the nerve here; the nerve being the career management for tech people. Except for the selected few in the programming world (like Guido van Rossum or Rob Pike or Joshua Bloch) there are almost no engineers widening their field of influence without becoming entrepreneurs, just by being employed by someone. Now I am certain that I am not the only one bothered by that.
Among other insightful things, the comments for that post brought a link to Who Needs an Architect?, a Martin Fowler’s article. I can’t resist the temptation to cite Ralph Johnson mentioned by Martin in the text
One of the differences between building architecture and software architecture is that a lot of decisions about a building are hard to change. It is hard to go back and change your basement, though it is possible.
There is no theoretical reason that anything is hard to change about software. If you pick any one aspect of software then you can make it easy to change, but we don’t know how to make everything easy to change.
Martin writes a bit earlier referencing the talk by economist Enrico Zaninotto
One aspect I found particularly interesting was his comment that irreversibility was one of the prime drivers of complexity. He saw agile methods, in manufacturing and software development, as a shift that seeks to contain complexity by reducing irreversibility — as opposed to tackling other complexity drivers. I think that one of an architect’s most important tasks is to remove architecture by finding ways to eliminate irreversibility in software designs.
Most of the efforts behind the software architecture activity are focused on removing the need for it. I can’t be fascinated more about the extent how this fits into my vision.
Why I don’t believe in software architects (January 26, 2010)
A common train of thought in the employed hacker’s head: I enjoy hacking; I don’t want to become a pointy-haired boss therefore I’m not going for management; I don’t want to have anything in common with suits and meetings and investors and therefore would not go for entrepreneurship; but I still want to do some career management for myself. The option that seem obvious for him is to aim for becoming a software architect. If you ever found yourself in this way of thinking, think again, for there’s no such “software architect” job that you would desire.
On the first glance this seems wrong. There are dozens of open positions in software companies bearing this title. A quick search on Amazon for “software architecture” reveals thousands of titles. But first 50 results or so are dealing with the software modeling using some higher-level description language, which is usually UML, and sometimes more exotic choices are presented like Z Notation (anyone?). There’s even a book luring the described hacker into buying it with its title: Software Design: From Programming to Architecture (it is about UML modeling, too). The only exception is the useless collection of developers’ anecdotes named 97 Things Every Software Architect Should Know (carefully cached by Google here), but I tend to think that this is the exception which supports the rule.
But wait, shouldn’t software architecture be an activity which involves dealing with software itself and not the models of it? Book authors do not think so. I guess the reason for that is the fundamental dichotomy between programmers in different companies. A former colleague of mine wrote recently a piece on that:
From what I see, a typical Java-centered company is either a J2EE enterprise or a place where they care about util.concurrent. Amusingly, this seems to be a very clear dichotomy. In both cases, there is a pile of (de facto) standard APIs and frameworks which take considerable time to master. And people who gravitate to one of the two types tend to be rather apprehensive if not ignorant of the other
“J2EE enterprises” love “outsourcing-style interview questions”:
[…] an endless stream of extremely low-level technical questions on particular technologies and APIs. RDBMS isolation levels, the servlet lifecycle, the methods on EJB home/remote interfaces, JSP scopes. A design pattern for them is always one from the GoF book or Sun J2EE patterns guidelines. Characteristically, they do not care about your design skills or code quality and really like J2EE-style
For the recruiters or book writers “software architecture” is neither an activity nor a way of thinking, it is a way of determining the job title. In their reality “software architect” is the person squeezing 3rd party code into a conceptual software model. He clearly belongs to the J2EE side of the dichotomy though might not use J2EE at all. It is a person who values dependency on someone else’s software in favor of developing it. This sort of dependency may be good, but for the demanding subject domains this is a double-edged sword (Paul Graham covers this issue with his usual bias towards Lisp in one of his essays). The reason behind all that is simple: “architect” does not write code. Mr Joe Hacker, is this the career path you were dreaming about?
A curious reader might ask: why do you proudly claim to hold this title then? Because I believe in software architecture as a way of thinking. I see this as a capacity to deal with the huge problems and significant amounts of code nip and tuck with the in-house development team. I do even know a single good book on the subject: Eric S. Raymond’s The Art of Unix Programming. Even is you never will hack Unix, this is a very valuable book to read.
What about career path then? Well, I can’t give any personal advice here except for the “avoid advertised ‘software architect’ positions”. The best company will allow you to keep writing code while expanding your area of influence wider and wider into the company products at the same time. This is what really software architecture is about.
- No public Twitter messages.