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