Tag Archives: MVC

Outsmarting yourself. The dangers of techie dogma.

Some recent events have led me to reconsider my early programming days. Only a few years in but with thousands of hours and 10s of thousands of lines of code under my belt I was beginning to feel pretty confident. I had a very lucrative gig and after a few rounds of layoffs my team was efficient and savvy. This was the late 90s mind you, and during that time J2EE had bubbled up as an industry standard. We were a creative bunch and after some strategic pruning we were finally producing pretty robust solutions. I had personally discovered Java reflection and was having a blast exploring the possibilities. When I declared in a team meeting that all of our web forms could “build themselves” it took about 30 minutes to dispel the skepticism and decide on a course of action. Remember, this was the 90s, forms must be statically and manually coded in HTML. The word “dynamic” was only just getting the attention it deserved.

It worked like a charm. Java is a strictly typed language, and every data type has a logical form control equivalent. Boolean could be a checkbox, strings a text field. We could even inspect the property max size and constrain the form field accordingly! Again, I must remind you that this was the 90s, nowadays this is a no brainer. Back then it was “pie in the sky”.

Our team got a lot of attention even before our modules were going live. I personally got to demo the usage pattern and experienced (or imagined) a collective wow from the group. It’s pretty amazing to change a data-type and see the input control change immediately on the form to accommodate it without any extra code and virtually no static HTML!

As you might imagine things were going to take a turn, and in this case the turn came when the team lead from a different group rejected our request that he provide getters (the J2EE convention for a method that retrieves the value of an internal property/variable) for all of his object properties. His claim? He could only provide getters for non-boolean data types as the standard convention was to use “is” for booleans. I thought it would be simple, satisfy the convention but also provide a getter so that we could accurately inspect the object. No dice. The discussion went all the way up to executive (and non-technical) staff where this guy referred to me and my team as “hacks” for wanting to violate the sacred convention.

Now’s a good time for a break from the techno-babble. I like to drive as fast as I can while still being safe and not damaging my vehicle. I’m sure I’m not the only one. Yet each person has their own interpretation of what exactly is “safe”. Conventions are great, in that they help us to make fairly predictable decisions. Now some people may call speed limits a “rule” and in a certain context they’d be correct. Yet, technically speaking a speed limit is not a “rule” it is more like a convention. If it were a “rule” in a programming sense then roads simply could not support speeds higher than the limit. Cars would never be capable of exceeding the limit. They wouldn’t break, they just couldn’t do it. Yet, as a convention, the possibility exists for stretching it and bending it. Every-so-often a cop comes along and writes you up because your notion didn’t match his. He wins, cause he’s the cop. Yet in programming world, when two equal team leads from different teams clash, the only cops are non-technical management. Back to the story…

The case was run almost like a jury trial. We both brought witnesses from our different teams and laid out the evidence. Long story short, I lost. The phrase “non-standard” being parroted in nearly every sentence coming from their side and at one point the claim was even made that aliasing the functions would break existing deployments. That of course was a blatant lie. Extending an object’s capabilities by adding a method alias really has no such potential. In fact in counter arguments I referred to these supposed bugs as “regression” only to be met with a spew of criticism that the term should be “ripple effect” not “regression”… Things were really getting ugly. So I bailed. Good thing too, the whole project dissolved in a matter of weeks.

Nowadays “convention over configuration” attempts to remove the developer’s brain from the equation by pre-deciding as many things as possible as a matter of convention. Ironically the same brain must then be used to remember all of the said conventions. The fact is, conventions are good. When firmly applied they work wonders at keeping code consistent. When applied strictly they become as impractical as a cop pulling over an ambulance carrying a cardiac arrest victim for speeding.

In training and teaching I’ve always tried to emphasize the need to think for ourselves. Freezing like a deer in the headlights whenever the speedometer hits 56 mph is not just bad, it’s dangerous! I won’t be so dogmatic as to reject all conventions, standards, acronyms, and whatever else someone decides to brand and market. I just warn you, don’t be so dogmatic as to reject thought. It is a necessary component of a successful project.

What’s so good about PHP?

I’m biased, PHP is fantastic. It has evolved into a super-power among programming languages. I liked Java, I deplored VB, C# is OK (copy of Java), Ruby-on-Rails is really more 4G, but PHP is just a flat out a git-r-done scripting language. Here are some of my reasons:

1. Super fast! Considering it is an interpreted language PHP flies. Even with gigantic script libraries included.

2. No DLL hell. So many people think that DLL hell was only a problem with Microsoft products but anyone being honest will have found DEPENDENCY hell to be exactly the same thing. Watch a whole building full of developers try to get their Rails versions synced with their libraries just to get one widget to work and launch the initial skeleton app. That’s just as bad as DLL hell. .NET versions, same problem. Even JAVA app dependencies can get wonky but PHP’s extensions folder is cake to manage (and they use DLLs!). In fact, for one client we have faithfully upgraded their PHP build with every point release manually and the code almost always works, and when it doesn’t it’s graceful and minor.

3. Loosely typed. This can be a train wreck for junior programmers but seasoned veterans who have delved beyond the 4th generation to make their own products and not just assemble a bunch of other people’s work will know when type matters and when it doesn’t. As it turns out, it VERY OFTEN doesn’t. Making strongly typed languages a real PITA.

4. The Frankenstein factor. All platforms have tempted developers to package bits of functionality into modules for reuse all over the place, even PHP. However, the PHP community began with nuts-and-bolts coders and the modules that come from that community are very large and specific. The small modules of functionality are incredibly mature and compiled into extensions. In other environments, especially the 4GLish of them, the “brilliant” idea was to make tiny modules for this or that. Mix that with some starry eyed kids and you don’t get apps, you get Frankenstein. And more dependencies to create the #2 mess mentioned above. The claim is that these modules speed up the development process, but I have yet to see that happen.

5. Environment. PHP sites by nature have everything necessary for a programmer to step in and modify. No project files, expensive IDEs, gigantic downloads, compilations, or gems to get just right. Even your environment variables can probably be left alone. Simpler is better.

6. Philosophy. The modern MVC philosophy of convention over configuration is an attempt to protect the world from bad programmers, but good programmers do this naturally. MVC is a good idea, and a decent pseudo-standard to code to, but it’s just that, a pseudo-standard. I’ve dug through other people’s models, views, and controllers in different languages and one thing that is certain. Everyone does their own version. In PHP we can implement MVC, and get it just as right (or wrong depending on who you’re talking to) as any other language.

7. The community. The PHP community is cool. Sure, being arguably (Java still holds the top spot, but it is not as web targeted) the the most popular web language out there means all kinds are posting their thoughts but there is a core group of geniuses on the main groups. Helpful folks, and there are code snippets posted to do just about anything. Easily modifiable for our own needs without any of the “hell” from #2 above.

I could keep going but that being said my bias is clear. Perhaps next week I should post an article like “What’s so good about Rails?” I could do it, just don’t know if I could make it to 7 points.