Suggestion for Konquerer developers and delivering "stripped" releases

[Kimberly Lazarski]

I normally lurk here but I just had to toss in my $.02

On Thu, 2006-11-09 at 18:34 -0800, Michael S. Mikowski wrote:
> Hey Phillip:
> 
> I for one am sick of your arrogant self promotion here.  You /can't/ write 
> programs that do not crash, because you /can't/ control your execution 
> environment. 

Perhaps you cannot control device drivers and such, but  you CAN control
your project and enforce dependencies, and  include exception handling.
Of course with extensions/plugins (not to mention forks of your project
in various distributions) third parties can introduce defects, but
obviously no reasonable person would blame the original developer for
those (unless the problem is architectural like some other products I
won't mention here, suffice it to say it starts with a "W")

> Unless, of course, you are working on programs with lower 
> complexity and far less distribution than KDE.

Even in a complex project with millions of lines of code, a good clean
architecture and thorough unit testing followed by at least minimal
black box integration testing goes a long way toward ensuring stability.

> 
> I can't believe anyone in this century designs /any/ program with paper.  

You haven't worked with a lot of developers then. The very best
architects I know sketch GUIs and flowcharts on paper in meetings with
UI designers and other developers, mocks up the GUI in VB or even Paint
for review of the workflow, then start coding.  Of course that has been
for enterprise apps and commercial products.

> That's like using drafting boards instead of CAD for mechanical design (I 
> used to design cars with CAD.  They never crashed.  At least, not when driven 
> in unknown environments :).  


> 
> If you are using paper for design, you are wasting your time and your 
> employer's money. 

It's far easier to fix architectural flaws and usability issues before
you have written hundreds of thousands of lines of code. It's far, FAR
cheaper to spend a lot of time architecting and designing and flushing
out functionality and workflow with sketches and flowcharts than it is
to throw code away and reimplement.  Some PHBs might kick and scream
because they measure productivity based on lines of code written (I've
read that OS/2 development process was rife with this kind of thought)
but mature experienced project managers will value design and planning,
and will understand that with a commercial product, having a sound
design and stable, usable product up front will be far cheaper and far
more profitable than firefighting and issuing "spin" in press releases
after releasing a buggy, rushed-to-market product.

>  Worse, you are compromising the quality, features, and 
> timeliness of your products.  Try some UML modeling or design charting tools 
> that can live with the project.

UML should come after hashing out the most basic GUI and architectural
concepts, which is where sketches and meetings come into play. Phillip
may be young but he does show wisdom, unlike some other people who show
arrogance toward others with a different view.

> 
> Get some humility.  Lose some narcissism and arrogance.

The same could be said for some folks who flamed him here. 

>   Learn to use some 
> modern design tools.  And, finally, please be constructive. 


>  KDE does need 
> good feedback on its projects and intelligent bug reports.
> 

A user coming here

> Otherwise, STFU.

You ask for good feedback, you got it, and now you're telling the user
to STFU? Who is the arrogant one here? This is EXACTLY the kind of thing
that keeps open source out of corporate environments, and keeps open
source out of the home market.  Why are you involved in the project if
all you are going to do is tell the user to "shut the fuck up?"  Why
don't you just ask for more detail in the defect report/feature
request/feedback, or if you can't be bothered, just quit? I've seen
developers with your attitude in the industry, and they tend to not last
long because the rest of the development organization tends to hate
them. They can't take suggestions, criticism, feedback, and invariably
will do what they want to do regardless of logic or team consensus.
There are times to buck the trends, but it should be done amicably, with
respect and tact.

To the rest of the KDE team: THANK YOU for all of your hard work. IMHO,
KDE is the best desktop environment around, even with whatever
shortcomings it may have. Please keep up the good work, and _please_
receive feedback from users with grace.

/me goes back to lurk mode

Kind Regards,

Kimberly Lazarski


> 
> Cheers,
> 
> Mike
> 
> On Thursday 09 November 2006 13:36, Philipp Hülsdunk wrote:
> > on a paper first; It will created many advantages:
> > * On paper you are not thinking on programming-language specific things.
> > This causes you to concentrate more on the programm instead of the
> > programming-language.
> > * On paper you can overview your concept better. In the source code it is
> > more difficult.
> > If I write software I do this, My programms then do not crash.
> >
> > Another suggestion is that you should comment your code better so that
> > other developers can understand the code better.
> 
-- 
Kimberly Lazarski
www.biyntech.com
(781) 826-2601 x1002