O'Reilly FYI

News from within O'Reilly

What do you think every software architect should know?

 
By Kathryn Barrett
February 11, 2009 | Comments: 2

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. You can pick it up, read a segment, and ponder it while you work, commute, or do whatever. It's written for software architects and aspiring software architects: anyone who wants to improve or cement his or her career standing.

But it's not only "experts" who have valuable advice. You probably have your own bits of professional wisdom, gained through experience or observation. Given the opportunity, what piece of advice would you share with software architects? What have you learned that's made a difference in your work? Now here's your chance to win three free O'Reilly books of your choice. Share your thoughts here during the next week (before 5 pm PT, Feb. 19, 2009), and we'll select one winner (in our totally arbitrary fashion) to receive three free books. It's a nice way to share with others and maybe help yourself.

You may also want to join Richard Monson-Haefel, the book's editor, for his live webcast on Tuesday, Feb. 17: 10 Things Every Software Architect Should Know. It takes place at 10 am P T and it's free.


You might also be interested in:

2 Comments

These immediately come to mind:

1. Make sure you're actually making your project do what it's supposed to do. Now this might sound like common sense, but if you misunderstand what you're supposed to be doing, you're going to create something that no one wants to do. And it's going to look bad on you, and it's going to take longer to get the final project done when you have to go back and rework it until it meets that specifications you were unsure of.
2. Learn the buzzwords, even if you don't care about them, because you'll be able to weed out useless information more easily and focus on the real problems. You'll be confident knowing someone's full of B.S. when they're using their buzzwords and you have a better idea of what's going on than they do.
3. Find a topic you're not good at and nail it into your skull until it becomes a part of your being. This might include lots of practice and studying.

Always make sure to document your projects, methods, classes, etc. This may seem like a no-brainer but most programmers fail to document enough or they document things that don't need it. Other programmers will think better of you if your code is easy to follow. Also, pick a convention to use when commenting. It is easier to read code comments when they all follow a standard pattern. There are tools out there that use certain commenting conventions, so you may save yourself some headaches if you pick a widely accepted format for your comments.
Once you have documented your code, get it peer reviewed. What may seem obvious to you, may not be obvious to others. As the author, you are too close to your own code, find someone who isn't. Make a note of which pieces they find difficult to understand and further document those.
If you don't have the motivation to comment a piece of code, at the very least, put in a comment stub with some notation stating that it needs commenting. This way, you can easily come back later and finish commenting those sections. Good programming isn't simply efficient programming, it's also programming that doesn't give you a headache while reading it.

 

Popular Topics

Browse Books

Archives

Or, visit our complete archives.

FYI Topics

Recommended for You

Got a Question?