[FoRK] Software architecture/design/development efficiency and conciseness - terms and ideas

Stephen Williams sdw at lig.net
Mon Jan 31 16:38:17 PST 2011

On 1/31/11 3:36 PM, Koen Holtman wrote:
> ...
> Well excuse me.  If there is persistent incompetence at the project
> management level, all the competent developers will tend to leave.

Then, later bring in competent developers to rescue them...

> A lot of code complexity is caused by bad project management -- it is easy
> to give developers incentives that reward them for adding more code,
> rather than for implementing actual features or for simplifying the
> existing code base.  Also, if nobody understands the real problem to be
> solved yet, but there is pressure to start coding, it is tempting to jump
> into coding a bunch of framework stuff of questionable relevance.

Definitely have seen this.  I have a few workarounds to avoid this kind of thing.

> That being said, for developers working under good project management,
> there are some fairly old and generally accepted principles that can be
> used to avoid introducing unnecessary complexity, e.g.
> - keep it simple

But not too simple.  And, as I've pointed out, thousands of lines of code and hundreds or thousands of classes of "simple" code is 
often far more complex than the "complex" solution.
> - do not implement an interface that generalises the problem until it is
> proven that it will be needed

Right.  But anticipate those that clearly will be required.  Generalized, this is: "No premature optimizations."  Although, 
sometimes you just know that a certain architectural level method / algorithm / style is best or required for an acceptable solution.

> - make one prototype to throw away
No one authorizes this, but you can force the issue and build first versions as testing frameworks or technology demos.

> - make sure you spend enough time in the design phase before going to the
> code phase

Well, sort of.  This is mostly invalidated by Agile development, which is often very successful.  It is also invalidated by the many 
waterfall, design phase up front projects that have failed or nearly failed.  On the other hand, many Agile methods only make sense 
if there is no reason to build complex libraries, tools, etc.  Although you can apply it a level down while building those.  As long 
as there is a good architecture step, then much of design can be done incrementally.  Traditionally, the big problem was that people 
pushed for a design phase that was far too detailed.  In many cases, you don't really have a feel for where the code should go until 
you have a lot of it working.  In a sense, 100% up front design, waterfall style, is like having having beginner programmers 
designing for expert developers.  That's because at the end of the project, the developers are an expert on that project while 
before it is written, generally speaking, no one is.

> A lot of this can be found in software project management literature.
> The literature is incoherent in the sense that not everybody agrees on the
> relative importance of the different best practices, but there is a
> fairly broad consensus on some basics.

Less and less consensus on major portions, OO waterfall / UML-ish vs. (sort of) agile for instance.  (I became a ScrumMaster a while 

> Koen.


More information about the FoRK mailing list