In the 10 or so years I have been a programmer I have run into a lot of “frameworks” in which to build an application. I’m relatively certain I even tried to write my own at one point or another. And, lets just be honest here, they suck.
Here’s why:
Programmer Jack decides he’s going to write the Awesome Sweet Cool App 2.0. He’s making a 2.0 because the stupid, awful programmer before him (because you know the guy before you always sucks) wrote this thing. It’s a pain in the ass to maintain, it’s was written using AwesomeLanguage 2.4 and AwesomeLanguage 4.6.91 b1459 is out now. Either way, it’s a “complete train wreck” and Jack needs something scalable, future-proof, and maintainable. Jack toils endlessly writing a custom page handler, image handler, a form processor that will take his XML/XSL templates and convert them to XHTML forms and on submission they are sent to a custom form processor which uses a factory pattern to choose the right object to return that handles the form automatically. All of the controls are automatically wired together so that the buttons bind to common events at runtime, and the application “just works”. FRICKIN’ AWESOME! Jack is a superstar, he beats the bad guys, he rescues the princess, and walks off into the sunset.
… until the boss asks Jack to put up a form that uses RESTful web services from another site, and based on user input, grabs data in a non-standard format and generates a .png based chart for the C-levels to ogle in a board meeting. Oh and there’s that PHP form that needs to go in the iframe so we can show today’s industry news, but “the framework” can’t have multiple form tags, and, well, the template itself has the main form tag that relates to a custom body id so that the preprocessor knows what content to load and how to handle the submission of data…
Uh oh.
I know you’re shuddering right now, because every one of you, like me, is Jack, or has been Jack at some point.
See, Jack developed exactly what he needed to. He solved all of the problems for 95% of the cases that he’d dealt with to that point. But now that Awesome Sweet Cool App 2.0 is out, the bosses want more from it. They invested, and they want their return. Jack, like the rest of us, isn’t psychic, and could have never forseen that he’d need to do something like this. The application isn’t made to work that way, the framework doesn’t really support a form like that because the custom data handler is using some blah, blah, blah.
I’ve learned in the past few years, that unless you’re going to write an app that is not going to require upgrading and extending like maybe a one-time-release game(which excludes pretty much every web application and page I’ve ever written), you better as hell build it on an established and flexible foundation and not do anything too far outside the box that interferes with the way the foundation operates. If you use MVC, use it how it was intended, .NET, great, use events and inheritance and the power of the languages that you’re given. If you rewrite the way that pages are served so that the Page_Load method never fires, so that hyperlinks or javascript “doesn’t quite work unless you…” then you’ve created a beast with sharp teeth that is coming for a chunk of your ass, soon.
You may have found a way to accomplish the tasks you used to do, but you’ve just made all your new tasks take 50% longer then they should have. And I’m guessing that those old tasks… they don’t come up very often anymore.
Leave the frameworks to teams of uber-intelligent visionaries that have the time and resources to make a great product. The steaming pile of code that you and the other guy have worked on for 2 months and treated like a task that needs to be done along with all the other tasks, it’s going to suck and you’re about to make your life and the life of the programmers after you (who will inevitably hate you, no matter how good it is) a living nightmare.
Over-architecting is the devil, Bobby Boucher!
Subscribe