You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Greg Reddin <gr...@fnf.com> on 2003/10/15 14:05:28 UTC

Re: OT: Simple is great . (period)

Funny, a coworker and I were discussing this very thing yesterday in the 
context of J2EE vs. .NET.  Neither of us have used .NET so we're just 
going on our perceptions.  But .NET proponents say that it is simpler 
than J2EE.  This is fine as long as you can handle being pigeon-holed 
into a *simple* way of doing things.  The beauty of J2EE (and the beast 
of J2EE) is that there is almost infinite flexibility.  But if you can 
master the complexity and reign it in then you have the best of both worlds.

To illustrate my point, I'll give a historical example.  Our group used 
to produce a huge fat client application that contained several hundred 
screens.  Way back when this effort started Visual Basic was the 
language they chose to use.  It was great for throwing together GUI 
applications really quickly.  But as the complexity of the application's 
requirements grew, and as the sheer size of the application grew, it was 
clear that VB couldn't scale.  We made it scale by developing a huge VB 
"infrastructure" to make development "easier".  At that point it 
would've been simpler to use something more complex.  Our needs would no 
longer fit into the model of the simple environment. The simple "always 
do it this way" approach was no longer working and we would've been 
better off to convert the thing to C++, IMO, where an object oriented 
pattern already existed.

My point is that you should keep it as simple as it can be.  But 
"simple" should rarely be the only factor in making architectural 
decisions.  In fact, in the discussion you were referring to, one 
person's definition of "simple" would've possibly been simple for him, 
but would've broken the design pattern and introduced complexity for 
everybody else.  You'd like to be using a tool set that makes simple 
things simple, but provides the capability to scale up complexity as needed.

I do believe in KISS, but to me it means keep it as simple as possible, 
but think ahead...

Greg

Vic Cekvenic wrote:
> 
> Someone recently posted in here “Simple is great if your needs are 
> simple” implying that KISS is not always good. I would like to disagree, 
> and point out that KISS is always good.
> 
> Teaching design is hard, and that is why it takes experience to do good 
> design. For a first few years in IT, I too was proud that I could design 
> complex things. Now (15 years of IT) I spend effort to try to simplify, 
> especially when I do project recovery.
> 
> In general, programmers  (primates?!) like me, can deal with a limited 
> maximum complexity. If the framework is complex, I can only do simple 
> projects with it. If the framework is simple, I can tackle complex 
> projects with it. (It ends up not beeing a business application 
> otherwise, just pure R&D that only works in lab conditions, and not in 
> production)
> -If it is complex, it is hard to maintain, or find a bug.
> -If it is complex, it is hard to communicate what people should be doing 
> on a large (complex) projects. KISS!
> - When learning a science, like math, they teach us “… and now we 
> simplify”. There was some TV History show, where a famous scientist 
> (forget the name) ended the letter saying: “Sorry I wrote a long letter, 
> I did not have time to simplify this”.
> - We spend time to make our code more readable.
> - We know that adding more resources to a complex project does not help 
> (“Mythical Man Month”), it only makes it more complex.
> - I think one reason open source projects are more successful, is that 
> it is done quickly by limited resource (thus limited complexity). Struts 
> was “done” by one person over a weekend for example. (Vendors have teams 
> that consider lots of requirements via a committer. I ran away from 
> those complex frameworks to things like Struts).
> 
> One approach I do teach is to design for the rule (and not for every 
> exception); and only consider 80% of what is needed (because that last 
> few % makes the design complex. Things that happen by exception can be 
> deal with as exception.
> 
> That is all I can think of now on why KISS is better than complex.
> 
> .V
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


Re: OT: Simple is great . (period)

Posted by Vic Cekvenic <ce...@basebeans.com>.
Greg Reddin wrote:

"But .NET proponents say that it is simpler
  than J2EE "
<SNIP>

I think to the extent .NET *is* simpler, we _should_ start using it. 
They could argue that there are no EJB/BluePrints/etc. complexities in 
.NET, you can just get the data, and display a grid. There are cultures 
in J2EE the _like_ complex solutions. My argument only trough KISS can 
J2EE be superiors for complex business apps.
As a software engineer, I spend time looking for lower costs to 
implement a given application, like it or not.


Victor Cekvenich,<br>
Struts Instructor<br>
(215) 312-9146<p>

Advanced <a href 
="http://basebeans.com/do/cmsPg?content=TRAINING">Struts Training</a> 
Server Side Java training with Rich UI, mentoring, designs, samples and 
project recovery in North East.
<br>
Simple best practice basic Portal,<a href ="http://basicportal.com"> a 
Struts CMS, Membership, Forums, Shopping and Credit processing, </a> 
software, ready to develop/customize; requires a db to run



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org