Disqus - Latest Comments for andysingleton

Re: Speed Up Your Product Development Without Losing Control

andysingleton — Mon, 21 Jul 2014 17:50:33 -0000

I agree that automation is important. It is essential for the process described in this article. I like the idea of "Development Automation".

I started to think about it in a simple way: A human gets more productive by using machine power. We are getting more productive because machines are doing a lot of the build / test / deploy work. In this way, product development is much like coal mining or farming, where it is even more obvious that over time we are using bigger machines to get more productivity from one person.

Re: Speed Up Your Product Development Without Losing Control

andysingleton — Mon, 21 Jul 2014 17:47:26 -0000

I was a very early Hubspot customer. I can confirm that their product quality was not very good, and then it increased a lot in the last 1.5 years. As a user, I got a lot of benefit from their continuous delivery process.

Re: Speed Up Your Product Development Without Losing Control

andysingleton — Mon, 21 Jul 2014 11:16:10 -0000

Yes, I think that Conway's law is very relevant here. We are trying to build a system as multiple independent services, and we use separate service teams to build, release and maintain them.

Yes, complexity will always cost money and time. However, I think that Brooks' "Mythical Man Month" observations are obsolete. He had a 40 year run of amazing insights about managing big projects. During this time, it was generally true that large projects were inefficient or even prone to "failure", and no silver bullet was found. Things have changed in the last few years. Companies like Amazon and Google have blasted through the size barrier.

They did it with a couple of tactics:
1) Using independent service teams. These teams communicate peer-to-peer to get what htey need and resolve dependencies.
2) Using a continuous integration machine that finds problems in the dependencies of one team on another through automated testing, and notifies both teams. This is BRILLIANT, because it replaces the most difficult part of human project management with a machine.

The underlying theory behind this goes directly against Brook's theory. He theorized that the problem is communications - with an increase in comunication channels of N partricipants to N^2 channels, which causes work and confusion. If you believe this, you organize hierarchically to contain the communicaitons. ACTUALLY, the most scalable projects (such as LInux) have the most open communications.

I think that the real problem with big projects is dependencies. If you have one person, he is never waiting for himself. If you have 100 people, it's pretty common for 50 people to be waiting for something. The solution to this is actually more open communication that allows those 50 people to fix problems themselves.

I have written several blog articles challenging the analysis in the Mythical Man Month, if you are interested.

Re: CloudCamp Boston

andysingleton — Mon, 03 Aug 2009 07:10:32 -0000

My comments on Cloudcamp Boston are posted at blog.assembla.com. I learned some good stuff from John's introduction. We could improve the conference format. I vote for more breakout sessions and skipping the 5 minute advertisements and the unpanel.
http://blog.assembla.com/as...