These forums are in read-only mode. Please see this news post for more information.

New forums can be found here


Go Back   WowAce Forums > Addon Chat > Frameworks
Frameworks Framework Discussion

Reply
 
Thread Tools
Old 02-17-2008   #11
Industrial
Amazing Member
 
Join Date: Sep 2005
Posts: 1,517
Default Re: Long Post - But I think it is topical.

Hey, I speak my mind. This is my opinion and you are welcome to not agree.

I'm not totally sure what that comment is supposed to mean, maybe that you think I'm not good enough a programmer and should go and play with the rest of the kids or something? dunno..

At least I'm able to talk about it, unlike you.

Have a nice day
Industrial is offline   Reply With Quote
Old 02-17-2008   #12
Seerah
Legendary Member
 
Seerah's Avatar
 
Join Date: May 2006
Posts: 6,724
Default Re: Long Post - But I think it is topical.

I believe sylv was referring to Puff the Magic Dragon and Little Jackie Paper. In other words, he was either wondering what you were smoking or thought you were in an imaginary land.

And it took you a month to come up with a retort to this thread? I'm disappointed.

/hug Indie
__________________
Seerah is offline   Reply With Quote
Old 02-17-2008   #13
sylvanaar
Legendary Member
 
Join Date: Nov 2006
Posts: 2,876
Default Re: Long Post - But I think it is topical.

Quote:
Originally Posted by Industrial
Hey, I speak my mind. This is my opinion and you are welcome to not agree.

I'm not totally sure what that comment is supposed to mean, maybe that you think I'm not good enough a programmer and should go and play with the rest of the kids or something? dunno..

At least I'm able to talk about it, unlike you.

Have a nice day
Seerah is right, Puff the magic dragon, and little jackie paper - ie. you live in fantasy land.

Most software has to deal with change, meet the needs of more than one person, and do this with a balance of machine (runtime) and human (development) resource usage.
__________________
sylvanaar is offline   Reply With Quote
Old 02-17-2008   #14
Bam
Hero Member
 
Join Date: May 2005
Posts: 615
Default Re: Long Post - But I think it is topical.

Quote:
Originally Posted by Industrial
This is aimed at people working in a "corporate" environment to be stimulated to work together and value each others views on the code more.
That's were I think you are particularly wrong. Large software project, small software project, solo programmer, or group programmer. In my experience there is not too much difference. Sure, very small software projects can more often get away with poor code. And huge projects may have some extreme requirements in terms of documentation and standards (ISO 98234928347 whatever.. oh god). But all software projects benefit from following pretty much the same principles.

I take a lot with me from my experience from large projects to smaller ones - even solo ones. I cut a few heals here and there. But more often than not it comes back to haunt me later.

Anyway, I wonder what exactly it is you disagree with in the article. You didn't explain that. Apart from the way it talks about the problems as a disease. I guess that's just a style the author chose. Not sure I like that style too much either though.
Bam is offline   Reply With Quote
Old 02-17-2008   #15
ellipsis
Amazing Member
 
Join Date: Sep 2008
Posts: 1,295
Default Re: Long Post - But I think it is topical.

Quote:
Originally Posted by Bam
Anyway, I wonder what exactly it is you disagree with in the article. You didn't explain that. Apart from the way it talks about the problems as a disease. I guess that's just a style the author chose. Not sure I like that style too much either though.
I think Indy was trying to say that the description of the problem as a disease results in a vague "symptom list" which could be applied to almost any piece of code, no matter how well designed/written. You might call it "code hypochondria" - for example,

Quote:
Originally Posted by sylvanaar
The symptoms of Over Simplification are:

Code that performs no useful function, either by design or through decay, and that is still present.

Complexity that has been shifted from its correct location and therefore been made more complex.
I can find several instances of each of these problems just from reading through, say, Prat's code. Does that mean Prat is suffering from over-simplification? I think not...in fact I'm fairly sure most would agree that, if anything, it has quite the opposite problem (though one could argue that's partially because of shifted complexity).

For over-simplification to be a real, solvable issue, it can't be a diagnosis which fits just as easily on any other piece of code. Vague symptom lists and obvious solutions like "prepare for areas of likely change" are not helpful to programmers. Which is not to say the post as a whole is useless - several of the points and examples given do have merit, and seem to coincide with issues that did come up in the process of designing this generation of frameworks.
ellipsis is offline   Reply With Quote
Old 02-18-2008   #16
sylvanaar
Legendary Member
 
Join Date: Nov 2006
Posts: 2,876
Default Re: Long Post - But I think it is topical.

Quote:
Originally Posted by Ellipsis
I think Indy was trying to say that the description of the problem as a disease results in a vague "symptom list" which could be applied to almost any piece of code, no matter how well designed/written. You might call it "code hypochondria" - for example,

I can find several instances of each of these problems just from reading through, say, Prat's code. Does that mean Prat is suffering from over-simplification? I think not...in fact I'm fairly sure most would agree that, if anything, it has quite the opposite problem (though one could argue that's partially because of shifted complexity).

For over-simplification to be a real, solvable issue, it can't be a diagnosis which fits just as easily on any other piece of code. Vague symptom lists and obvious solutions like "prepare for areas of likely change" are not helpful to programmers. Which is not to say the post as a whole is useless - several of the points and examples given do have merit, and seem to coincide with issues that did come up in the process of designing this generation of frameworks.

Yeah. I did mention there was a counterpoint to "Oversimplification" - "Complexification". However, like a disease, you cant diagnose some of these things with just one symptom. If I have a fever it doesnt mean I have the flu without some other symptoms as well - not everything will apply in every case that is an oversimplification Also, dont forget that you can have more than one disease at a time too just like in real life.

You read this like a rulebook when it is infact just guidelines.

As far as Prat goes - I have found that its just sorta "trendy" to critisize it and call it "bloated" - because if you don't people will think you aren't cool and "in the know" - I think even Firefox is "bloated" now... But take for a minute that you are being sincere:

Prat does have issues with oversimplification. I said early on when i joined the developers of then Prat 1, that I dont want to break up the collection, I wanted it ot be all in one addon - I had drawn a parallel to Fubar - my goal was "the fubar of chat", though i disliked having to update my fubar modules separately. That's my sacred cow. So as the number of modules grew I had to implement the AutoLOD feature to preserve my "One Addon" approach so the unused modules would not continue to use memory - though that functionality isnt all that complex ultimately its still a good example of what this is talking about.

Remember - oversimplification happens very early on (thats another symptom), has "sacred code" or "do not touch" components, exposure to previous complexity influenceing decisions, and introducing complexity to maintain the simplicity - even the unused code bit applies.

It actually says quite alot more than you read - i think you were too quick to be contrary.

__________________
sylvanaar is offline   Reply With Quote
Old 02-18-2008   #17
Bam
Hero Member
 
Join Date: May 2005
Posts: 615
Default Re: Long Post - But I think it is topical.

Well, it's a short text. More of an overview than a precise cookbook on how to spot and solve Over Simplification. I assume the rest of the book has more details. But just because it doesn't go into great details, doesn't make it invalid and doesn't mean that Over Simplification cannot be a problem.

Though I had the feeling of "recognition" while reading the text, it still brought out some new points for me. Over Complexification is hardly new to anyone. And it's probably more frequent than Over Simplification. I think the biggest "punch-line" for me was "Previous contact with Complexification is the primary cause for Over Simplification". I've certainly been there myself many times.

You are struggling with code that is just way too complex. Finally you give up and decide to rewrite it in order to make it simpler. Then when you start using the simplified code, you begin to realize that something is missing... again and again and again. But you don't want to touch this beautiful and simple code that you just wrote. So the missing parts go elsewhere. Hence, pushing complexity to other places. Sometimes it may be possible to push it "sideways" into independent modules/libraries. But very often the complexity gets push upwards into code that ought to be at a higher abstraction level. That's when you realize that the original code had reasons for being complex. Simplifying things isn't always the answer.

This is not to point fingers at anyone in particular. As I said, I've been there many times myself. And I will in the future too no doubt. One thing is for sure: It's never too late to learn new stuff.

Bam is offline   Reply With Quote
Old 02-18-2008   #18
sylvanaar
Legendary Member
 
Join Date: Nov 2006
Posts: 2,876
Default Re: Long Post - But I think it is topical.

This is the introduction to the book (Again without permission)

Quote:
What Is a Programmer Illness?
Repeatedly I see the same mistakes being made during software development. These errors hide behind slightly different masks, but at their heart, many of them are the same. I have made many of these mistakes myself, not realizing that I was repeating the same errors until well after they had been made . Even one of these mistakes can have far-reaching consequences for a software development project; making them over and over is guaranteed to cause loss of time or money.

Many projects I have worked on started out with a goal to avoid past problems. Unfortunately, the projects often fell into the familiar programming traps with all the corresponding complications associated with them. One of the major problem areas projects fall into is having to perform considerable optimization work toward the end of the project. Knowing that this was a major problem, we established a mandate to optimize this new project from the very start. Optimizations were made early and were considered to be of primary importance. There was also an emphasis on early completion of features using whatever means necessary.

However, these methods led to several of the classic mistakes made by programmers. By focusing on optimization alone, the code was made difficult to understand and hard to modify. As the project went on, changes became increasingly difficult to make, and fixes to existing code took longer. This led to cutting of features and simplification of the project?s scope. A considerable amount of extra work was also accrued due to the distrust of the performance of externally generated code, such as the C++ Standard Template Library, and higher-level language features. This further reduced the amount of new features that could be implemented, and made standard features more onerous to implement. Topping this off were the other common mistakes not related to the goal of optimization, such as cut-and-paste coding used to implement features quickly in the short term. All this meant a considerable amount of time, and hence money, spent on a small feature set.

So, was this reduction in scope worth the performance gained from this approach? Unfortunately, the desired performance improvements were not realized, resulting in the hiring of a consultant to optimize the application near the end of development. Despite the intentions and efforts of the developers, loss of time and difficulties in development were not offset by the desired performance goals. Although the project was completed, more could have been achieved in the same time, or the project could have been finished earlier. Even a successful project leaves a lot of room for improvement, and there is hope that many of the team members took away lessons from the failures in the project as well as the successes.

Over time, seeing these errors has led to the metaphor of an illness to describe these commonly repeated mistakes. This metaphor serves several purposes, most important as an aid to remembering the importance of each of these mistakes. Comparing programmer mistakes to a more common problem of human illness also allows each mistake to be discussed in a structured manner that aids in reference and recall. Programmer illnesses, just as regular human disease, can also be communicable. A new programmer is very likely to pick up these mistakes from his mentor. A programmer working on code filled with the little bugs will be less careful and might, through lack of caring or out of necessity, introduce similar bugs. These problems must be prevented or caught and cured early to reduce their impact on your project.

On a slightly less serious note, some of the terminology already in use is reminiscent of the fancy terminology used by doctors. For example, Premature Optimization and NIH Syndrome sound like some strange disease or mental condition. In a way, these actually do describe a mental condition present in many programmers. To counteract this problem, you must be disciplined in your approach to design and coding. This importance of discipline is evident in the recent success of Extreme Programming and other agile methodologies. These new methodologies suggest an approach that requires fewer but more disciplined programmers to accomplish the same tasks that a larger group of average programmers would take the same amount of time to do. In addition, nobody wants to catch a bug, be it in code or in our blood.

__________________
sylvanaar is offline   Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 10:00 AM.