Bruno Zanchet's blog

Don't make me think

2010-05-15T08:00:00.001-03:00

"At Sears, I really only need to see the name on my way in; once I'm inside, I know I'm still in Sears until I leave. But on the web - where my primary mode of travel is teleportation - I need to see it [the logo] on every page."

Quite basic one. Very quick read - I'd say around 2-3h. Lot's of basic concepts, but also some interesting stuff inside.

If you don't want to read it yourself, at least make sure that your UX, designer, product owner or whatever read it!

A theory of fun

2010-05-10T21:31:00.001-03:00

"We get positive feedback for climbing the social ladder. We’re just tribal monkeys throwing feces at each other in order to own the top of the tree. But notice some of the subtleties there: climbing it while helping others (naches and kvell). Climbing it while pushing the boundaries of our knowledge (fun). Climbing it while strengthening our social networks, building communities and families that work together to improve everyone’s lot (grooming, pairing, and feeding others).
As monkeys go, that’s pretty darn good. In the general run of animals, it’s amazing. It’s a lot better than being a shark that only gets feedback for eating."

Quick read, fun, interesting insights. A very good book!

I'm joining ThoughtWorks Brasil

2009-12-06T10:30:00.000-02:00

It's now official: I'll be joining a brand new startup called ThoughtWorks Brasil before the end the year.

- ThoughtWorks?

Yeap, ThoughtWorks. In the brand new Porto Alegre office - how cool is that?

- But what about Yahoo!?

I had a great time. I worked with the best people I've seen in my life and I believe we did a great, great job. I would certainly do it again. However, I simply couldn't get used to São Paulo and after an entire year.. I think I never will. Sorry.

It was a though decision.

Take a look at this video from my friend Fabio Giolito (who also couldn't handle São Paulo and went back to his Rio de Janeiro):

That was the spirit during these last 12 months. Really.

I'll miss ya.

Purple Cow

2009-10-14T23:28:00.000-03:00

"It's people who have projects that are never criticized who ultimately fail"

Getting real for marketing people.

(shortest review ever)

Python Brasil 2009

2009-09-02T04:35:00.000-03:00

I'll be speaking in the Python Brasil [5] - the fifth conference of the brazilian Python community. It will take place in Caxias do Sul, RS, 10th to 12th of September 2009.

I'll be speaking about "Python at Yahoo! Brasil" - mainly about our (almost famous) Python powered project, called Yahoo! Meme.

See you guys there! :-)

The Seasoned Schemer

2009-08-22T14:23:00.000-03:00

"- Does your hat still fit?"

"- Of course it does. After you have worked through the definition of the Y combinator, nothing will ever affect your hat size again, not even an attempt to understand the difference between Y and Y!"

Well, the quote pretty much nails it: The Seasoned Schemer, also by Daniel P. Friedman and Matthias Felleisen, is a very good complement for the first book, and as recommended as "The Little Schemer".

Except that... I don't agree with their "nothing will ever affect your hat size again": I think there are lots of "head expanders" out there waiting to be read.

But I'm taking a break before the third one: it's healthy to keep the same hat size sometimes :-)

Thrift: a software framework for scalable cross-language services development

2009-06-21T16:23:00.000-03:00

I'll be speaking in the upcoming International Free Software Forum (fisl.org.br) about Thrift - a "software framework for scalable cross-language services development".

My deck is (already) available at http://github.com/bzanchet/presentation-thrift-fisl10/ - yeap; git over slideshare :-)

See you there!

The Little Schemer

2009-05-21T17:40:00.000-03:00

Do you know what "recursion" means? No, I mean, have you looked recursion in the face? Do you KNOW how the magic happens? It's not that simple.

"- Does your hat still fit?
- Perhaps not after such a mind stretcher."

Have you heard of "The Little Schemer", by Daniel P. Friedman and Matthias Felleisen? I wish I had... Some 5 years ago. Well, I already have the other two here, just waiting for this one to be properly digested.

As part of the digestive process, I just implemented the y combinator function in python - the language I'm currently fluent at thanks to that 5-times-a-week-8-hours-a-day thing.

It's not exaggerated: "it's one of the most strange and wonderful artifacts of Computer Science" (aside from these words, there's also a javascript version here thanks to Douglas Crockford).

Go grab your copy. Now.

Pragmatic Thinking & Learning / Predictably Irrational

2009-05-13T14:00:00.000-03:00

Next, two "light psychology" books. First one: Predictably/Irrational, by Dan Ariely.

"[...] everything changed irreversibly in a matter of a few seconds. An explosion of a large magnesium flare, the kind used to illuminate battlefields at night, left 70 percent of my body covered with third-degree burns.

The next three years found me wrapped in bandages in a hospital and then emerging into public only occasionally, dressed in a tight synthetic suit and mask that made me look like a crooked version of Spider-Man. Without the ability to participate in the same daily activities as my friends and family, I felt partially separated form society and as a consequence started to observe the very activities that were once my daily routine as if I were an outsider."

Very entertaining, it has some cool insights about human cognition, psychology and behavior. Lots of stories and scientific studies, resembles Malcom Gladwell's style. Not bad.

Then Pragmatic Thinking and Learning, by Andy Hunt, one of the original "Pragmatic Programmers".

"You can set up more rules to explain, and then more rules to explain those, but there’s a practical limit to how much you can effectively specify without running into a Clinton-esque “It depends upon what the meaning of the word is is.” This phenomenon is known as inﬁnite regression. At some point, you have to stop defining explicitly.

Rules can get you started, but they won’t carry you further."

As the first one, not bad. It contains some cool chapters, some nice ideas and insights about cognition, concentration, productivity. But not a world changer, either. Personally... A little too much self-help, and not much that wasn't said before.

So, from these two, I'd highly recommend Dan Ariely's Predictably/Irrational. It's a light, quick-to-read book, full of short and curious stories - kind of thing that also matters. But concerning psychology, cognition and neuroscience, I would stick to some more focused, deep books on the subject: for now, two of my favorites are The 21st-Century Brain and, of course, Godel, Escher, Bach. What are yours?

Javasript: the good parts

2009-04-24T13:00:00.000-03:00

"It is rarely possible for standards committees to remove imperfections from a language because doing so would cause the breakage of all of the bad programs thtat depend on those bad parts. They are usually powerless to do anything except heap more features on top of existing pile of imperfections. And the new features do not always interact harmoniously, thus producing more bad parts.
But you have the power to define you own subset. You can write better programs by relying exclusively on the good parts."

That's Douglas Crockford talking about the "most misunderstood programming language"; and his arguments are very strong: javascript is not only a small, toy language. It's a very powerful tool, with astonishing features. And given that with great power comes great resposability: JavaScript is hard.

Building modular, reusable, readable code with this language is not a trivial task - this is not actually a disadvantage, though; it's a challenge (who doesn't like them?). In this book, Douglas Crockford points out a lot of interesting ways to avoid most of the problems of the language in order to write robust, concise code.

So, closing the review: JavaScript has its issues, but most of its problems are not inherent to the language and can be safely avoided. It certainly doesn't deserve all the critics out there (although some implementations obviously do). Really recommended book; it sheds light on a lot of myths and shows the bright side of this powerful language.

"The central question of how to improve the software art centers..."

2009-04-12T20:01:00.000-03:00

I believe a small set of high talented individuals is enough to empower an entire company. I believe hiring as much virtusos as it's virtually possible to find should be number one priority in any company.

I believe it's incredibly dangerous (and stupid) for a company to be unaware of that. Brooks:

"Most organizations spend considerable effort in finding and cultivating the management prospects; I know of none that spends equal effort in finding and developing the great designers upon whom the technical excellence of the products will ultimately depend."

Yeap; directly from the 70's. Please, go on:

"The differences are not minor—it is rather like Salieri and Mozart. Study after study shows that the very best designers produce structures that are faster, smaller, simpler, cleaner, and produced with less effort. The differences between the great and the average approach an order of magnitude."

Sad but true. Freaking disappointing when you see one of them moving away and can't do much about (because our gigantic company is moving like a turtle, flushing its millions somewhere). I should've called the CEO.

Hey, Vitor, keep up with the good work at twitter.

On Python vs Ruby

2009-04-02T05:00:00.000-03:00

So, finally... After some 6 months pythoning.. Some random rants on advantages (and disadvantages) of Python over Ruby.

What I do like about python:

the "in" operator

"test" in "this is a longer test phrase"

2 in [1,2,3]

the "and" and "or" behavior - python got it right (are you listening, PHP?)

a = a or b

a = a and b

list comprehensions

[a for a in some_list if a >= 3.1415]

*args and **kwargs (definitely very useful)

def func(param, *args, **kwargs):

do_something_with(param)

go_ahead(*args, **kwargs)

What I miss in python (that Ruby has):

side effects

if a=get_a():

return a

the "||=" operator (but the "or" operator almost replaces it)

self.a ||= self.fetch_from_somewhere()

mixins (no, multiple inheritance is not the same thing)

class MyList:

include Enumerable

...

special characters in method names

def shit=(new_shit):

#updates the shit

def do_shit!():

#does some real shit

#..

passing blocks of code around

creating functions and lambdas is OK; but.. come on; the level of expressiveness ruby achieved is way more comfortable.

What I really dislike about python:

global functions

map([], my_callable)

filter([], my_callable)

double underscores

don't you prefer straightforward naming conventions (eg: method_missing, initialize) over __init__ or __repr__?

explicit "self"

come on, we're adults, we can grok what "self" means

public attributes

don't you agree that "private" is a better default?

Yeah... Definitely none of them are real issues. Remember: when you get into this exactly same flamewar, keep in mind that the most important is that (I hope) you're not using Java (or PHP) :-)

Gödel, Escher, Bach

2008-11-16T05:30:00.000-02:00

First it was Joel:

"I read this before starting college, and decided that I wanted to major in 'Godel Escher Bach.'"

Then Steve:

"All of his books are wonderfully imaginative and are loads of fun to read, but if you're a programmer and you haven't yet read Gödel, Escher, Bach: An Eternal Golden Braid (usually known as "GEB"), then I envy you: you're in for a real treat. Get yourself a copy and settle in for one of the most interesting, maddening, awe-inspiring and just plain fun books ever written. The Pulitzer Prize it won doesn't nearly do it justice. It's one of the greatest and most unique works of imagination of all time."

With those two legends praising this book that much... What's your excuse to skip it? (maybe because it's 700 pages thick) But... Come on. It is that good, indeed.

(sorry, I couldn't find a quote representing the overall idea of the book - there are a lot of interesting things; to show just one fragment would be unfair..)

On Scala and Java

2008-10-28T21:59:00.000-02:00

Gold. This text is gold :-)

Static Typing's Paper Tigers

And then we've got Scala. I've gotta mention Scala. Who here knows... you've heard of Scala? Yeah? (a few hands go up) Mmmmm, yeah, getting there... looks like some people, OK.

Scala is a very strongly typed language for the JVM. It's from researchers in Switzerland; they're professors. It's from sort of the same school of thought that static typing has evolved with over the last fifteen years in academia: Haskell, SML, Caml, these sorts of H-M functional languages.

And Scala's interesting because it actually takes a functional static type system and it layers... it merges it with Java's object-oriented type system, to produce.... Frankenstein's Monster.

I've got the language spec here in my backpack. Oh, my god... I mean, like, because it's getting a little bit of momentum, right? So I figure I've got to speak from a position of sort of knowledge, not ignorance, when I'm dissing it. (Heh heh.)

And so before, I was like: "Oh yeah, Scala! Strongly typed. Could be very cool, very expressive!"

The... the the the... the language spec... oh, my god. I've gotta blog about this. It's, like, ninety percent [about the type system]. It's the biggest type system you've ever seen in your life, by 5x. Not by an order of magnitude, but man! There are type types, and type type types; there's complexity...

They have this concept called complexity complexity meaning it's not just complexity; it's not just complexity-complexity: it's parameterized complexity-complexity. (mild laughter) OK? Whoo! I mean, this thing has types on its types on its types. It's gnarly.

I've got this Ph.D. languages intern whose a big Haskell fan, and [surprisingly] a big Scheme fan, and an ML fan. [But especially Haskell.] He knows functional programming, he knows type systems. I mean, he's an expert.

He looked at Scala yesterday, and he told me: "I'm finding this rather intimidating."

I'm like, "THAT sounds like it's gonna take off!" (loud laughter) Oh yeah!

But the funny thing about Scala, the really interesting thing — you guys are the first to hear my amazing insight on this, OK? — is: it's put the Java people in a dilemma. There's a reeeeeeeal problem.

The problem is, the Java people say, "Well, dynamic languages, you know, suck, because they don't have static types." Which is kind of circular, right? But what they mean, is they say: No good tools, no good performance. But even if you say, look, the tools and performance can get as good, they say, "Well, static types can help you write safer code!"

It's... you guys know about those talismans? The ones, where, "What's it for?" "To keep tigers away"? (some chuckling) Yeah? And you know, people are like, "How do you know it keeps tigers away?" And your reply is: (sneering) "Do you see any tigers around here!?" (minor laughter)

So this is what... OK, so for a long time, for many years... and you know, I've written more Java code than most Java programmers ever will. (Editor's note: nearly 1M lines in production. Ouch.) So trust me. I tried. OK? I'm not just coming in and saying "I don't want to learn Java." No. I know Java as well as the next person.

But I come to them and say, let's do proof by – say, argument by example! You know, an existence proof. IMDB is written in Perl, right? Yahoo! – many of their properties are written in PHP. A lot of Microsoft stuff's written in VB, right? ASP .NET? Amazon.com's portal site is Perl/Mason.

A lot of companies out there are building big, scalable systems – and I mean scalable in the sense of throughput and transactions, stuff like that, but also scalable in terms of human engineering — in these dynamic languages with no static types. [Using nothing more than good engineering principles.]

So... isn't that a demonstration that you don't need the static types to keep those tigers away?

And they're like: "Well! But! What if... what if a tiger came?" (laughter) Right? "People need shotguns in their house in case a bear comes through the door, right?" The Simpsons made fun of that. (laughing continues)

Yeah. So, you know, for a long time, I was like: "Yeah, yeah, yeah. OK. So tigers could come. Fine."

Scala, now, is the tiger that's going to kill Java. Because their [type-talisman] argument now has become a paradox, similar to the Paul Graham Blub Paradox thing, right? Because they're like, "Well, we need static typing in order to engineer good systems. It's simply not possible otherwise."

The Scala people come in and they go: "Your type system suuuuuucks. It's not sound. It's not safe. It's not complete. You're casting your way around it. It doesn't actually prevent this large class of bugs. How many times have you written catch (NullPointerException x) ... in Java? Our type system doesn't allow [things like] that."

Our type system does what you said your type system was doing.

So, therefore, you should be using it! ∴

And the Java people look at it and go: "Wehellll... (cough cough)... I mean, yeah, I mean... (*ahem*)" (running finger under collar, as if sweating profusely) They say, "Welllll... you know... it's awfully... cummmmmbersome... I..."

"We can actually get around the problems in practice that you guys say your type system is solving through Good Engineering Practices."

(laughter begins to grow)

HA!!! (I point accusingly at the audience, and there's more laughter)

Yeah.

From http://steve-yegge.blogspot.com/2008/06/rhinos-and-tigers.html, without any kind of authorization, of course.

Maverick

2008-09-28T16:27:00.000-03:00

"Aristotle, who didn't subscribe to The Wall Street Journal, once said 'Thinking requires leisure time'. If you are not in possession of leisure time, you can't be thinking all that much."

I'll stick with this specific quote mostly because this is a highly reviewed book around there. It's a pretty old book (1993 - fifteen years ago! Man, that was before the 2000's bubble - did we had intelligent life on earth that time?). But it's not outdated at all!

The ideas that Ricardo shows on the book are very convincing, although not that revolutionary nowadays (I can't say for sure if they were all brand new ideas at that time, either). Democracy in choosing bosses, self-set salaries, flexible working hours are some of the ideas Semler adopted in his company.

It's certainly a recommended book. At least, it will be a good starting point to start rethinking your workplace. It's better than his first one, Virando a própria mesa, but not as great as his (currently) latest one, Você está louco (sorry, english readers - that one is really that great, but I guess it's available in portuguese only).

And I think that's enough Semler for me - should not be reading him again any time soon :-)

RESTful Web Services

2008-09-15T16:21:00.000-03:00

"We wrote this book to tell you about an amazing new technology. It's here, it's hot and it promises to radically change the way we write distributed systems. We're talking about the World Wide Web."

Gee. Can a book released on May, 2007 be outdated already? OK, it's not the case. It's not totally the case.

Warned that the book was almost useless (thanks, gc), I was a little bit hesitant to start it. Four hundred pages, after all! Well. He was right. The first six or seven chapters are... Hm... ~~Useless~~ Of very questionable utility. Come on, it's possible to write an introduction to REST ideas without describing amazon's S3 or google maps. Two hundred pages that worth.. Hm.. Twenty. Thirty, at most! Gee.

Chapters 8, 9 and 10 are worth the trees they killed, I would say. REST and ROA "best practices", HTTP and encoding, WS-* versus REST. I can read that.

Then back to questionable chapters. Rails 1.2, Restlet, Django? There are some very small examples and code snippets. OK, maybe it give us a taste of how REST looks like in the real world. Then almost fifty pages describing HTTP status codes and headers. Do we need that in a book?

Well. It's a good book, after all. But I can't deny the impression that it was very poorly reviewed and almost designed to be that long. O'Reilly, could you fit the next edition in 100, 120 pages, please? Thanks.

Cocoa Programming For Mac OS X

2008-09-08T14:14:00.000-03:00

"This book [...] acts as a foundation. It covers the Objective-C language and the major design patterns of Cocoa. It will also get you started with the three most commonly used developer tools: XCode, Interface Builder and Instruments."

Breaking my reading pattern, this is a more technology-specific book. It's full of small, directed examples showing a lot of features of the apple SDK. From CoreData to Garbage Collector to OpenGL, it's a very good starting point for developers unfamiliar with the programming tools from apple (like me).

The parallels with C/C++ and Java are very helpful when dealing with the ~~weirdness~~ particular syntax of Objective-C, also.

Just one complaint: in this third edition, released in 2008, not one chapter about automated testing? Not a word? I'm not asking to test-drive all the examples (it is not a bad idea, though), but some tips on unit tests and automated GUI tests would be very handy. Some people like to test-drive even the more basic examples :-)

The ThoughtWorks Anthology

2008-09-01T18:20:00.000-03:00

"ThoughtWorks is a collection of passionate, driven, intelligent individuals that delivers custom applications and no-nonsense consulting. Ask a ThoughtWorker what they like most about the company, and they will likely say it is the other ThoughtWorkers they get to meet, work with, and learn from."
[...]
"This anthology provides a great snapshot into the incredibly diverse set of problems on which ThoughtWorkers are working".

So, what to expect?

From DSLs to testing to ant build files, the subjects discussed in this book are addressed with the right degree of detail: all the details are there. Yet the chapters are very concise (basically 10 pages for those that don´t have any code, then 20 or 30 pages) and all of them are very, very clever.

As a developer using object-oriented languages since... ever, I have to make a special mention to chapter 6, "Object calisthenics" - which present us 9 "rules of thumb" of object-oriented programming. Gosh, I wish all developers (juniors, specially) read it... Yesterday!

Worth to mention the chapter 10 ("Domain annotations") too. In this one, the author describes a case study (of a real TW project, of course) in which they mixed domain-driven design with the use of annotations, discussing the trade offs they made.

I confess I missed a chapter addressing something like architecture or layers - something like this, actually (hey, Philip, you're a ThoughtWorker - get your material into the next edition, please :D). Summarizing, this book is quick and easy, though very insightful and clever. Very recommended!

Agile Software Development with Scrum

2008-08-25T14:05:00.000-03:00

I think this was probably the last book from any "agile bibliography" that I haven't read yet. This could be the reason why I ended the book with the feeling of "already saw this somewhere". But even considering that the "agile argument" is somewhat well known and widely accepted nowadays (more in theory than in practice, for sure), Agile Software Development with Scrum still worth reading.

In the book, after describing all the roles, vocabulary and practices of Scrum in the first four chapters of the book, the chapters 5 and 6 are the most interesting part. There, the authors describe the theoretical foundations for empirical methodologies like Scrum and XP, based on complexity theory and process control theory, among others. Very enlightening. Chapters 7 and 8 are less about scrum and more about organizations, and 9 ("Scrum Values"), is self-explanatory.

One bold difference to Kent Beck´s book is that Ken and Mike list the values of scrum only in the last pages of the book. Kent, apart from doing it right in the beginning of his book, did a thoughtful separation in values, principles and practices. Point for Kent.

Summarizing my opinion: this book certainly has its place on my "top 10" books for developers (to be released :). Read it.

Slack

2008-08-18T22:30:00.000-03:00

[...] when people learn something that really matters to them, they go through a moment of panic. As soon as it's apparent that this new approach is superior to what they have been doing for years, there is an unspoken "Oh, shit" that ripples through the room. Their faces turn white. You can practically hear the flip-flops in their stomachs.

Important to mention, Tom DeMarco wrote this book after the already-a-classic peopleware.

But this is a book about change. Better saying, about why some companies change, and others don't. Slack isn't exactly about work and workspace - it's more focused on the human aspects of the organization; it's not hard to remember some of the lessons they taught us in the previous book, though.

I wouldn't say that it's a must-read-as-soon-as-possible kind of book, but some very interesting stories and lessons definitely worth the time spent on it.

(back reading, after some days off and a few non-technical books. Next should be this one, then this)

Lean Software Development

2008-06-17T22:21:00.000-03:00

Many consulting firms use applied ratio as a key management measurement, one that they feel should be maximized, since utilization directly affects profits. Similar measures have found their way into internal software organizations, where their tie to profitability is more tenuous. It is difficult for those who think this way to understand that full utilization provides no value to the overall value stream; in fact, it usually does more harm than good. We would never run the servers in our computer rooms at full utilization - why haven't we learned that lesson in software development?

This book was an eye-opener in a sense. Most agilists I know are always ready to talk by hours and hours about how software development does not relate (or shouldn't relate) to industry practices. The industry practices they know, or they think they know, at least. Naming it: scientific management, or Taylorism. In fact, traditional software development is much like taylorism - high work division, standard method for executing each job, vertical hierarchy, a small team planning each job and task - not forgetting to mention the fact that those techniques were already outdated three decades ago.

But agile software development does relate to some industry practices, after all (and that's not a bad thing, necessarily!). Decide as late as possible; deliver as fast as possible; empower the team; amplify learning - those principles were here before the manifesto - it's called Lean manufacturing and it's the main reason of the success of the top auto maker in the world. This book does a great job explaining how (and why) to think lean, relating lean manufacturing practices to (agile) software development. Recommended book, for sure.

The psychology of computer programming

2008-05-20T21:10:00.000-03:00

I don't know why I bought this book, really. Not from a list, not a "classic". If it was someone's indication, I can't remember. Its ambition is not small: to "trigger the beginning of a new field of study". Not bad.

There are dated examples, of course (time sharing vs batch? COBOL vs PL/I?). But I can't deny that they could be considered helpful, giving things a little perspective.

My opinion is that the book raises (raised, 25 years ago, actually) many timeless concepts about programming as a human activity - I don't know if it was successful in its mission of triggering a whole new field of study, but it's certainly worth reading. I reproduce here two of the many insights this book has. First, about Parkinson's law:

"When Parkinson said that 'work expands to fill the time allotted', he was making us aware that the very existence of schedule goals can influence the rate of work. But now we see that the very existence of schedule as a goal can influence "the time allotted". The reason work can expand to fill the time allotted is the existence of other goals whose importance relative to scheduling is not made clear. Perhaps we might follow this line of reasoning and begin to understand what fallacies underlie the generally accepted conclusion that programming projects can never be done on time."

Second, about the lack of experimental evidence on software engineering (or, how they called it, systems programming):

"The time has come to sweep the myths out of our closet and replace them, if possible, with hard experimental evidence. Not that any of these problems will ever be 'solved' - the complexity is to great for that. But what worthwhile problems are ever solved? It's not so much the solutions we need, anyway; but the experience in trying to get them."

Isn't software development just like architecture?

2008-05-09T00:45:00.000-03:00

This kind of architecture, I mean. Not that.

(and, I think, the spread use of expressions like "MVC architecture" or "software architect" is exactly what collaborates to avoid this comparison).

I think any person familiar with agile philosophy (and contrary to most software managers) agrees that software definitely isn't like civil construction or any other form of traditional engineering. Then there is Knuth's famous comparison to art. But isn't there a better comparison? Well, those four guys stoled that idea from an architect, after all. Why didn't we bring this metaphor further?

To me, software development (aka "software engineering") is just architecture without the autocad part (call it "java" or ".net" or "rails").

Look at the facts: were you the owner of an architecture office, wouldn't those characteristics be familiar? You have clients without a clear idea of what they want. You have to design and deliver a completely abstract product. You can reuse some elements, but each project is essentially unique, with its own problems and weird details.

So, how would you do it? You need small and quick cycles of feedback from the client (otherwise the result would be worthless). You need silence, concentration and focus in order to work. You go through days and days solving a lot of small problems - and new problems arise and old problems change in unpredictable ways. Sometimes you need to use a team, but a small team is the only way it works (you can always break the project into smaller projects and use a set of small teams, of course). You need a lot of communication.

In the end, you will deliver a completely abstract product (I mean... maybe the client saw it in autocad, but the deliverable itself - the project - it's abstract).

So, forget about the construction metaphor. What software developers do is something that is out there for hundreds of years. And, curiously, it's definition starts exactly like Knuth stated: "Architecture is the art and science of..".

(More to come)

Planning extreme programming

2008-04-24T17:10:00.001-03:00

"It isn't completely against the rules to slip a date, it's just that the XP methodology requires you to chop one of your own fingers off each time you do it."

Who am I to criticize a book by Fowler and Beck? I don't know, I don't know.

I really like Beck's informal style, sometimes referring directly to the reader, as if they were talking personally. And it's not the same thing when they write "Kent once was in a project wabba wabba wabba", and that's the case of this book.

And the content don't seemed very revolutionary, as one would expect from this pair. I mean... "Yesterday's weather" is certainly a good idea, but isn't worth 130 pages by it's own. I'm saying this maybe because the book was wrote back in 2001 (loooooooong time ago, by internet standards), and wasn't updated at all.

Well... I'm certainly a little bit disappointed to write this, but there are better books out there than this one.

Getting Real

2008-04-14T11:34:00.000-03:00

"Simple rules, as with the birds simulation, lead to complex behavior. Complex rules, as with the tax law in most countries, lead to stupid behavior."

Andrew Hunt

Discussing business, marketing and web application in "web 2.0", this book is an incredible valuable source of ideas and insights. It would be a great book if it were an idealistic book wrote by a consultant, a journalist or any tech guru.

Being wrote by a real company, doing real business and earning real money, it is even better. If you want to be an entrepreneur, or if you simply work with web applications, you should read it.

By the way: can't wait for the second edition.

Extreme Programming Explained

2008-03-09T17:50:00.000-03:00

"If you have six weeks to get a project done, the only thing you can control is your own behavior. Will you get six weeks' worth of work done or less? You can't control other's expectation. You can tell them what you know about the project so their expectations have a chance of matching reality. My terror of deadlines vanished when I learned this lesson. It's not by job to "manage" someone else's expectations. It's their job to manage their own expectations. It's my job to do my best and to communicate clearly."

One could argue that this book is a little bit utopian - I would agree. But no one can deny that this Kent Beck masterpiece is full of very valuable insights.

After all, this is a book that literally tipped a revolution, that changed the world. Get one for you, one for your boss, one for each of your colleagues - it's a must read.

Implementation Patterns

2008-02-20T21:54:00.000-03:00

"Maintenance is expensive because understanding existing code is time-consuming and error-prone. Making changes is generally easy when yo know what needs changing. Learning what the current code does is the expensive part."

This little insight is reason enough to write a book. And a great book, by the way. Implementation patterns are a solution addressed to the most expensive task we face: understanding other's code. This is a very subjective matter, and that's nothing but one more reason to read the ideas and examples of a master like Kent Beck. Definitely recommended.

The Pragmatic Programmer

2008-02-09T01:55:00.000-02:00

"People should see your name on a piece of code and expect it to be solid, well written, tested and documented. A really professional job. Written by a real professional. A pragmatic programmer."

Reading this book now make me feel sad for reading some other books of the pragmatic bookshelf before this one. That's wrong. I would put this book just after "The mythical man-month" on my "book list for developers" (to be written).

Worth saying, not many books in the world were dense and inspiring enough to originate an entire new book series, like "The pragmatic programmer". Simply can't recommend it enough.

Let me put it on 2 words: Read It. Or, better, 3 words: Read It, Now.

Managing Humans

2008-01-19T21:40:00.000-02:00

"The current generation never knew a home without a computer. They assume they have ready access to just about any piece of information… and they’re probably working on their own Linux distribution right now. As a means of shaping your brain for critical thinking, I’m going to give college two thumbs up. As a requirement for doing great work in the software development industry, I’m going to give a college degree a long “Hmmmmmmm” while I slowly stroke my goatee."

Great book, great insights. Definitely recommended.

But, come on, Rands. I would give you two thumbs down, here. Who in the world still believing that a bunch of code monkeys is a great team? Critical thinking was supposed to be a primary requirement on any new hires.

Critical thinking is a characteristic of great people. A great team is composed by great people. I want critical thinkers on my team, and that's it. I would recommend everybody to go college. Simple as that.

Just can't do that

2007-12-09T01:47:00.000-02:00

If you're being pressured to compromise code quality, it might help to point out that you, as a developer, don't have the authority to degrade corporate assets (the overall code base).

(from Practices of an Agile Developer)

Buy Some Nice Chairs

2007-11-24T19:43:00.001-02:00

"Get a really nice chair, skimping on the rest of the furniture if necessary. You cant program well if your back hurts. Yet, organizations that will spend $100.000 a month on a team won't spend $10.000 on decent chairs."

(from Kent Beck's Test Driven Development: By Example)

I would say, aditionally: buy an exceptional keyboard - a regular mouse is enough. But more important: buy the best monitor you can afford. Two of that, if possible.

Blink

2007-11-13T23:00:00.000-02:00

"What if we stopped scanning the horizon with our binoculars and began instead examining our own decision making and behavior through the most powerful of microscopes? I think that would change the way wars are fought, the kinds of products we see on the shelves, the kinds of movies that get made, the way police officers are trained, the way couples are counseled, the way job interviews are conducted, and on and on. And if we were to combine all of those little changes, we would end up with a different and better world."

That's not a book about software engineering or even about computers. Thats not a book that tell us how to work. He even didn't speak of "the way software is made" in the examples. But the world we see is nothing else than a reflection of ourselves. So I saw software engineering and work lessons. Hahá.

I bet Malcom Gladwell never heard of user stories, time-boxed iterations or baby steps. I bet he never heard of waterfall. But I think "the way software is made" fits perfectly in that list, maybe with one exception: it is changing (Hey, I'm not saying that all the others are frozen in time...).

I think Kent Beck can't be more right when he says that Agile development really isn't anything else than the way the world expects software development to happen. We simply can't scan the future with our binoculars, so it's better to focus on small decisions and little steps. That's one of these small changes that makes the world a better place.

Computer Scientist

2007-10-24T23:23:00.000-02:00

And I don't need to waste my time with a computer just because I am a computer scientist.
[Medical researchers are not required to suffer from the diseases they investigate.]

- prof. dr. Edsger W. Dijkstra

Yeah, that's one of the most wrong perceptions about our academic formation. It's not easy to convince people that the hours spent sited in front the computer are the easy ones.

Hard is to talk with the customers, the users, the clients… to make they talk about what they expect from the software, or about their real environment and their real problems, the ones we must model in the computer in order to automate, to solve.

Hard is to design a system that is flexible, simple and extensible. And that is, at the same time, closed for changes.

Dijkstra, of course, is right. The hardest part of our jobs, being a mathematical theorist, a bored guy trying to prove that P=NP or even a real world software developer, can be done without these machines. A pen and paper are vastly sufficient. But the true is… Come on, we just love our iPods, and pens can’t feed them with music. Yet.

A little break: non nerd quote.

2007-10-04T23:18:00.000-03:00

Ernesto "Che" Guevara, in his book Motorcycle Diaries: A Journey Around South America:

Maybe someday a miner will grab his pickaxe and go poison his lungs with a smile in the face. They say that this is the way it works there, were comes the red flame that fascinates the world. That's what they say. I don't know.

Yeah. You really didn't knew. You were simple wrong. Nobody, nowhere would go kill himself just because of proletarian power, communism, whatever.
Anyway, why the hell so many people still wearing your face? They enjoy being wrong like that?

Prediction etc

2007-09-24T00:37:00.000-03:00

Prediction is very difficult, especially about the future. (Niels Bohr)

apud Craig Larman's "Agile & Iterative Development: a manager's guide"

Peopleware, revisited

2007-09-15T22:12:00.000-03:00

Just another quote, to answer this post, by Rodrigo Urubatan.

"Teams are catalyzed by a common sense that the work is important and that doing it well is worthwhile. The word well in this last sentence is essential: The team assigns itself the task of setting and upholding a standard of prideful workmanship. All team members understand that the quality of the work is important to the organization, but the team adopts a still higher standard to distinct itself. Without distinguishing factor, the group is just a group, never a real team.
Into this complicated mix, now imagine dropping a $150 framed poster do advise people that "Quality Is Job One". Oh, Gee, we never would have thought that. No sir, we sort of assumed - until this wonderful poster came along - that quality was job thenty-nine, or maybe eleventh-seven, or maybe even lower than that on the corporate value scale, maybe someplace after reducing ear wax or sorting the trash. But now we know. Thanks."

I Really Agree With DeMarco And Lister.

Peopleware

2007-08-30T00:31:00.000-03:00

Excellent quote from the excellent book "Peopleware", by Tom DeMarco and Tim Lister.

Historians long ago formed an abstracion about different theories of value: The Spanish Theory, for one, held that only a fixed abount of value existed on earth, and therefore the path to the accumulation of wealth was to learn to extract it more efficiently from the soil or from people's backs. Then there was the English Theory that held that value could be created through ingenuity and technology. So the English had an Industrial Revolution, while the Spanish spun their wheels trying to exploit the land and the Indians in the New World. They moved huge quantities of gold across the ocean, and all they got for their effort was enormous inflation (too much gold chasing too few usable goods).

It's something to be kept in mind.

Mythical Man-Month

2007-08-07T20:34:00.000-03:00

The first post can't be different: those words, which encourages and motivates even us agilists of the 21st century.

Nevertheless, I do not believe that we can make the next step upward in the same manner. Whereas the difference in poor conceptual designs and good ones may lie in the soundness of the design method, the difference between good designs and great designs surely does not. Great designs come from great designers. Software construction is a creative process. Sound methodology can empower and liberate the creative mind; it cannot inflame or inspire the drudge.

Frederick P. Brooks, Jr.'s classic "The Mythical Man-Month: Essays on Software Engineering"