Apr 21, 2011

How organizational structure impacts architecture

Melvin Conway was a computer engineer back in 1968, but I find his observations from back then, all so true today: http://www.code-muse.com/blog/?p=7

Also, if you've heard of Craig Larman (I've heard of him because of one of his earlier books - "Applying UML and Patterns"), then I highly recommend watching: http://www.infoq.com/presentations/Large-Multisite-or-Offshore-Delivery. Don't be mislead by the title - it's more about how you should structure your team(s)/organization for proper software development work.

Scaling explained

http://tinyurl.com/3na6aqs

Apr 20, 2011

Apr 15, 2011

Development Environment

Check out the nice diagram http://tinyurl.com/65hwzzz of how a good development environment should look like.

Unlike software design where "adding an extra layer of indirection" helps solve all your problems, try to keep the "layers" of the dev enviroment as few and as simple as possible. And try to use systems which are supported by a strong community (hudson/jenkins split doesn't help one bit in this area)

Apr 14, 2011

A decent perspective on Software Architects

Finally, a good post about the so called "Ivory Tower" architects: http://www.codingthearchitecture.com/pages/book/software-development-is-not-a-relay-sport.html.

I've deeply disliked (to avoid using words such as hate) for a long long time this type of people with their precious roles. The larger a software organization gets, more and more useless roles are created. The people in those roles, in the end, not only don't help the actual team working and delivering software, but they slow it down.

On the other hand, never underestimate the human ego when you have a business card with the title "Software Architect"