Development and Concern for the Present

Jettison everything else, then, and lay hold of these things only, few as they are: and remember withal that it is only this present, a moment of time, that a man lives: all the rest either has been or may never be.

These words came from Marcus Aurelius, a roman emperor and among other things a philosopher. This thought was actually a part of a larger idea found throughout his writings in that a person’s life can only be measured in the present as in his mind it is the only thing that can truly be taken away from someone. The past is done and the future isn’t guaranteed.

Great, so what the hell does that have to do with programming? Truth is, it has a lot to do with it.

When it comes to programming, certain people… not going to name any one (Me)… tend to get overwhelmed playing the prediction game. It’s not good enough to see what I’m doing now, but I’m always planning about 8 steps ahead. Problem is, it sounds like a good idea but in reality can create over engineering and paralysis.

What if in the future it needs to be web service based?

What if in the future a user will need multiple addresses?

The question I should be asking is: Will all this What Ifing help anything get done now or will it just make the system overly complex for no good reason? Am I really smart enough to predict where the system will go in the future?

The customer, like the future, is a fickle thing. You can’t predict where a customer might be two months from now. What you do know is where the customer is right now. Just like Marcus wrote “all the rest either has been or may never be.” You can put in 20 extra hours a week creating a massively robust and fluid front end web design only to have the customer decide a year down the road that it needs to be a standalone app. This is something that cannot be predicted. It is the way of the unknown. You can only do best by what you know now.

Are there ways to protect yourself? Sure. Things like abstraction and decoupling can help at least make the change be less painful and overall are good practices anyhow. Things like ORMs can help against database changes (You know when sql server is just “SURPRISE” replaced with oracle), service oriented architecture to hide the underlying data processing, repository pattern, ect ect ect. There are many tools out there to help make it easier when a large chuck of a project is called to change heavily or to be completely redone.

Fact is, things will change and you can’t predict them. The best you can do is create architecture that allows for change rather than creating one that assumes what those changes will be. Live in the now, let the future come as it does. For every step in the future you try to predict, another assumption is laid upon a foundation of assumptions. If any one of those turns out to be false, the whole thing will come crashing down. Don’t spend a lot of time on creating things you can’t prove will ever be needed since in the end you have to get something out at some point. In the real world a working program now is better that a crazy advanced magic one that still isn’t out.

The Abin Sur Principle

The end of one great story can spark the beginning of another.

In the DC Comic Green Lantern, Hal Jordan acquires the source of his powers, the power ring, upon the death of Abin Sur. I find this to be one of the more fascinating stories in comic books as it conveys a lesson in life.

Too often in life, and even more so in the IT industry, we are forced to see the end of something: A respected colleague leaving, moving to another position, or sometimes being fired unjustly. Any one of these could seem like a bad thing and I think we as human automatically assume the worse. It’s almost instinctual to assume the worst and work against whomever fills that spot (Whether consciously or not). After all, the loss is great and there’s no way said person could be replaced. Problem is: It’s hard to predict what will happen when the new person arrives.

Sure we have all had that shock of the new person coming in and shaking things up. Abrupt change can cause extreme friction, an unknown, and the unknown is something we as IT people hate. Our job entails building things. It’s difficult to build things without a plan and a set vision. It upsets us to be in a situation of flux. We want stability. For someone to leave is to remove our livelihood. Then the panic comes.

It won’t work. This person doesn’t know what’s going on. This company will never let this happen. These are all things we’ve said in this situation. Maybe it’s because we believe we know the company better than anyone (sometimes that’s true) or maybe it’s because the new idea are contrary to what we think is the way of doing things. Problem is by doing this we’ve proven ourselves to be fools. Why? The one thing about uncertainty is… well it’s uncertain. You can’t know if the change will be good or bad. By taking a stance either way, you’ve falling into the world of assumption… arrogant assumption. No one can predict what will happen, not even you.

Cure? Just keep doing and see where it goes. It’s a hell of a lot less stressful than worrying about it the whole way and you’re still getting paid the same. Try to see the vision of the new person. Try to figure out what he/she is thinking in the long run. You might like what you see once you give it a chance.

Just a final note:

Evolution is full of this principle. The end of the Dinosaurs allowed small mammals to finally come out from the holes in the ground and take their place in history. End of one amazing story and the beginning of another.

Just Use Html: Why MVC Can Be A Good Thing

Just a fair warning, this isn’t intended on being taken as truth, but if you’ve been here before you should already know that.  If you haven’t and you can’t figure that out from the url alone, you’re probably are confused by addition so oh well.

So something has come up in days of yore, and it involves HTML.  Now I understand that those four simple letters are enough to give most programmers a rash unseen since being a kid of wearing Wranglers without washing them first.  Seems to me that there is an utter fear of HTML in the programming field and I can understand.  Sure there were times a log time ago when it was simple and people didn’t have to put up with this CSS thing.  Then design got complicated with that now defunct term DHTML.  All of a sudden, HTML design became a tool of the lesser and programmers wanted nothing to do with it.  To complicate matters, things like ASP.Net Webforms made it even more painful to worry about design. and really has so many ways to ignore it because of the 8 million automatic controls.   End result:  The ability to work with and create worthwhile pages became a lost art.

Flash forward to MVC.  To me one of the greatest things about the MVC framework was that it forced me to once again become one with HTML, and to the same extent CSS.  I’ll admit it was painful at first.  I had been able to get away without really having a good understanding of either for so long thanks to WebForms, but no way would this last.  Eventually I started to get pretty comfortable with it and have to admit I’m a far better programmer overall because of it.  How did I pull this off?  97% of the time I don’t use HTML.Helpers and other HTML churning methods.

Now I get that it sounds alien to most people.  After all, things like HTML.EditorFOr coupled with annotations can help with quickly creating pages.  I won’t argue that.  In fact, from a programmer’s stand point it’s probably better and I’m just a minority.  But I’m ok with that.  Why?  Because I like HTML.  I like CSS.  I like seeing both when I open a page in Visual Studios.  What I don’t like is the abomination that HTML helpers and the like create.  I didn’t go to MVC just so I could have even less HTML than I did in WebForms.  In fact, if I didn’t like HTML so much I would have just stayed with WebForms.  When it comes to quick development, WebForms wins hands down.  The switch to MVC wasn’t about speed, it was about doing it right for a change.  It was about getting my hands dirty and really learning web design and javascript.  It was about learning, not about taking the easy route once again. What have I gained from it? I can mock the s–t out of a page with notepad in the time it takes a kid to go through bubble wrap. Yeah, that fast.

I might get blasted for this, but personally a lot “MVC Magic” is just a way for people who are afraid of HTML to feel more comfortable.  That something like:

<% HTML.BeginForm(...) %>

Feels more safe than:

<form id="....  >

And why wouldn’t it? WebForms allowed a much more programmer friendly approach to creating pages, so it makes sense that something like the first example would be championed by programmers. Problem is, it just keeps feeding the issue: programmers don’t know jack about designing web sites.

There is nothing wrong with HTML and CSS. It’s not a difficult concept. Instead of using tools to get around dealing with them, embrace them. Don’t take the easy way out. Don’t get scared and run. Just use them. In fact, here’s an exercise:

Come up with a simple site idea like say a forum and build it completely in HTML, CSS, and Javascript (jQuery, Mootools, ect are still javascript). 100% mock up. If you find that hard or annoying, stuff it and keep going. I swear that the benefits will be astounding.

I’ll give plus points if the page has a possibility to make a lot of money… no reason for that at all…

What I Hate About Programming

Lately I have been screwing around with creating a blog framework using MVC and jQuery, the former being more troublesome from a design stand point. For example, The use of controllers and actions can cause a great deal of second guessing. Do I put all the admin view attached actions, like one for viewing a list of posts to select and edit, on an Admin controller? Do I have a Post Admin Controller and a Comment Admin Controller? Should anything having to do with Posts be on one Post controller and just seperate the actions based on attributes? (As in MustBeAdminAttribute as opposed to MustBeLoggedIn) After all controllers are about grouping things, but how the h— should they be grouped? Of course, that’s a sort of gray area an subject to debate. The problem is I can’t help but think not matter what, I’m making the wrong choice. Why? Mostly because I know I’m not a super programmer.

Now this isn’t going to be an Atwood, back patting, I’m so good I know I’m bad kind of post but something has really occurred to me more and more lately. As I’ve gone deeper and deeper into things like Entity Framework, MVC, and jQuery I’ve only been left with the feeling that someone else, somewhere is doing this a lot better. Maybe it’s because my lack of experience with them, maybe it’s just a self depreciating nature thing, but it’s also having access to too many good programmers due to the plethora of them on the internets. Yeah right, that’s a bad thing? Well it kind of is. It’s tough doing anything anymore when you know there are people far better than you doing a far better job. And with the advancement of information sharing, you can’t help but find proof of that. With that comes a certain guilt that you aren’t the top of the food chain and in fact you just might be a programmer the other better people complain about. That’s right, you. Someone at this very moment is straight up banging his/her head against a desk because of something you wrote.

Some would suggest this is the sign of a good programmer. Someone who is never completely happy with his/her performance. F— that, it just plain sucks and makes what can be enjoyable an epic pain in the a–. No one wants to be that guy, you know the one that names every variable with numbers (v1 + v2 = v3) or has one gigantic method that does everything. Problem is, this is all relative. One person’s perfection is another guy’s multi purpose stored procedure that runs 10 different query using a switch and a passed in string. Code perfection is in the eye of the beholder. And by now we all know there are plenty of high end beholders.

What does that mean? You can never win at the game of programming. Read it again. You can never win at the game of programming. That is unless you are beyond a doubt the sharpest bulb in the bunch. For the rest of us chumps, it’s grin and bear it time.

That’s it. That’s the answer. Suck it up. Don’t like that answer? Refer back to the answer. Fact is, you’ll never be perfect and if you were, chances are you wouldn’t be reading this nonsense. You’d be out in the middle of the Gulf of Mexico kicking it back on some island you own. For the rest of us mortals (Or dumb immortals), it’s time to join the Tool Fiesta. Start dancing, drinking, and accepting. I’m not saying that you can’t better yourself. Hell maybe you’ll be one of the top people out there… and optimistically thinking, considering this site, maybe you are (What the hell are you doing here though?). But you aren’t going to be perfect and neither is your code. However, sitting around and worrying about producing perfect code is just sitting around. Have to figure some code is better than no code at all right? Just lie to me.

Did Postback ruin the “web”?

If you’ve been reading my drivel as of late, you’ll know that I have moved full steam ahead with MVC, for better or for worse, ’till death do us part… or until MVC catches me shacking up with a much younger framework and sues me for everything I own. Either outcome, I going with it for a while. Why? Well I could name a couple reasons but the main thing I just like how easy it is to use jQuery with it do to how “RESTful” is it. Silly, I know.

Well I have put out some things about certain catches with MVC and it started to make me wonder about why I’m having so much trouble with certain aspects of the framework. It isn’t the modularity. I really like the controller concept. It isn’t the attributes instead of base pages to take on certain repeated checks (Say if the user is logged in), it fact I’ve embraced them. No the problem lies in the last few years of my short but uneventful programming career.

In the beginning there was ASP

I’ve admitted before, or at least I think I have, that I’ve only been doing this for about 7 years. I wasn’t the kid that started programming on an Apple II (E, C, GS, you can take your pick. Had them all growing up), I didn’t find programming those mini computers (You know the ones that basically had a strip of plastic that served as a monitor) all that much fun, and I surely didn’t sit around in my youth trying to hack into anything put in front of me. I just wasn’t that guy. In fact I didn’t start programming until around 2000 or so, the hey day of ASP. Now at that point in time, what a page could do was pretty limited. You could show tables, you could click links, you could post data to save. It wasn’t pretty but it got the job done. For the most part, web programming was just a step up from kiddie scripting and a small step down from VB Weenies. Fact was, it wasn’t very complex and site design reflected this. Sure there were a few that could push the limits, but the limits were pretty low.

You can cut a tin can with it.

ASP.Net… or at the time “.Net”. .Net was this almost mythical name that seemed to be used for everything from solving the complex page dilemma to removing that nasty “cranberry” stain from your expensive sheets that you can only buy in Sante Fe. At first people were sceptical, and why not be? Microsoft was pushing it as the universal key and at the time that seemed pretty impossible. Then people started using it. Sure it was messy at first. A lot of the people from the ASP walk of life either had forgotten how to program in forms or just never really learned. (Yours truly) Now all of a sudden there was a separation of mark up and code, and some crazy thing called post back, and wow what the hell are events? Classes? Double You Tee Eff? It was like this wave of excitement that web programming had grown up and it was the real deal. And it didn’t stop there.

Give a man an inch…

Well it didn’t take long for the over ambitious (IE Sales people) to start pushing the envelope of what could be done. Every time we reached what we thought to be a summit, someone would see if we could climb the next mountain… that happened to be twice as tall. After all it should be safe to assume that if you can make it up 10k feet, then 20k shouldn’t be that much harder right? All of a sudden “Can you do this?” had turned into “What I want is this” and for the most part it was possible. (Though ugly at first)

I want a page with data that I can edit.
-We can do that.

But I don’t want to be taken to another page
-We con do that

And I want it update when I save something without leaving the page
-We can do that

And I want it to seamlessly incorporate a bunch of different information from a million places and have it handle each part of the page differently but also have it handle all of this without leaving the page… and I want it done in two weeks.
-We can do that.

Of course this incredible feeling didn’t really allow us to think about the cost of all of this. Things like Viewstate, Session, gigantic pages with a bountiful of html, inability for smart phones to browse or at least load quickly, ect ect ect. It didn’t matter, because we were able to give the customer what the customer wanted: A Winforms program without the installation process. And over time, this has allowed pages to be so complex in structure that it you really couldn’t tell it was a web site if it weren’t for the browser.

Just because we can do a thing doesn’t mean we must… do that thing.

WebForms, as the cool kids cal them now, opened up a whole can of worms. They made it easy to create incredible complex pages with relative ease. And to do so they bent the “rules” of the web to allow for greater ease of development, at least that’s what you hear from MVC proponents (And REST people). MVC brings us back to the time when programming didn’t pervert the system, and at it’s core it isn’t pretty. Taken just as is, with the tools that the MVC framework has, the complex Web Forms we grew accustomed to are just not possible without a ridiculous amount of work. Heck a simple button press becomes much more complex in order to mimic a Web Forms post back. And that’s the problem… I’m trying to emulate something that MVC wasn’t built for and in a way could be argued that the web wasn’t built for: The post back. The Post Back is one of the key parts of Web Forms that allowed for so much and it really isn’t in MVC. I mean it could be. You could load up all the page/view functionality onto one gigantic controller but that kind of breaks one of the strengths of MVC: Modularity. Fact is, that little guy helped shape the way we think of site design and programming. (Not to mention viewstate but whatever) It allowed for so much to be done with so little effort. It gave us a bridge to winforms. For right or wrong, it gave us a solution and it also reprogrammed our future ideas.

Who has time for principal?

When conversing with other people about MVC, I had stated the whole “It’s the way the web was intended” line (Which personally I really don’t subscribe to because in a way I don’t care) and someone rebuked, “If it gets people what they want, then who’s to say what’s right for the web?” And I have to agree with him on that. I mean, it’s not like there’s life on the line here. If I move to MVC purity there will still be hunger, still be war, still be movies made by those idiots that brought you films like “Meet the Spartans” and “Disaster Movie”. (Although if Microsoft could solve that problem with MVC, I don’t think we’d have Web Forms anymore. Get on it Microsoft…) In the end, isn’t that what matters? Getting things done?

The beat marches on

So where do I go from here? If anything, I think the 800 gorilla is that I have to start designing web sites in a new way. Have to unlearn all of the things I got from WebForms and take myself back to the day when things were more simple. Even with advances with Asynchronous Calls, I still have to develop a completely different state of mind. Is this a bad thing? Time will tell. It’s possible that this is a fool’s errand but it’s also possible that use of MVC will bring forth sites with better structure and more reasonable functionality. After all it’s possible that post back derailed good site design.

Let it be noted

Before the comments about [Insert Javascript Library] start to pile in… HAHA comments on this site… Ok let’s pretend I get comments and the would be comments about [Insert Javascript Library]/Asynchronous calls(Let’s just call it JLA for short) calls, right or wrong I see JLA as a work around. It’s a way to allow for the complexity of said Web Forms without changing the MVC framework or relying postbacks. But even with those you still have a lot of unfun code that barely makes up for the loss.

Modern Programming: Anti-Evolution?

For a moment let’s just not bother arguing the merits of evolution versus whatever, and look at one of the basic ideas behind it.

Every one’s heard the cliche phrase of “the strong will survive”. Most likely it’s been in some movie you watched, some coach spouted it out, maybe you hear it from some business “guru”. Doesn’t matter. (Although there is actually a lot more since it’s not the just being strong but the best suited for the current environment ect, but let’s just play Sesame Street evolution.) Let’s go by the overall idea that those that have traits that are against survival will be removed… ie the weak.

The best code I’ve ever written was someone else’s.

Whenever you do something new, you run into problems mostly due to lack of knowledge. In the programming world, this is an everyday occurence provided you’re actually trying to learn. Can’t figure out how to make something work? Well just go search for it. No matter how new something is, most likely there are already people answering questions about it on a forum, posting it on a blog, or probably some site that is dedicated to it (Say like MSDN) that will give you an idea of what to do. That’s the beauty of programming today. But what about 20-30 years ago? What happened when you just plain didn’t have instant answers or dare I say it? No Stackoverflow. Well some people would be just fine. Those people would just plow through and figure it all out. They would go through whatever written specs there are on… paper… and get it done. They are the people who already have posts about it in their blogs now days before you even asked about it. These are the real programmers. Problem is, for every one of those there are probably 10 people who take what they have and run with it. Then for everyone of those there are 10 who barely understand it, just copy/paste, and post it somewhere. And for every one of those, there are ten that take that code and use it. And guess what? Most likely all those people still have a job. All of them.

The herd isn’t thinning

The question now is: How bad is this? Basically with the wealth of information out there, even the worst of programmers can keep a job that no way in hell they would have held 20-30 years ago. (How can I guess that? Because even 7 years ago when I first started really programming it was difficult to find things and that was with search engines.) With the demand for programmers being so high in so many places, businesses are almost forced to take on people who have just barely (Due to said search engines/copy and paste) made it because hey at least the person has prior work, so he/she must be good right? So the cycle continues, but in the long run most likely it continues in a direction contrary to evolution. Because remember, by my completely accurate and undebatable numbers, there are 1000 bad to every excellent. By that idea, and since the bad aren’t being removed, the amount of bad code out there is growing at an incredible rate and it’s being learned by new people. People who may not be bad but will be eventually due to the amount of horrible stuff out there. The bad are breeding bad, and it isn’t being stopped. At some slippery sloped point you have to wonder if there will only be mostly bad to learn from.

Those that are most capable of surviving in the present conditions will be chosen

So the whole “only the strong will survive” isn’t exactly the whole story. It’s not just strong but whoever is best suited for the environment. When we think of strong, we think most rugged, toughest, most able to surive encounters. However, in the evolutionary sense this isn’t true. If it were, all dinosaurs would have been like this almost mythical bad boy. Problem is things like food availabilty, ability to avoid predators, hell even resistance to sun exposure can all factor into what is really “strong”. The point is, those who are chosen are best for the environment they live in. Now lets take the 1000 bad coders to every 1 excellent one. With that in mind, most environments entered into are going to be suitable to which group? The bad ones. A lot of us have seen this. Started work at a company that the code was just dreadful but the 3 guys that have been there for years and the one dude that was hired in a week before you are all happy as a pig in… well anything. We try to change things. We try to move things forward, but in the end we get burned out and leave. Guess who replaces you? The guy who works well with the other four. In fact, this is another part of evolution is that if two groups of the same animal are split by something, say a new river, the two might in fact eventually become incompatible. Think about it, a company that has strong programmers and weak ones that becomes taken over by the weak will eventually spawn a whole new type of programmer and programming shop that it completely alien to a decent programmer and would allow itself to continue unstopped. At some point, slipery slope full on, there may end up being way more bad companies then good and the good programmers may get weeded out.

How do I know if I’m the strong?

Fact is, you probably can’t. Some people know it because they work for high end companies like Google and Microsoft. The rest of us mortals don’t. I think that is why this career has frustrated me at times actually. I can’t really be proud of what I’ve done because I’ve never been fired for bad code. I’ve never been released for writing bad programs. Hell I’ve never even been pulled into an office. You would think that means I’m doing something right except I’ve never known anyone who has. And I’ve had about 8 jobs over 7 years(All due to contract work or companies going under… Let me tell you, I’ve was on a streak of joining failing companies for a while), so I have my feel for bad code and bad coders. None of them were fired or let go because of bad code. And companies keep hiring in bad people so I’d have to believe that even if someone was let go, that person would find another job eventually. Hell, go to somewhere like Chicago, and you practically have to shoot someone to get fired because companies need people so badly.

Better than being dead.

So maybe its a good thing. Since after all I still have a job, I still get paid well, I still have some security. But in the long run, is this a good thing? Can programming as a whole grow as this situation continues? Everyday it gets easier and easier to be a programmer. I can’t imagine that’s going to change. With tools like jQuery, StackOverflow, Google, and any other way to help people with kid’s gloves, it’s hard to think that things are going in the right direction.

Last note

While writing this I couldn’t help but realize that this my be riddled with hypocrisy. After all, how do I know if I’m not one of the bad people? Sad thing is I don’t.

What about you?