The Pragmatic Craftsman :: Simplicity from complexity : by Stanley Kubasek ::

I’m reading the Code Craft blog (I discovered it a few days ago) andI’m really enjoying the entries there. I recommend you check it out.

Here are few entries which are worth a read. The author writes from India, where he currently works. His summary of the Indian software market is the best you will find — he just tells it how it is. Excellent writing.

Indian bubble    – unless you are willing to pay wagesthat start to sound a lot like like US wages, attracting top people is nearly impossible

Knowing, doing and learning

Let the hard stay hard

Finding coders on the subcontinent    – The practical reality is that anyonein India who can spell Java already has a job.    – experienced candidates… less thanone in five could write a loop that counted from one to ten in AN Y programming language    – you have to interview too many badcandidates to find the really good ones

ReferenceCode Craft by Kevin Barnes

Excellent article about SOA. The article should be called Pragmatic SOA 101 — hype free.

ResourceSOA best practices (need an IBM account), Mark Lorenz

Great dose of advise. Hundred one points, to be exact.

ReferenceLessons from Project Management: 101 ways to organize your life, Project Management Source blog

What are the key elements that ensure the success of your project? What are the keys that will tell you not to continue with the project? I don’t know to tell you the truth. But the four things that are outlined below, and explained by Reganwald blog, I are crucial, in my opinion. This is a very good, must-read and re-read (notice new category ), article.

Excerpts from the entry:

I’ve read the whole article and it is one of the best I’ve read on the subject! I concur that these things are crucial.

Reference What I’ve learned from failure, Raganwald blog

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)!