Chubby Nickel Audio Vlog

Composite applications are just applications made with the intent to reuse the functionality created in them to make the development of other applications faster and easier.

The implementation and stigma around the named composite methodologies (like Model View Presenter and Model View ViewModel), is that they are some new complicated methodology for application development. The sad truth is that they are an old programming methodology; it is just object oriented programming rehashed, narrowed and renamed. I assume it’s so that a person that has nothing to offer the development community can still profit from it by restating OOP in different words.

Many companies just hired “developers” and let them do whatever they wanted as long as they produced something that worked. I blame these pseudo developers as much as I blame the mental dwarfs that keep rehashing the old shit and placing it in a shiny new wrapped gift box… with sparklies. Just because most of the people hired to be developers did not follow the principles of object oriented design, does not mean that those principles did not previously exist. But these talentless unproductive mouth breathers know that they can make a pretty penny by pretending that all the problems caused by the old developers was because the shiny new box of shit that they just created didn’t exist before.

The actual ideas behind the buzzwords are older than even C++ (my favourite language), there were other languages before C++ to adopt the, “easy to maintain and reuse” philosophy of object oriented design. Just because I think it’s ridiculous to rename and old ideal and sell it as something new does not mean that I think it is a bad thing… at least not in itself. The ideas behind composite application development show one way that you can use OOD principles to make developing, maintaining, testing and deploying of applications faster and easier.

The negative effect is when these “developers” start to believe that this one way is the only way. Even when there is almost half a century of good object oriented development principles. Although making something easier and faster to maintain, develop, test and release is a good thing, its like teaching a child to ride a bike using training wheels. The kid can get up on the bike and pedal without falling over, and it can help the kid learn to eventually ride the bike without the training wheels. It’s not bad that developers start with training wheels, it’s bad when “developers” just trade one set of training wheels for another set and never free themselves from the limitations.

It seems like most U.S. businesses tend to try and organize their tree of responsibility the same way:

President, CEO, CTO, CFO and VPs are in charge of Directors, who are in charge of managers, who are in charge of team leaders, shift leaders or projects leads who are in charge of the grunts.

In several instances this is a very useful setup, like for big chain stores the resposibility setup is very clear and makes things easier. In other organizations, this setup can create a lot of high paid time wasters. For instance:

A software development firm does not need the wole chain of resposibility, you have programmers who get their tasks from their manager (or team lead or project lead), and report their status to them. The manager has enough time to manage several groups so there is no need for a manager for each project, otherwise the manager is wasting time checking on status too much, sending emails and in general dicking around or bugging the programmers. Since one manager can manage several teams, there is no need for a director, and no need for a VP of the department, those positions would equally waste time because they would have so few people to manage. The CTO is not needed because the managers can report straight to the CEO or president.

Overall, most of these positions are filled by highly paid slackers who feel they need to be doing something.  Because they feel the need to “manage” something, they spend a lot of their time making things worse for the developers… the people that do most of the work but get paid considerably less. Most of these positions can be dropped or pay the people less to save a considerable amount of money. And if you want a better product, then pay the people who are doing more actual work.  In an economy that is failing, it makes sense to drop the dead weight of most upper management to retain the producers of the companies product instead of reducing the producers and keeping the people that sit around making power point presentations.