Apr 27, 2011
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.
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.
Apr 20, 2011
Memory Leaks in Java
Good post about the different types of memory leaks which you should be aware of: http://blog.dynatrace.com/2011/04/20/the-top-java-memory-problems-part-1/
Apr 19, 2011
How not to scale
Brilliant short presentation: http://www.youtube.com/watch?v=nPG4sK_glls&feature=youtu.be
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)
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"
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"
Subscribe to:
Posts (Atom)