Common misconceptions in web application development(techfounder.net)
techfounder.net
Common misconceptions in web application development
http://www.techfounder.net/2008/07/20/common-misconceptions-in-web-application-development/
7 コメント
While I agree in principle that #1 is correct - that OOP is not necessarily less performant than procedural languages, the argument provided is a bit of a strawman. No OOP-antagonist that I know would consider that a proper argument.
The arguments that I see are this:
1. Encapsulation makes code less performant because large, overdesigned objects are created to pass around information rather than designing the code to the data. Consider sending XML around (SOA) rather than a pointer to a struct, for example, because of proper encapsulation.
2. Inheritance tends to be poorly used in OOP, causing poor performance without gaining many rewards in maintainability except for an ideological category system. This ties into complaints about polymorphism and inversion of control systems and the words "bloated piece of shit Spring" come to mind. :)
3. OOP encourages architecture astronauts due to the ideological supports. Further, it hides poor algorithmic decisions because it separates a processing function into multiple files and functions.
The arguments that I see are this:
1. Encapsulation makes code less performant because large, overdesigned objects are created to pass around information rather than designing the code to the data. Consider sending XML around (SOA) rather than a pointer to a struct, for example, because of proper encapsulation.
2. Inheritance tends to be poorly used in OOP, causing poor performance without gaining many rewards in maintainability except for an ideological category system. This ties into complaints about polymorphism and inversion of control systems and the words "bloated piece of shit Spring" come to mind. :)
3. OOP encourages architecture astronauts due to the ideological supports. Further, it hides poor algorithmic decisions because it separates a processing function into multiple files and functions.
Excellent post! Sometimes you just gotta say those things that should go without saying.
1. OO code is less performant than procedural code
Never forget, the primary purpose of OO is to help us, not our users. OO is a great way to get junior people thinking a certain way, set standards, and make maintainability a little more manageable (usually). The only thing it really does for our users and customers is help us help them by making our lives a little easier.
2. The backend is the most important part of development
Sometimes I think we get this backward. Think about it. You can do almost anything you want on the back end and no one notices unless there's a problem. The client side is a whole different story. It has to work perfectly no matter what browser or resolution your user arrives with, and it has to do it using a limited number of technologies, a small footprint, and with limited round trips to the server. It's almost like it's 1965 all over again.
3. Graphical designers are good at user interface design
UI design != UI function. It doesn't matter how pretty it is if the user can't figure out what to do or if it doesn't function as expected.
4. The existence of a superior programming language
Yea, some languages are better than others for certain things, but a expert practitioner of a seemingly inferior technology is almost always better than an average practitioner of a superior technology. To this very day, my mother can still print faster than any of us kids can write. Amazing.
5. XML is more economic than a DB
XML serves its purpose of being autodocumenting quite well. That's all it does well. If you need to parse for any reason, almost any other format blows it away.
1. OO code is less performant than procedural code
Never forget, the primary purpose of OO is to help us, not our users. OO is a great way to get junior people thinking a certain way, set standards, and make maintainability a little more manageable (usually). The only thing it really does for our users and customers is help us help them by making our lives a little easier.
2. The backend is the most important part of development
Sometimes I think we get this backward. Think about it. You can do almost anything you want on the back end and no one notices unless there's a problem. The client side is a whole different story. It has to work perfectly no matter what browser or resolution your user arrives with, and it has to do it using a limited number of technologies, a small footprint, and with limited round trips to the server. It's almost like it's 1965 all over again.
3. Graphical designers are good at user interface design
UI design != UI function. It doesn't matter how pretty it is if the user can't figure out what to do or if it doesn't function as expected.
4. The existence of a superior programming language
Yea, some languages are better than others for certain things, but a expert practitioner of a seemingly inferior technology is almost always better than an average practitioner of a superior technology. To this very day, my mother can still print faster than any of us kids can write. Amazing.
5. XML is more economic than a DB
XML serves its purpose of being autodocumenting quite well. That's all it does well. If you need to parse for any reason, almost any other format blows it away.
"UI design != UI function"
I would say, UI design != Graphic Design. UI design is inseparable from UI function. They are one and the same. Design isn't how something looks.
It shouldn't be confused with graphic design though, which is really how something looks. Graphic design is purely in the realm of the aesthetic.
I would say, UI design != Graphic Design. UI design is inseparable from UI function. They are one and the same. Design isn't how something looks.
It shouldn't be confused with graphic design though, which is really how something looks. Graphic design is purely in the realm of the aesthetic.
"Graphic design is purely in the realm of the aesthetic."
This is not strictly true. For example, when designing for print, a good designer pays strict attention to information architecture and type readability and legibility (which are two different thing). These things are both form and function.
But then, as I think Donald Norman says, "Beautiful things work better..."
This is not strictly true. For example, when designing for print, a good designer pays strict attention to information architecture and type readability and legibility (which are two different thing). These things are both form and function.
But then, as I think Donald Norman says, "Beautiful things work better..."
Right. That's what I meant but not what I said. Thanks.
I agree, it's an excellent post.
Another caveat that relates to #2 is that a lot of people get so obsessed with the back end that they build it before they figure out what problem they're trying to solve in the first place. Without knowing what the user is going to do with the application, how can you design a back end to support it?
Another caveat that relates to #2 is that a lot of people get so obsessed with the back end that they build it before they figure out what problem they're trying to solve in the first place. Without knowing what the user is going to do with the application, how can you design a back end to support it?
#7 - Data driven web apps (who doesn't have one these days?) can do a million things (probably an understatement) but the key is to do a few things really well.
Write down the features you want (what you want your app to do) and then cut it in half - than cut it in half again - than identify the three hardest features left and cut one of those - and than you probably have a lightweight app that will get off the ground so you can work to stay off the ground.
Write down the features you want (what you want your app to do) and then cut it in half - than cut it in half again - than identify the three hardest features left and cut one of those - and than you probably have a lightweight app that will get off the ground so you can work to stay off the ground.
This site treats XML as a database. Well, it uses the s-expression (XML's slim cousin) instead, but still.
UI design != UI function - I have had to explain that way too many times. Interface Design = Interaction Design + Visual Design + Information Architecture
However I, personally, would add one more.
#6 You can't be a ninja at both front and backend
Following on from 2. if you focus on the skills to do the backend you are never going to learn or keep up to the date with all the intricacies of browsers quirks. Vice versa if you spend all your time dealing with browser quirks you may not pick the best architecture.
It's not that we aren't capable of doing either, it's more that you can't be amazing at both at once.