O'Reilly FYI

News from within O'Reilly

Contest: share advice for a chance to win 3 free books

By Kathryn Barrett
February 23, 2009 | Comments: 10

We're looking for your advice for software archictects: some wisdom you've gleaned through your experience or an observation that you can share.

97 Things Every Software Architect Should Know is a collection of short essays—only two pages each—by four dozen leading software architects such as Neal Ford, Michael Nygard, and Bill de h ra. It's a book of advice that deals with all sorts of development issues, some that go way beyond technology: communicating with stakeholders, eliminating complexity, empowering developers, and so on. But "experts" aren't the only ones with valuable advice. Take a minute to share yours and you could win three free books of your choice (the prize will be awarded in our customary, totally arbitrary fashion). Please post your comments by 5 pm PT on Tuesday, March 3. Plus—you can get bonus points for twittering about this.

You might also be interested in:


Read at least one business/interpersonal communication book per quarter:

I've find sometimes getting too deep in the technical creates a gap between what we do and what the "suits" want to drive.

Some recommendations:

-Making Things Happen (from O'Reilly ;)
-Crucial Conversations
-The Path of Least Resistance

I think that all Software Architects need to remember that we don't know everything. When an idea, tool or advice is proposed we should make sure that it doesn't apply or won't work before we dismiss it. Just because we are supposed to be experts doesn't mean that we know everything. Let's face it if every Architect knew everything they needed to there wouldn't be a need for a book like "97 Things Every Software Architect Should Know".

communication goes both ways - listen to what the client wants, then work out between you what the client actually *needs*. Keep talking, and keep listening.

Others have said it, but it bears repeating... if you're making software that communicates with other programs be as forgiving as possible in the messages your software will accept, and as perfectly formed and standards-following as possible in the messages your software sends out. Doing that reduces the chances that other programs can stop your software from working, AND it reduces the chances that your software causes some other application to break.

My advise is about "ecosystem". Even when one could think this technology is the best in world and that it is rock-solid, sometimes it does not fit with the organization environment causing more problems that solution when implementing it. I have seen that many times, and I consider that a good architect should know when and how a particular technology should be applied to a customer IT ecosystem.

I would summarize my 50c worth of advice in the following three bullets:

  • Know thy domain (and if you don't, research: read, work with similar systems)
  • Know thy problem (and if you don't, talk: to the client, to fellow architects)
  • Know thy technologies (and if you don't, evaluate: read books, develop prototypes)

* Expose your own APIs and use them.
* Automate your processes.
* Measure everything (loc, defects, time to fix, commits), let the team know you are measuring and make your measurements available.
* Invest in automatic testing.
* Pay attention to usability.

Code to elegance and intelligence , how ?
Elegance can be achieved from down through OO design patterns and incremental code design and architect , and can be achieved at top from the user inteface and interaction design , the best example is MAC OS X user interface , it's awesome .

Intelligence can be achieved from the code that learn from its user behaviour , by the time it act like the user , if the user was hurry or forget to do something of the repeated actions that she used to , absolutely there will be piriorities and limitaion to what the app can do instead of his user , app can't delete things ... etc , but can minimize after reading all mails and still inactive for awhile, can open the tab that the user open it every once he open the app automatically , the app should talk to the user and be his friend :).

let the people share in this innovation by exposing your api and internals .

Keep it simple and minimal. You will likely reap more benefits than incur loss.

* You can always be right. You just have to be willing to be proven wrong. Then Simply adopt the new position and **poof** you are right again.

* You may be smarter than any one else in the room. You are not smarter than tens, hundreds, or thousands of your peers working toward a common goal. Quit reinventing the wheel, use and contribute.

* Always work under the assumption that the way you are solving a problem is not the best solution, inefficient, and buggy. It will keep you from getting cocky and drive you to constantly improve.


Popular Topics

Browse Books


Or, visit our complete archives.

FYI Topics

Recommended for You

Got a Question?