97 Things Every Software Architect Should Know

Discussions

News: 97 Things Every Software Architect Should Know

  1. 97 Things Every Software Architect Should Know (35 messages)

    It's rumoured to be difficult to get a software architect to put something down on paper but imagine the getting 50 or so of them to write something creative. Last week after many months of effort and at least 2 wikis later O'Reilly published "97 Things Every Software Architect Should Know". The book is the collective contribution of technical architects from all over the world working across the full range of domains. For more details please check out the wiki: http://97-things.near-time.net/wiki The book is now available on Amazon: http://www.amazon.com/Things-Every-Software-Architect-Should/dp/059652269X/ -John- [Editor: Thanks, John. It would be great if someone would do a book review on this.]

    Threaded Messages (35)

  2. Highly pleased with the result[ Go to top ]

    As a contributing author, I'm proud to be part of this project. I've been perusing over my co-authors' entries this week, and have used more than one in communicating challenges and prinicpals of software architecture to clients and peers. This book does a good job of capturing the types of insight that rarely lend themselves to conference presentations, white papers, and traditional software books; the content is more along the lines of memorable, "off-the-record" hallway conversations at conferences. Thanks again to Richard Monson-Haefel and Mike Loukides for heading up the effort and for taking a courageous and innovative risk on a new kind of software book that I believe practitioners of the craft will appreciate.
  3. I'm pleased[ Go to top ]

    Many architects are really they have no clue what architects suppose to do. I have heard these days many company’s trying to remove architects role because there are bunch of people they really don’t know what’s their company’s business and how to pick the right framing work/ technologies. I hope this book might help those idiots (architects).
  4. Re: I'm pleased[ Go to top ]

    Many architects are really they have no clue what architects suppose to do. I have heard these days many company’s trying to remove architects role because there are bunch of people they really don’t know what’s their company’s business and how to pick the right framing work/ technologies. I hope this book might help those idiots (architects).
    A little harsh but lets say you are right, for argument's sake. Do you really think that the advice: "use dumb designs" will help these people? Actually, I'm unfairly targeting this book. "Stupid is the new smart" has long been an unquestioned assertion in IT. The argument goes that smart people do things that dumb people don't understand. Dumb people are cheap so you want to make sure you don't do things that would require smart people. The easiest way to ensure this is to get dumb people to design your systems. Based on this logic, it makes perfect sense to get architects that don't really know what they are doing. This guarantees that your 'architecture' will be dumb and reduce your costs. If extrapolate, this explains why so few students are getting technical degrees in the US. It precludes you from designing software. Highly educated smart people can only be allowed to do the most rote of programming tasks. This way that can't infect a system with their 'smarts' which would obviously make it too expensive to maintain.
  5. Re: I'm pleased[ Go to top ]

    Many architects are really they have no clue what architects suppose to do. I have heard these days many company’s trying to remove architects role because there are bunch of people they really don’t know what’s their company’s business and how to pick the right framing work/ technologies. I hope this book might help those idiots (architects).
    This sounds like a problem with upper-management confusing an architect with a systems analyst. Or maybe architects thinking that they're systems analysts, but not really understanding the business.
  6. So I'm looking through this and there's a lot of good stuff but so much of it is purely subjective. Not to say that it doesn't have value but depending on who reads it, they will get completely different meanings from it. A good example of this is 'Don't be Clever' http://97-things.near-time.net/wiki/dont-be-clever It contains this gem:
    More developers can implement and maintain dumb solutions.
    While I agree with not getting too fancy, I have a hard time with this argument. My experience is often that you will need more developers to maintain dumb solutions. Where I work an ETL tool (that I detest) is used extensively. This tool makes clever solutions basically impossible. This has resulted in an explosion in development staff. It also has resulted in system that is basically trapped in time. When we identify better solutions, we can't do implement them. Doing so would require 1000's of hours of excruciatingly explicit work. We are trapped by the dumbness of the design. I'm sure that the author or someone else would say that I'm taking it too literally but the reality is that this is exact argument that was used to justify this approach. I think the real problem here is that often 'clever' means 'something I don't normally do'. For example, some people that I work with think that standard Java-style OO is terribly clever and only pure procedural logic is dumb enough. I on the other hand look at some COBOL approaches as too clever and unmaintainable. I think the real danger here is that someone might interpret this to mean that the architect should dumb things down for the developers. Often this results in developers becoming clever to work around the inadequacy of the dumbed down architecture and that's much much worse.
  7. Agreed...[ Go to top ]

    I agree with you, James. There are far too many of these to really be anything groundbreaking. Especially if misconstrued as rules to live by, etc. That being said, I agree with most of the points. I think the way I approached the reading was, how can I apply these principles to myself, and not others. To give a somewhat obscure analogy, I treated these more like koans than rules. Peace.
  8. So I'm looking through this and there's a lot of good stuff but so much of it is purely subjective.
    Of course it's subjective, we were simply giving some guidance to would-be or existing architects, anyone that's done this job will understand that. It's also nice as an architect to have written backup for some of our ideas and approaches. If you want a formal, non-subjective approach then there are plenty of other options but there again you have to water those down and you get back to being subjective again. I should make it clear that all we got out of this was a free book so we're not funding a new house out of this. :-) -John-
  9. So I'm looking through this and there's a lot of good stuff but so much of it is purely subjective.


    Of course it's subjective, we were simply giving some guidance to would-be or existing architects, anyone that's done this job will understand that. It's also nice as an architect to have written backup for some of our ideas and approaches.
    I guess that's my concern. When things are described in such vague terms as the example I gave above is, anyone can basically take it as confirmation of what they already believe. It's kind of like the Bible. There's always an interpretation that backs up your argument. I guess I'm just not a big fan of distilling complex design options with lots of trade-offs no matter what you choose into cliches. I'm not looking forward to my inevitable argument about whether a given approach is 'clever' or not. As described "Don't be clever" really doesn't mean anything.
  10. So I'm looking through this and there's a lot of good stuff but so much of it is purely subjective.


    Of course it's subjective, we were simply giving some guidance to would-be or existing architects, anyone that's done this job will understand that. It's also nice as an architect to have written backup for some of our ideas and approaches.


    I guess that's my concern. When things are described in such vague terms as the example I gave above is, anyone can basically take it as confirmation of what they already believe. It's kind of like the Bible. There's always an interpretation that backs up your argument.

    I guess I'm just not a big fan of distilling complex design options with lots of trade-offs no matter what you choose into cliches. I'm not looking forward to my inevitable argument about whether a given approach is 'clever' or not. As described "Don't be clever" really doesn't mean anything.
    Perhaps concrete examples of past cleverness that worked out or attempts at cleverness that fell flat? At least then, one would be in a position to go "I don't think that's too clever." Then you could argue to the example(indicting the author in the process) instead of the potential vagueness. In fact, examples of the items would enhance the reading, war stories so to speak.
  11. The original guideline was 300 words[ Go to top ]

    It may help for folks to know that part of the original guidelines we were given included keeping ourselves to only 300 words. So, if some of these things seem a bit brief, well, that was the intent. Conveying a significant point about software architecture in 300 words is a challenge, particularly if those 300 words need to come from a software architect. ;-)
  12. It may help for folks to know that part of the original guidelines we were given included keeping ourselves to only 300 words. So, if some of these things seem a bit brief, well, that was the intent. Conveying a significant point about software architecture in 300 words is a challenge, particularly if those 300 words need to come from a software architect. ;-)
    I so like the ones I've read so far. #7 Stand up is right on the money. Don't give away too many secrets! ;-)



  13. I so like the ones I've read so far. #7 Stand up is right on the money. Don't give away too many secrets! ;-)
    Do'h! I *like* the ones. The "so" was going a different thought that changed mid-typing. Forget the CAPTCHA. Give use EDITING!!!!
  14. Re: The original guideline was 300 words[ Go to top ]

    Forget the CAPTCHA. Give use EDITING!!!!
    lol
  15. Re: The original guideline was 300 words[ Go to top ]

    It may help for folks to know that part of the original guidelines we were given included keeping ourselves to only 300 words. So, if some of these things seem a bit brief, well, that was the intent. Conveying a significant point about software architecture in 300 words is a challenge, particularly if those 300 words need to come from a software architect. ;-)
    If there was only some medium where additional information could be provided ... ;) :)
  16. Yes...yessss[ Go to top ]

    I think you're onto something...if only...if only... :-)
  17. I wrote the Don't Be Clever entry, so maybe I can address some of these questions on that topic. First of all, a lot of good points are made here. As Oscar Wilde wrote, "the only thing worse than being talked about is not being talked about". Which might mean that a book of this kind wouldn't be saying much if it didn't spark some debate. Bill makes a great point above when he brings up what we mean by "architecturally significant". That is a very context-dependent term, as are so many terms in our relatively nascent field. Cleverness, too, is context dependent. It's a fine line between pushing the envelope and working just beyond your ken. Business application developers writing a new ecommerce web site are probably doing it wrong, in my view, if they're using bitwise operators. Not certainly, but probably. You have to be very knowledgable to use them. Or even smart. But misapplication of smart things makes cleverness. Smart people are fantastic. Yay, smart people. But I think a smart solution crosses the line into a problematically clever solution when context is not understood, when you use your knowledge of an API or the intricate details of how a platform works, often to make it do something it wasn't intended to do. That's when it's the time to step back and reframe the problem, if possible. In the case cited above regarding frameworks, I don't think that use of any framework is usually 'clever' in this negative sense. Choosing to use a framework like Spring or GWT or anything else that is open, proven, well-documented, well-understood, addresses a defined problem space, and is reusable across projects is the opposite of clever. Find the solution where everyone can go, 'duh', because you've been smart in framing the problem, and reframing it if required, and making tough choices if required. Clever solutions sometimes come about when we think we must take the universe as given to us, confusing the transient current state with unchangeable, concrete, forever laws of physics. It's a category mistake. In writing the book, we were discouraged, if not forbidden, by the editors to refer to concrete technologies. They wanted a "timeless quality" to the axioms, so that the book could remain relevant to the most people for years to come. Which necessarily leads writers to a degree of generality. That, along with the space restrictions mentioned, accounts for the lack of "war stories", and I think it was a fine editorial choice. But because I may not have been clear in my definition, I can offer a couple of examples here of what I meant by problematic cleverness. One project I know of uses faces-config.xml to generate beans for CRUD operations. It appeared to save the time of writing these beans. It was a lot of work. You have to be smart to think of that solution and you have to be smart to implement it so it works all day every day, which it did. But it's not how faces-config was intended to be used. That solution is something we can potentially admire, until later when something needs to change, and then someone else is painted into a corner by these weird predicates and there's a ton of 'splaining to do. Smart people + predicating the solution on intricate and obscure details of something + making something perform an unintended purpose + ignoring context but somehow still making it work = clever = suspect. So that I'm not pointing fingers, I once used the Java SPI facility in a case where I really could have just used a system property, which is what most people would probably have done. I was attracted by the lure of the shiny new thing that I was knowledgeable about, and told myself some stories about how much more 'extensible' this was going to be and etc. Cleverness got the best of me. I wrote some interfaces, some classes, the SPI hook up thingy, and so on. If only I had been smart instead of clever. If I had been smart, I would have done the 'dumb' thing--the thing that is straightforward, simple, clear, a few lines of code instead of all that stuff, something that everyone understands, and that fit the intended purpose. But I didn't. So now every once in a while I get to spend a lot of time explaining to people what SPI is, how it works, what it's for, and why it's being used that weird way and struggling to illustrate the 'benefit' so I don't look like a moron. I'm not sure they're convinced. It was, as I believe we were fond of saying in the nineties, my bad. But no one thinks you're neat if you just use a system property. In a different context, we've all seen the clever solutions with 16 different pit stops at runtime. They usually seem to involve Excel somehow. Let's turn this data dump in csv into tab delimited with Python so we can move it onto the PC under this guy's desk running this VB deal that lets us put it into Excel so we can suck it into this other API thingy and that will let us use the 20 year old tail that's now wagging the dog that we think we're required to use because we think the universe is just a given and we have to duct tape stuff together instead of fighting for the elegant thing. Good job. You know 17 languages. You solved it. Very clever. With respect to the comment about not looking forward to conversations with developers about what's clever or not, I've had lots of good discussions with colleagues on that matter, and they usually help illuminate something we can simplify if we step back and breathe. People often are driven, even against their better judgment, to clever solutions when they face a lot of difficult legacy stuff and a serious time crunch. I understand. I live in this world with tons of COBOL doing the heavy lifting and tons of generated Java code from Visual Age from 10 years ago and lots of little also-ran frameworks scurrying around being annoying and I get it. And if the 16 pit stop solution is what the business really needs at that point because they can't afford more and it's not that important but they need it yesterday, then so be it, then that's the right solution. The actually right solution. Really. Don't just go around being elegant and extensible all over the place because you're an elegance bigot. But make the situation clear to your customer, and note that you're building up a little more technical debt, and that with debt comes interest that makes it harder to pay on the principal.
  18. Eben, there's a lot in your post but I basically assumed this is your argument. I actually agree 100% with what you mean. My concern is that people will not get your intended meaning. In fact I think a lot of people would interpret this to mean something quite different from your intention. I recently had an experience where the kind of issue I am talking about came to pass. I was in a meeting discussing a common element to a number of contracts. I had an issue with what our expert consultants had proposed because it had hardcoded details that everyone (except the consultants, apparently, or maybe they didn't care) knew were going to change in less than a few months time and would be expected to change regularly for the foreseeable future. My recommendation to change this element to be more dynamic was met with "we aren't trying to architect the most theoretically pure design". This isn't the exact verbiage "don't be clever" but it's basically the same sentiment. I don't really think this person thought that my recommendation was wrong, he was just being defensive because he knew what they did was crap. "Don't be clever" is similar to the YAGNI argument. I actually agree with the real YAGNI argument. The problem is that a lot of people don't take the time to understand what it really means. And because YAGNI is an 'accepted' principle, it carries weight even if it's not used properly. This presents people with the following conundrum: argue about what words mean and look like an ass or appear argue against a principle they actually agree with or just give up. I guess what I'm kind of saying is that it would be better to have some obtuse term that means nothing in plain English. You then either understand it, or you don't and have to educate yourself or remain ignorant. When it's something like "don't be clever" people hear it and it immediately has meaning to them. They may not question that what they think it means isn't really what you are saying. Given the size of these articles, I'm not sure there's an easy way to remedy this. And I really do agree with you on the overall idea. I just wish there were a way to make people really understand the ideas they bandy about.
  19. James, I agree with you agreeing with me. Just kidding. I think your point actually speaks to a larger problem in IT. Some term of art ("service", "REST", "dynamically typed", "encapsulated") is bandied about, as you put it, and everyone in the room starts nodding knowingly, happy to be safe in the comfort of the good old boys club where we all understand each other. The term almost always does actually refer to something real and discernible. But it gets watered down through merely pointing to it repeatedly and then it gets misused by marketers, and that makes it tough. Secretly, some of those people at the table aren't sure what the term means, and this makes them scared, and which makes them mad, and they start wondering if the emperor has any clothes. It's a problem. But it's not a problem of the book, I think. It's a problem of language and expression and precision. Which was the motivation behind axiom 95, The Importance of Consomme. Here's an example. Woody Allen makes "Deconstructing Harry", and suddenly everyone with a movie stub "knows" that "deconstruction" means "making a perfunctory examination of", and the culture is off to the races. "Deconstruction" is a term of art, like "service", it means something real, and it takes several hundred pages of one of the smartest people in the world to express. And when smart people read it, they still struggle with it, because they don't know as much as Derrida, and it's translated from French. But now 10 years after Woody puts the film in the can, everyone "knows" what deconstruction is, and (if they ever even heard of him, or of the movie, for that matter) they know that Derrida is stupid for being so high-falootin, because why didn't he just say that deconstruction means "a little taking apart, like analysis-light", in which case he wouldn't have had to make up a new word to explain the concept. Your point is crucial in IT, and especially for architects who need to perform some translation with the business and IT; but we see this all the time, in any discipline. And yes, your consultants are going to be defensive when they've made a shaky recommendation and you're really smart and you're paying them $300 an hour. But I'm not sure I see the connection to the axiom there. The idea of isolating what changes, as in your real-life example, is something I think we often shoot for. I'm sorry that was their (weird) response. We see this all the time with a term like "REST", which people usually intend as POX/HTTP, which isn't the point at all. The point has something more to do with Hypermedia as the Engine of Application State. But even if people read Fielding's dissertation, there still are open questions, debates, misinterpretations, to the point where Fielding is forced to rage on his blog "is there some broken manual somewhere that needs to be fixed?". Perhaps "clever" was not the best word choice on my part. But it _does_ have a certain connotation. Like "cunning" does--cunning seems to mean "smart, but in the way that a Disney villian is". Because language is such a problem in software architecture, for me, at least, right now, it's very important focus on language. And also to be able to say "I don't know". When people are measured by being smart, it's very painful to say "I don't know", and they go into Protean convulsions trying to avoid saying it. But I try to encourage this in my team members. It's very helpful for the situation you describe, and others. "I don't know that term. What does it mean?". "I haven't heard that term used in just that way--can you help me understand what you mean?". If the emperor really does have no clothes, it's revealed.
  20. James, I agree with you agreeing with me.
    I can agree with that.
    Perhaps "clever" was not the best word choice on my part. But it _does_ have a certain connotation. Like "cunning" does--cunning seems to mean "smart, but in the way that a Disney villian is".
    I was thinking 'tricky' and 'straightforward' as replacements for 'clever' and 'dumb' but it doesn't have the right ring, maybe.
    Because language is such a problem in software architecture, for me, at least, right now, it's very important focus on language. And also to be able to say "I don't know". When people are measured by being smart, it's very painful to say "I don't know", and they go into Protean convulsions trying to avoid saying it. But I try to encourage this in my team members. It's very helpful for the situation you describe, and others. "I don't know that term. What does it mean?". "I haven't heard that term used in just that way--can you help me understand what you mean?". If the emperor really does have no clothes, it's revealed.
    I was thinking this just a little while ago. I bet I could go into a meeting and give a presentation about how some aspect of computer systems works that was totally nonsense and no one in the room would say anything as long as I sounded confident enough. As far as the book goes, is there an opportunity to expand the online area to include discussion? I didn't see anything when I was poking around.
  21. While I agree with not getting too fancy, I have a hard time with this argument. My experience is often that you will need more developers to maintain dumb solutions. Where I work an ETL tool (that I detest) is used extensively. This tool makes clever solutions basically impossible. This has resulted in an explosion in development staff. It also has resulted in system that is basically trapped in time. When we identify better solutions, we can't do implement them. Doing so would require 1000's of hours of excruciatingly explicit work. We are trapped by the dumbness of the design.
    I have felt the pain of this too. They end up with a Rube Goldburg machine and think it is wonderful.
  22. If you are in a work situation where people are pitting Java and COBOL solutions against one another as means of defining what's "too clever" and using the quoted excerpt as backing, might I put forth that there's so much dysfunction there that one should consider moving on to somewhere else? The idea with this book (as I understood it) was to share distillations of insight gleaned through years of experience, not to provide a proof text that would serve as a tool for software architects to combat one another. Anyone viewing this work as a means for such a thing is laboring under a severe misapprehension.
  23. I'm sympathetic to what James is saying though. Part of what I wanted out of the book (I wrote #97) and why I'm glad the contributions are freely available was not for everyone to agree with them as doctrine, but to stimulate debate and thinking on principled software design. And I think we need to understand that there are still some areas which need to be worked through and require judgment - especially in what it means for something in software to be "architecturally significant". For example I think build and version control systems are significant to software architecture, but I'm sure there are people that wouldn't agree.
  24. If you are in a work situation where people are pitting Java and COBOL solutions against one another as means of defining what's "too clever" and using the quoted excerpt as backing, might I put forth that there's so much dysfunction there that one should consider moving on to somewhere else?
    You do realize that most business software still runs on COBOL right? What's dysfunctional about it? I think it's dysfunctional to quit just because everything isn't the way you'd like it to be. If everyone thought like that, we'd all be in deep trouble. And why do you assume I'm talking about a single place of business? In any event, it's really aside from the point. These were just examples. One person's 'clever' is another person's 'dumb'. An person might think something's too clever just because they don't really understand it. My experience is that poor decisions are made when such obtuse rules are applied. The fact is that clever is extremely poorly defined in this context. To me that section is merely a mirror. It only reflects back what people already have in their heads.
    The idea with this book (as I understood it) was to share distillations of insight gleaned through years of experience, not to provide a proof text that would serve as a tool for software architects to combat one another. Anyone viewing this work as a means for such a thing is laboring under a severe misapprehension.
    Have you worked with any consultants lately? A lot of them don't care about what's good for their clients. They care about getting in, getting paid, and getting out or, even worse, setting up hugely expensive maintenance contracts which can conveniently be serviced by the outsourcing arm of their company. Vague principles that are easily misinterpreted are perfect fodder for rationalizing poorly designed garbage.
  25. I believe GWT is elegant. However, I had to argue with the management at my last job about using it "because other people didn't understand it." What if they had to do VC++, Swing, or AWT? Or use some other GUI API? I also had to battle to get things like Hibernate and Spring in. What if I'd fallen into the "Don't be too clever" using the unwillingness to consider these technologies as the metric. Some of our best work came out of the use of those technologies and everyone from junior and senior to customer benefited. I agree with the sentiment and pearls of wisdom are important but so is clarity.
  26. The circle closes...[ Go to top ]

    I believe GWT is elegant. However, I had to argue with the management at my last job about using it "because other people didn't understand it."
    I also had to battle to get things like Hibernate and Spring in.
    Heh. Where I used to work, someone *cough* battled to get Hibernate and Spring in, but "other people didn't understand it". So the architects wound up writing massive wrappers (and Ant tasks to generate them) so other people didn't have to understand it. So now they have a really hairy framework that provides some simple, basic services — and they can't do anything clever.
  27. Re: The circle closes...[ Go to top ]

    So the architects wound up writing massive wrappers (and Ant tasks to generate them) so other people didn't have to understand it.
    That's the clever part.
    So now they have a really hairy framework that provides some simple, basic services — and they can't do anything clever.
    And that's the problem with cleverness.
  28. Re: The circle closes...[ Go to top ]

    I believe GWT is elegant. However, I had to argue with the management at my last job about using it "because other people didn't understand it."
    I also had to battle to get things like Hibernate and Spring in.


    Heh. Where I used to work, someone *cough* battled to get Hibernate and Spring in, but "other people didn't understand it". So the architects wound up writing massive wrappers (and Ant tasks to generate them) so other people didn't have to understand it. So now they have a really hairy framework that provides some simple, basic services — and they can't do anything clever.
    I don't mind the battle. If your ideas can't take a little scrutiny, then it probably isn't that good. One metric I use to know if my code is sound is "Does it survive me?" When I leave, do they immediately rewrite or dump my stuff or is it still in use. If I were those guys, I would have spent time educating the other developers as opposed to working around them. Educate. Discuss. KISS. The last was the hardest, but they all came around. :-)
  29. You do realize that most business software still runs on COBOL right? What's dysfunctional about it?
    He didn't say using COBOL was dysfunctional.
  30. One person's 'clever' is another person's 'dumb'. An person might think something's too clever just because they don't really understand it. My experience is that poor decisions are made when such obtuse rules are applied
    James, maybe this is the key. Is this not the very reason that we have jobs, that there is such a job as Software Architect instead of nothing? Is not our very job to be the guy who looks in that mirror you describe and make the determination that for this company, for this problem, with these constraints, this solution is right or wrong, too clever or, as you put it nicely, too tricky, or just right? Perhaps that's why the job exists in the first place. We're the guy who looks in that mirror and makes that interpretive call.
  31. One person's 'clever' is another person's 'dumb'. An person might think something's too clever just because they don't really understand it. My experience is that poor decisions are made when such obtuse rules are applied


    James, maybe this is the key. Is this not the very reason that we have jobs, that there is such a job as Software Architect instead of nothing? Is not our very job to be the guy who looks in that mirror you describe and make the determination that for this company, for this problem, with these constraints, this solution is right or wrong, too clever or, as you put it nicely, too tricky, or just right?

    Perhaps that's why the job exists in the first place. We're the guy who looks in that mirror and makes that interpretive call.
    If every software company and IT department had people with your ideals as architects we'd have much better software (as in a less than an 80% estimated failure rate.) But the reality is that most people in software and IT are not qualified to be in the positions they have. Anything that makes them sound like they know what they are doing is going to be used. Maybe its my problem but I don't have the verbal Jujitsu skills to get past all of the nonsense arguments I come up against. By the time I've argued past the "but that would be doing more than one thing" argument and the "we're not a software company" argument and the "you are just criticizing complaint" and the "you are trying to be clever" argument, the meeting is over. Maybe it's just that I like to use analogies and a lot of people don't really get analogies. But in any event, "Don't be clever" terrifies me. It appears at a very superficial level to align itself with the most wrongheaded (IMO) ideas in IT. I really would be less worried if there were more clarification about this on the web page. The real point is something I really do agree with.
  32. But in any event, "Don't be clever" terrifies me. It appears at a very superficial level to align itself with the most wrongheaded (IMO) ideas in IT.
    If you agree with the point, but are worried about how your team members might interpret it, perhaps Brian Goetz explains it better than I do, and you can point them to this: http://java.sun.com/developer/technicalArticles/Interviews/goetz_qa.html Or to this little quiz linked to from the java homepage--check out question 3: http://java.sun.com/developer/Quizzes/javaexperts/ So, I'm just sort of, "terrifying?"...
  33. If you agree with the point, but are worried about how your team members might interpret it, perhaps Brian Goetz explains it better than I do, and you can point them to this:
    It's a little better. The problem is that writing clear straightforward code is smart and creating clean straightforward designs is smart. I mean smart in the most straightforward literal sense. Calling 'smart' choices 'dumb' is (in your parlance) 'clever'. It creates impact and gets people's attention but at the cost of clarity. That's really my point.
    So, I'm just sort of, "terrifying?"...
    I think you're swell. What I'm terrified of is what the world will do with your words. I'm afraid you will be writing blog posts in a few years lamenting how the world got your principle all wrong. Look at what a lot of the Agile founders are saying these days for examples.
  34. Calling 'smart' choices 'dumb' is (in your parlance) 'clever'. It creates impact and gets people's attention but at the cost of clarity.
    Well played, Mr Watson, well played. Fair enough. Recall that a previous poster uses the term "koans". At the risk of taking on a certain ethereal quality, isn't that the very problem with being clever. And isn't it hard to avoid. That is, if I had taken your advice, as I should have, I might have thought, "Don't Be Clever"... :)
  35. Blame the whole book?[ Go to top ]

    Hey. I was one of the posters for the book, although my entry was not chosen because it lacked "passion" in the writing. If you go to the site, you will find much more entries than the ones chosen for the book, from several different people from around the world (included mine). I think you are blaming the whole book just because you don't like ONE post in it. We need to understand this is a compilation, not the truth from heaven. That is, you will find several authors, that write in different ways, some clearer that others, some more to the point than others. That is why you have 97 entries, plus all the others that are not in the book just because the book has the 97 in the title. So, go ahead and read, you may find just one pearl (or more) there that changes your life, or you may not.
    William Martinez Pomares.
    Architect's Thoughts
  36. Re: Blame the whole book?[ Go to top ]

    Hey.
    So, go ahead and read, you may find just one pearl (or more) there that changes your life, or you may not.


    William Martinez Pomares.
    Architect's Thoughts
    +1. Years ago, back in '95, I read something that changed my coding life on a C++ graphics newsgroup. "Third-party libraries make me seem much smarter than I actually am."