<?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"
	>
<channel>
	<title>Comments on: Over Engineering Software</title>
	<atom:link href="http://blog.digitalstruct.com/2008/02/17/over-engineering-software/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.digitalstruct.com/2008/02/17/over-engineering-software/</link>
	<description>Getting inside the mind of a php developer.</description>
	<pubDate>Thu, 21 Aug 2008 18:49:22 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6</generator>
		<item>
		<title>By: Mike Willbanks</title>
		<link>http://blog.digitalstruct.com/2008/02/17/over-engineering-software/#comment-38598</link>
		<dc:creator>Mike Willbanks</dc:creator>
		<pubDate>Tue, 19 Feb 2008 05:08:58 +0000</pubDate>
		<guid isPermaLink="false">http://blog.digitalstruct.com/2008/02/17/over-engineering-software/#comment-38598</guid>
		<description>I believe it all depends on what you are needing.  I do not always follow in the steps of building out certain areas unless I deem them as absolute necessity going forward.  I typically do refactoring in much of my code.  

For instance, lets take the last personal project I worked on.  Phase 1 included only core behavior, while I plan for an administration area in the future, I didn't build any of it, rather built the components that I will be utilizing for certain sections.  Phase 2 is building an administration area and refactoring the code to run off a more centralized area (right now data is simply cached from a third party in files rather than being extensible from a database perspective).  Phase 3 is to build the features on top of what was previously there.

Rather, what I speak of is simply to stop over engineering certain aspects.  I could have taken phase 2 and said, well it is necessary for the data to be stored in the database right away, when I have no clue of the marketability of the said product.  It solves the task but doesn't completely give all of the functionality that it could have.  Meanwhile, the object oriented structure in place to allow modifying the data source with little to no extra effort.  Which left an interface for building in the future.  

It is both maintainable and extensible to build what I may need on top of the components already built.  As developers we will be faced with the decision of what approach is going to be better (build for refactoring or build for abstraction).</description>
		<content:encoded><![CDATA[<p>I believe it all depends on what you are needing.  I do not always follow in the steps of building out certain areas unless I deem them as absolute necessity going forward.  I typically do refactoring in much of my code.  </p>
<p>For instance, lets take the last personal project I worked on.  Phase 1 included only core behavior, while I plan for an administration area in the future, I didn&#8217;t build any of it, rather built the components that I will be utilizing for certain sections.  Phase 2 is building an administration area and refactoring the code to run off a more centralized area (right now data is simply cached from a third party in files rather than being extensible from a database perspective).  Phase 3 is to build the features on top of what was previously there.</p>
<p>Rather, what I speak of is simply to stop over engineering certain aspects.  I could have taken phase 2 and said, well it is necessary for the data to be stored in the database right away, when I have no clue of the marketability of the said product.  It solves the task but doesn&#8217;t completely give all of the functionality that it could have.  Meanwhile, the object oriented structure in place to allow modifying the data source with little to no extra effort.  Which left an interface for building in the future.  </p>
<p>It is both maintainable and extensible to build what I may need on top of the components already built.  As developers we will be faced with the decision of what approach is going to be better (build for refactoring or build for abstraction).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Evert</title>
		<link>http://blog.digitalstruct.com/2008/02/17/over-engineering-software/#comment-38584</link>
		<dc:creator>Evert</dc:creator>
		<pubDate>Mon, 18 Feb 2008 22:08:56 +0000</pubDate>
		<guid isPermaLink="false">http://blog.digitalstruct.com/2008/02/17/over-engineering-software/#comment-38584</guid>
		<description>I'm with sebs..

My approach used to be yours, and try to build a semi-framework for every feature.. Later on I realized there was more work in maintaining the abstraction, while in a lot of cases it was unnecessary to begin with..

Writing maintainable code is very important, and design for change is too.. My moniker is now 'build for refactoring' instead of 'build for abstraction'.</description>
		<content:encoded><![CDATA[<p>I&#8217;m with sebs..</p>
<p>My approach used to be yours, and try to build a semi-framework for every feature.. Later on I realized there was more work in maintaining the abstraction, while in a lot of cases it was unnecessary to begin with..</p>
<p>Writing maintainable code is very important, and design for change is too.. My moniker is now &#8216;build for refactoring&#8217; instead of &#8216;build for abstraction&#8217;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: stefan</title>
		<link>http://blog.digitalstruct.com/2008/02/17/over-engineering-software/#comment-38569</link>
		<dc:creator>stefan</dc:creator>
		<pubDate>Mon, 18 Feb 2008 10:49:00 +0000</pubDate>
		<guid isPermaLink="false">http://blog.digitalstruct.com/2008/02/17/over-engineering-software/#comment-38569</guid>
		<description>I refactor a lot. My experience is that in my mind, things will become much more clear when I have some basic structure in place, so the first thing I'll do is write myself a small prototype, and extend that over and over until I have the features I want.

Because I work with a framework (symfony in this case), I have the added advantage of being able to install plugins and configure a lot. Things such as authentication are all caught with the sfGuard plugin, and then adding the correct authorization is a matter of editing a configuration file telling which modules can be accessed with which credentials.

so aside from writing OO code, doing it with a framework will speed up development and re-usability even more.</description>
		<content:encoded><![CDATA[<p>I refactor a lot. My experience is that in my mind, things will become much more clear when I have some basic structure in place, so the first thing I&#8217;ll do is write myself a small prototype, and extend that over and over until I have the features I want.</p>
<p>Because I work with a framework (symfony in this case), I have the added advantage of being able to install plugins and configure a lot. Things such as authentication are all caught with the sfGuard plugin, and then adding the correct authorization is a matter of editing a configuration file telling which modules can be accessed with which credentials.</p>
<p>so aside from writing OO code, doing it with a framework will speed up development and re-usability even more.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
