The Pragmatic Craftsman :: Simplicity from complexity ::

Software writers I love. There are only a couple of them. Paul Graham is in this group. (Steve McConnell, Martin Fowler, Robert Martin are the rest (out of top of my head)). His essays are always top quality. They are filled with some great, practical information. They are based on his personal experiences. They are really valuable to read.

One of the recent articles from Paul Graham, How To Start A Startup (see my post on it), was great. It’s filled with practical info. It’s well written. It’s complicated info explained in simple terms.

Another one I really like is Beating the Averages. (This one I plan to re-read every year.) If you want to be a successful company, a successful developer, beat the average guys. There is a lot of good information in this article.

I have not read all of Paul’s essays yet, but I’m sure they’re top quality. Paul publishes an essay a month, roughly.

I read Paul’s essays because they’re filled with useful, practical information. I read his essays because I like to read the best. I read Paul’s essays because I can see best writing in action (good way to improve — he even has an article on how to improve your writing , Writing, Briefly). Not enough?

Reference[1] PaulGraham.com — His website[2] Paul Graham’s RSS Feed

Martin Fowler, to me, is a great IT mind. He has written three (that I know of) books that are on my must-read list. I I own the first two. All three are pretty much classics in the industry. They are: Refactoring, UML Distilled, and Patterns of Enterprise Architecture.

Fowler has also written countless articles on design (Is Design Dead? is my favorite) and architecture (mainly in IEEE Software magazine, where he is still the editor of Design).

Needless to say, Martin Fowler is an industry leader, great writer. He’s somebody that you should know about as a software engineer. (And read his books, too.)

That’s enough about him, the person, since this post is about his blog, Martin Fowler’s Bliki. I’ve been reading it for couple of months now. I think it’s pretty good. I’ve been enjoying it. It’s a bit on a technical side (he is an architect after all) but he touches several areas, mainly design, architecture, refactoring, uml, agile-development, and others. Add it to your RSS Reader (I use Bloglines) and enjoy it too.

I don’t know what’s so complicated about UML that I never seem to get it. Or I never seem to remember it. I guess I like to learn by doing. I just don’t learn by reading an article or a book. Nonetheless, you need an article to learn the concepts. Read on.

I’ve read quite a few articles about UML but I had always been confused. I even read some of UML Distilled book (chapter about class diagram) by Fowler (considered a classic intro to UML), which to me is a little vague and not specific enough. (I did like the UML User Guide, though, by Grady Booch, the original author of UML.) However, I don’t think that you really need a book to learn the class diagrams — you can learn from a good article. I am going to give you the article that it is currently my number one intro to UML’s class diagrams. It was published by The Rational Edge and was written by Donald Bell, here is the link. He breaks it very nice: simple, clear, and gradual. With good examples too. Read it, re-read it, and whenever you get a chance draw some. You’ll learn and you’ll remember. Not like me. (( But I think I’m getting it now.

Article Link: UML Basics: The class diagram by Donald Bell

This is as good of an article on requirements as I’ve ever read. It is 20 pages long, but you should make effort to read it. The article comes from Gary Evans (very good writer) and it was published in July 2004 edition of The Rational Edge. (I have been subscribed to Rational Edge (free) e-zine for couple of months now, and it is one of the best publications that I read.)

Evans tells you how to get from a start of a project — gathering requirements — to the point where you can write code. What’s different about Evans than the other writers is that he takes you along step by step and shows you an easy example as he explains something. Very good job, Evans. So, he first tells you about use cases, and shows you how to write one. Then he goes on and takes you through a step of finding classes from the use case. Next is seeing the interaction between the classes through an UML class diagram and a sequence diagram. After that, you add attributes to it and you are almost ready to code.

Almost ready, because this was only part I of the series. The second is coming next month. But even without the second it would be quite easy to go from the diagrams to code. I really enjoyed the article. See more about the author on Evanetics.com

JoelOnSofware.com: this is a very good, very well-written blog about software development with a concentration on managing the development process. Joel has some great essays on Painless Functional Specifications: A series of articles on writing functional specifications. If you’re involved in software development and don’t write specs, he’ll probably convince you that you should — in the end, you’re hurting yourself and wasting time if you don’t (but still a lot of us don’t write it!).

The Joel Test gives you a pretty good indication where your software team, and company, is. The Archive section gives you a bigger picture of what he’s written about.

Read the blog and improve your software development! I know I’m going to be reading it and I recommend it to any software developer/engineer and project manager.

Joel started a company, Fog Creek, recently, that looks very enticing — I would definitely would want to work for his company. Check out the about page and see for yourself. I wish more CEOs were looking out for programmers as much as he is. We would develop better software (that’s a proved fact)!