<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Startups: Fire Your Dev Teams</title>
	<atom:link href="http://mikemason.ca/blog/2008/01/startups-fire-your-dev-teams/feed/" rel="self" type="application/rss+xml" />
	<link>http://mikemason.ca/blog/2008/01/startups-fire-your-dev-teams/</link>
	<description>agile thinking</description>
	<lastBuildDate>Mon, 02 Apr 2012 03:52:56 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Rachel</title>
		<link>http://mikemason.ca/blog/2008/01/startups-fire-your-dev-teams/comment-page-1/#comment-35903</link>
		<dc:creator>Rachel</dc:creator>
		<pubDate>Sun, 30 May 2010 22:34:55 +0000</pubDate>
		<guid isPermaLink="false">http://mikemason.ca/blog/?p=19#comment-35903</guid>
		<description>&quot;The minute you’re successful, plan to rewrite your software from scratch&quot; - I have one word in response to this misguided notion: Netscape. Old code is good code, because it’s been well-tested and debugged, and, most importantly, it’s been well received and taken up by the market place. Just ask the people at Netscape, who made a feature out of re-writing their entire code base, just when they got to a leading market position, then fell further and further behind the competition as their perpetually-delayed &#039;new and improved&#039; browser failed to seize the moment in the way their original offering had done. Successful startups are about being new and innovative, they’re never, ever about re-inventing wheels.</description>
		<content:encoded><![CDATA[<p>&#8220;The minute you’re successful, plan to rewrite your software from scratch&#8221; &#8211; I have one word in response to this misguided notion: Netscape. Old code is good code, because it’s been well-tested and debugged, and, most importantly, it’s been well received and taken up by the market place. Just ask the people at Netscape, who made a feature out of re-writing their entire code base, just when they got to a leading market position, then fell further and further behind the competition as their perpetually-delayed &#8216;new and improved&#8217; browser failed to seize the moment in the way their original offering had done. Successful startups are about being new and innovative, they’re never, ever about re-inventing wheels.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jason</title>
		<link>http://mikemason.ca/blog/2008/01/startups-fire-your-dev-teams/comment-page-1/#comment-10730</link>
		<dc:creator>jason</dc:creator>
		<pubDate>Fri, 20 Feb 2009 16:35:18 +0000</pubDate>
		<guid isPermaLink="false">http://mikemason.ca/blog/?p=19#comment-10730</guid>
		<description>I badly _want_ to disagree, but experience says you are mostly correct.  I&#039;ve worked on a few new enterprise products that have been amazingly successful but struggled a little after success.  I wouldn&#039;t fire the _entire_ initial dev team, but I would include the dev. manager(s), if they are also not well-rounded enough to handle the road from start-up to enterprise.

Not all, but a good number, (50-75%?), of the development and management folks that brought a product to its first release are complete software development flatfoots.  They were fast because they knew _one_ way to do things and did it well.  They were flatfoots because after 5 years they still only knew one way to build something, wrote horrible code with high prod support and maintenance costs, and they could not figure out how to work with a structured development process.  

I am glad you mentioned this, because I had not yet realized why some of these developers or managers were ever useful.  I actually appreciate them a little more, now that I see where they would excel.  Maybe they weren&#039;t morons, just better aimed for startup work.  Great post, Mike!</description>
		<content:encoded><![CDATA[<p>I badly _want_ to disagree, but experience says you are mostly correct.  I&#8217;ve worked on a few new enterprise products that have been amazingly successful but struggled a little after success.  I wouldn&#8217;t fire the _entire_ initial dev team, but I would include the dev. manager(s), if they are also not well-rounded enough to handle the road from start-up to enterprise.</p>
<p>Not all, but a good number, (50-75%?), of the development and management folks that brought a product to its first release are complete software development flatfoots.  They were fast because they knew _one_ way to do things and did it well.  They were flatfoots because after 5 years they still only knew one way to build something, wrote horrible code with high prod support and maintenance costs, and they could not figure out how to work with a structured development process.  </p>
<p>I am glad you mentioned this, because I had not yet realized why some of these developers or managers were ever useful.  I actually appreciate them a little more, now that I see where they would excel.  Maybe they weren&#8217;t morons, just better aimed for startup work.  Great post, Mike!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mike</title>
		<link>http://mikemason.ca/blog/2008/01/startups-fire-your-dev-teams/comment-page-1/#comment-10579</link>
		<dc:creator>mike</dc:creator>
		<pubDate>Wed, 18 Feb 2009 06:23:04 +0000</pubDate>
		<guid isPermaLink="false">http://mikemason.ca/blog/?p=19#comment-10579</guid>
		<description>We fired a guy, he got a job at Intel the next week. Should we higher him back now?</description>
		<content:encoded><![CDATA[<p>We fired a guy, he got a job at Intel the next week. Should we higher him back now?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Stephan Schmidt</title>
		<link>http://mikemason.ca/blog/2008/01/startups-fire-your-dev-teams/comment-page-1/#comment-276</link>
		<dc:creator>Stephan Schmidt</dc:creator>
		<pubDate>Sun, 20 Apr 2008 07:39:16 +0000</pubDate>
		<guid isPermaLink="false">http://mikemason.ca/blog/?p=19#comment-276</guid>
		<description>Excellent post, exactly my experiences. 

What commenters miss here, it&#039;s not about hiring smart developers. Because it&#039;s not about skills but mind sets. Startup vs. Enterprise mind sets.  I&#039;ve seen both and they differ a lot.

Peace
-stephan</description>
		<content:encoded><![CDATA[<p>Excellent post, exactly my experiences. </p>
<p>What commenters miss here, it&#8217;s not about hiring smart developers. Because it&#8217;s not about skills but mind sets. Startup vs. Enterprise mind sets.  I&#8217;ve seen both and they differ a lot.</p>
<p>Peace<br />
-stephan</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike Mason &#187; Fire your dev teams (reprise)</title>
		<link>http://mikemason.ca/blog/2008/01/startups-fire-your-dev-teams/comment-page-1/#comment-130</link>
		<dc:creator>Mike Mason &#187; Fire your dev teams (reprise)</dc:creator>
		<pubDate>Sun, 09 Mar 2008 17:49:50 +0000</pubDate>
		<guid isPermaLink="false">http://mikemason.ca/blog/?p=19#comment-130</guid>
		<description>[...] of course I don&#8217;t really think you can fire your entire development team and throw away your existing successful code base. Just because a blog post is spell checked and [...]</description>
		<content:encoded><![CDATA[<p>[...] of course I don&#8217;t really think you can fire your entire development team and throw away your existing successful code base. Just because a blog post is spell checked and [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Original developers and non-workaholics beware &#8212; The Puerto Rican Rails Dude</title>
		<link>http://mikemason.ca/blog/2008/01/startups-fire-your-dev-teams/comment-page-1/#comment-129</link>
		<dc:creator>Original developers and non-workaholics beware &#8212; The Puerto Rican Rails Dude</dc:creator>
		<pubDate>Sat, 08 Mar 2008 17:52:17 +0000</pubDate>
		<guid isPermaLink="false">http://mikemason.ca/blog/?p=19#comment-129</guid>
		<description>[...] first one comes from Mike Mason, a software consultant, who advises start-ups to fire their original development team when the company has a successful launch. Of course, now that I&#8217;m part of a dev team [...]</description>
		<content:encoded><![CDATA[<p>[...] first one comes from Mike Mason, a software consultant, who advises start-ups to fire their original development team when the company has a successful launch. Of course, now that I&#8217;m part of a dev team [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Candelon</title>
		<link>http://mikemason.ca/blog/2008/01/startups-fire-your-dev-teams/comment-page-1/#comment-115</link>
		<dc:creator>Michael Candelon</dc:creator>
		<pubDate>Wed, 27 Feb 2008 22:18:40 +0000</pubDate>
		<guid isPermaLink="false">http://mikemason.ca/blog/?p=19#comment-115</guid>
		<description>I don&#039;t believe its helpful the group of people that got you to where you are now but all of that aside, the more I read articles geared toward me and my startup, the more I think that an attribute of a successful startup comes from making good use of the available resources specifically geared toward startups. One company, Sun Microsystems has a startup essentials program that gives startups discounts on x64 servers, free tech support and access to a 2.0 community. Not everyone has millions and that company knows it and its that outreach that I think we could use more of. www.sun.com/startup</description>
		<content:encoded><![CDATA[<p>I don&#8217;t believe its helpful the group of people that got you to where you are now but all of that aside, the more I read articles geared toward me and my startup, the more I think that an attribute of a successful startup comes from making good use of the available resources specifically geared toward startups. One company, Sun Microsystems has a startup essentials program that gives startups discounts on x64 servers, free tech support and access to a 2.0 community. Not everyone has millions and that company knows it and its that outreach that I think we could use more of. <a href="http://www.sun.com/startup" rel="nofollow">http://www.sun.com/startup</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ronny</title>
		<link>http://mikemason.ca/blog/2008/01/startups-fire-your-dev-teams/comment-page-1/#comment-94</link>
		<dc:creator>Ronny</dc:creator>
		<pubDate>Mon, 18 Feb 2008 02:20:42 +0000</pubDate>
		<guid isPermaLink="false">http://mikemason.ca/blog/?p=19#comment-94</guid>
		<description>Forgot to comment on rewriting the whole app. Ask the Netscape team if that is a good idea!
However if you hired a bunch of monkeys in the first place and/or it stretched it too far before you allowed them to do bugfixes (features galore, no time to fix bugs or architectural flaws), so the code is in such a bloody mess that it&#039;s beyond repair, it might be the only alternative. But in that case, I&#039;m surprised that the company is doing good in the first place because as mentioned in earlier replies, management much be incompetent!
In any case, if you hired at least one real hacker, and [IMPORTANT] let them know your general business goal,  at least the architecture should be half decent.</description>
		<content:encoded><![CDATA[<p>Forgot to comment on rewriting the whole app. Ask the Netscape team if that is a good idea!<br />
However if you hired a bunch of monkeys in the first place and/or it stretched it too far before you allowed them to do bugfixes (features galore, no time to fix bugs or architectural flaws), so the code is in such a bloody mess that it&#8217;s beyond repair, it might be the only alternative. But in that case, I&#8217;m surprised that the company is doing good in the first place because as mentioned in earlier replies, management much be incompetent!<br />
In any case, if you hired at least one real hacker, and [IMPORTANT] let them know your general business goal,  at least the architecture should be half decent.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ronny</title>
		<link>http://mikemason.ca/blog/2008/01/startups-fire-your-dev-teams/comment-page-1/#comment-93</link>
		<dc:creator>Ronny</dc:creator>
		<pubDate>Mon, 18 Feb 2008 02:08:39 +0000</pubDate>
		<guid isPermaLink="false">http://mikemason.ca/blog/?p=19#comment-93</guid>
		<description>Hahaha! Although you have an occasional good point, firing the entire dev team and rewriting all the sortware are the two worst ideas you could possibly think of!
You should never hire anything but great hackers for your development team, ever! And if you mistakenly did, then fire them immediately! The black and white scenario that you propose that &quot;all startup developers are useless at enterprise development&quot; is as stupid as saying &quot;all blacks are.....&quot;, &quot;all whites are&quot;, or &quot;all foreigners are....&quot;. If you give this advice to a public company, please let me know the stock ticker so I can short it! (Thanks, Joel, for the idea: http://www.joelonsoftware.com/articles/fog0000000245.html)
Unfortunately reality is not that simple! One thing is pretty simple though: Hire only good ones, fire all bad ones. The problem is that most management are utterly incapable of seeing the difference between them. *That* is what the focus should be on! And if you&#039;re thinking recruiters are better at it, forget it! They&#039;re worse! You think you can see it from their CV? Hahaha, you&#039;re funny!
By the way, what on earth is an &quot;enterprise developer&quot; anyway? If you refer to the ones certified by a big corporation, I&#039;d also like the stock ticker please! You can make loads from shorting I&#039;ve heard :)</description>
		<content:encoded><![CDATA[<p>Hahaha! Although you have an occasional good point, firing the entire dev team and rewriting all the sortware are the two worst ideas you could possibly think of!<br />
You should never hire anything but great hackers for your development team, ever! And if you mistakenly did, then fire them immediately! The black and white scenario that you propose that &#8220;all startup developers are useless at enterprise development&#8221; is as stupid as saying &#8220;all blacks are&#8230;..&#8221;, &#8220;all whites are&#8221;, or &#8220;all foreigners are&#8230;.&#8221;. If you give this advice to a public company, please let me know the stock ticker so I can short it! (Thanks, Joel, for the idea: <a href="http://www.joelonsoftware.com/articles/fog0000000245.html)" rel="nofollow">http://www.joelonsoftware.com/articles/fog0000000245.html)</a><br />
Unfortunately reality is not that simple! One thing is pretty simple though: Hire only good ones, fire all bad ones. The problem is that most management are utterly incapable of seeing the difference between them. *That* is what the focus should be on! And if you&#8217;re thinking recruiters are better at it, forget it! They&#8217;re worse! You think you can see it from their CV? Hahaha, you&#8217;re funny!<br />
By the way, what on earth is an &#8220;enterprise developer&#8221; anyway? If you refer to the ones certified by a big corporation, I&#8217;d also like the stock ticker please! You can make loads from shorting I&#8217;ve heard <img src='http://mikemason.ca/blog/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kjetil Valstadsve</title>
		<link>http://mikemason.ca/blog/2008/01/startups-fire-your-dev-teams/comment-page-1/#comment-92</link>
		<dc:creator>Kjetil Valstadsve</dc:creator>
		<pubDate>Sun, 17 Feb 2008 21:37:09 +0000</pubDate>
		<guid isPermaLink="false">http://mikemason.ca/blog/?p=19#comment-92</guid>
		<description>Hi Mike. You sure like polemics, don&#039;t you? What you are saying is straightforward enough: It takes different kinds of programmers for different phases of a company&#039;s life. I recognize the difference you point out, between &quot;startup&quot; and &quot;enterprise&quot; programming.  However, I think you will rarely have a clean-cut situation where the whole dev team is exclusively startup-mode. In fact, if a programmer is good enough, he or she is able to run both modes quite easily. It would be really unfair to be fired just because you&#039;ve been in the startup mode for a while. Also, it would be very wasteful, since your knowledge about the business is useful. But I guess you were polemical.

Some background: I myself have worked at a startup for a long time, and I recently got my old-timer ass moved onto the new, next-generation, full-rewrite project you are talking about. Management was certainly in &quot;enterprise&quot; mode - this was going to be a REAL project, mind you. Everyone was going to be writing design documents - in Word! - and no code, positively NO code, was to be keyed into anything, unless the Design Document had been approved. By a board of architects. When I was lobbying for the switch, I was informed that rogue coding was almost grounds for termination. Being an old hand, I had people working for my cause, and I got moved onto the project. (Thank you all.)

One would think this was the project you prescribe. Most of the staff were new hires. The Chief Architect was an old hand. But it wasn&#039;t that project. Code duplication was way over twice (!) that of the &quot;legacy&quot; code base I had left - I ran Simian. I noticed quickly that no &quot;utils&quot; or &quot;common&quot; module was defined by the Architects, so the natural cultivation of reusable libraries had been stopped in its tracks. Test coverage was low because of a low POJO factor. SOP for creating a new module was to copy the code of similar module, then tweak it. So basically, I quit Word and rolled up some sleeves.

It took a year or two (and not so many Word documents after all), and we beat the thing into shape. It is now a distributed, dynamic module system with dependency injection. I think the moral is that programmers of all kinds, if they&#039;re good enough, do not distinguish between the &quot;modes&quot; so much - they want to make something, and they recognize that the &quot;enterprise&quot; mode is valuable for what it&#039;s worth - and it does have worth in the &quot;enterprise&quot; phase. You just need someone to champion that perspective, and a base of good programmer talent.

I am not a champion, so this particular project got on because of all the great programmers on the team. If you are reading this and recognize the project, you know I&#039;m not complaining about anyone. It was a very educational experience. I will also point out that the original design was OK, it just didn&#039;t actually manifest so much in the code. Or, you could say, it manifested in way too many places in the code, in the varying shapes and forms you get with reuse by code duplication.

Mike, you make a good read, and you certainly have a point. But if you really have to fire your dev team, take a long hard look at the hiring practices and middle management, because your problem is NOT just with the grunts. And if you really have to rewrite the whole thing, you are taking on a huge, HUGE cost. The last nail in your theory&#039;s coffin? I wasn&#039;t fired, I&#039;m quitting!</description>
		<content:encoded><![CDATA[<p>Hi Mike. You sure like polemics, don&#8217;t you? What you are saying is straightforward enough: It takes different kinds of programmers for different phases of a company&#8217;s life. I recognize the difference you point out, between &#8220;startup&#8221; and &#8220;enterprise&#8221; programming.  However, I think you will rarely have a clean-cut situation where the whole dev team is exclusively startup-mode. In fact, if a programmer is good enough, he or she is able to run both modes quite easily. It would be really unfair to be fired just because you&#8217;ve been in the startup mode for a while. Also, it would be very wasteful, since your knowledge about the business is useful. But I guess you were polemical.</p>
<p>Some background: I myself have worked at a startup for a long time, and I recently got my old-timer ass moved onto the new, next-generation, full-rewrite project you are talking about. Management was certainly in &#8220;enterprise&#8221; mode &#8211; this was going to be a REAL project, mind you. Everyone was going to be writing design documents &#8211; in Word! &#8211; and no code, positively NO code, was to be keyed into anything, unless the Design Document had been approved. By a board of architects. When I was lobbying for the switch, I was informed that rogue coding was almost grounds for termination. Being an old hand, I had people working for my cause, and I got moved onto the project. (Thank you all.)</p>
<p>One would think this was the project you prescribe. Most of the staff were new hires. The Chief Architect was an old hand. But it wasn&#8217;t that project. Code duplication was way over twice (!) that of the &#8220;legacy&#8221; code base I had left &#8211; I ran Simian. I noticed quickly that no &#8220;utils&#8221; or &#8220;common&#8221; module was defined by the Architects, so the natural cultivation of reusable libraries had been stopped in its tracks. Test coverage was low because of a low POJO factor. SOP for creating a new module was to copy the code of similar module, then tweak it. So basically, I quit Word and rolled up some sleeves.</p>
<p>It took a year or two (and not so many Word documents after all), and we beat the thing into shape. It is now a distributed, dynamic module system with dependency injection. I think the moral is that programmers of all kinds, if they&#8217;re good enough, do not distinguish between the &#8220;modes&#8221; so much &#8211; they want to make something, and they recognize that the &#8220;enterprise&#8221; mode is valuable for what it&#8217;s worth &#8211; and it does have worth in the &#8220;enterprise&#8221; phase. You just need someone to champion that perspective, and a base of good programmer talent.</p>
<p>I am not a champion, so this particular project got on because of all the great programmers on the team. If you are reading this and recognize the project, you know I&#8217;m not complaining about anyone. It was a very educational experience. I will also point out that the original design was OK, it just didn&#8217;t actually manifest so much in the code. Or, you could say, it manifested in way too many places in the code, in the varying shapes and forms you get with reuse by code duplication.</p>
<p>Mike, you make a good read, and you certainly have a point. But if you really have to fire your dev team, take a long hard look at the hiring practices and middle management, because your problem is NOT just with the grunts. And if you really have to rewrite the whole thing, you are taking on a huge, HUGE cost. The last nail in your theory&#8217;s coffin? I wasn&#8217;t fired, I&#8217;m quitting!</p>
]]></content:encoded>
	</item>
</channel>
</rss>

