I Hate Programming for the Web

So I have really been thinking about this for a while now. I have had the chance to work on more then one web based project. I have also had the joy of attempting to write a website for just TWO browsers (in a time when there were essentially two well known ones, IE and Mozilla). I have come to the same conclusion each time I do it, I HATE writing "applications" for the web.

State (NO, not friggin' New Jersey or Pennsylvania)

Gripe number one, the web SESSION. This little beastie is meant to turn what is normally a stateless protocol (http or https) into a stateful one. It is meant to keep track of things on behalf of the client, on the server, for the purpose of making mere html pages seem as if they are an application. This session information makes the loosely coupled html pages hang together as if they were a full blown application. Depending on your platform a programmer can store just about anything that they can dream up into the session and then call it back at whim. So you might ask - what is so wrong with the idea of storing some of this information? One - it’s a bastardization, the web was never designed to have such a construct. Some smart people made it up to solve the problem of doing more "interesting" things with web sites. Two - it can if not done correctly, completely screw up and make pointless any load balancing you may want to do to make sure your web servers can handle the load of all the people attempting to hit your site at once. Lets be blunt, if you wanted a cohesive state (engine or otherwise), why didn't you just write an actual APPLICATION?

Standards - We don't need no friggin' standards

Gripe number two - HTML/CSS. Look these things are supposed to operate the same way no matter what 'interpreter' you use to parse and present the results of the markup that is HTML. Both of these things are supposed to be standards that leave little or no room for interpretation on what it is that they are supposed to represent or what they are supposed to do when they are parsed out to make a web page. However, as any web developer will tell you, there is ambiguity in the standard that then gets interpreted by a browser programmer and as such leads to the different browsers doing different things based on the EXACT SAME markup and CSS. What a FRIGGIN' PIA. FOR REAL? What you get out of this is needing to maintain more then one CSS for the different types of browsers, or to maintain different CSS markup in the same file for similar purpose. This is all done in the name of making the ONE web page you just wrote look the same no matter which browser it is being viewed in.

Singular deploy

Gripe number three, while it is true that I get to deploy the application just once, as you can see above - I might as well have deployed the application one time for each browser type I wanted to support. My code is different essentially for each one. Granted - a lot of the logic is deployed once (i.e. the dynamic stuff I am doing behind the 'presentation' that is a web page) so I'll give anyone that one no questions asked. The other thing of interest here - will things like the Apple Application Store bring back applications on the desktop? Think about it - a super easy to use, easy to deal with installation and management mechanism that has what amounts to a micro payment to purchase in a great number of cases. VERY interesting if you could make that system work on more then just the iPhone/iPod Touch.

Security

Gripe number four. The web is a huge pain in the ass when it comes to security of what it is that you are developing. There are phishing attacks, XSS, CSRF, and god knows how many other varieties of remote type attacks. There is injection of a variety of kinds to top everything off. Add to all of this stuff that you have to defend against on the server side you also have the security vulnerabilities in the browser to contend with as they may make any of the other styles of attack that much easier. Desktop applications may have a number of the same types of problems, but at least I can count on only having to solve them in the application and not having to deal with accounting for both a browsers issues as well as problems in my own code. All this in the name of not having to deal with remote installation of code. Lets just acknowledge that installing software and managing packages has gotten a lot better then it was and consider it when new projects come around. But we don't we stick with deploying things as 'websites' because that is what EVERYONE DOES. I would still at least consider, in a closed circuit, if doing something new as a web app (i.e. internally for a company) makes the most sense before embarking down that path. Think Customer Service application and ask yourself if it makes sense to be a web application. Really?

AJAX - Flash and other ilk

SO - IN THE NAME of all this is freakin' holy, because we want things on the web to act, look and feel more like applications on the desktop WE ADD things like flash, silverlight, ajax etc. These things essentially provide a 'framework' window in which to - wait for it - WRITE AN APPLICATION! Are we all certified morons? We are all OK with this - it might as well be a java applet for cryin' out loud. All of these things break browsers in some very fundamental ways because the URL that renders the page is now a meaningless bit of fluff, the forward and back buttons which worked wonderfully when all the web was stateless are also now meaningless because they all work on the context of a page - and all the flash, ajax and silverlight items do not. Talk about ass freakin' backwards. Lets take a browser and put an APPLICATION in it rather then a web page. All these items are designed to get more control over something that was specifically designed to be so much more light weight and easy to use.

URL Shortners

Talk about compounding issues - now on top of everything else we have a class of services that shorten URLs so that emails and Twitters and other such 'social media' items don't have to deal with super extra special long urls links in text. HELLO? FOR REAL? I think Jeff Atwood put it perfectly when he pointed out that an href in html or url tag in bbcode or what have you were specifically designed to SHORTEN THE ACTUAL url so that you could use a single word as a link if you wanted. These url shortners add another level of complexity for finding things on the web, they can't be indexed, the can't easily be searched - they are not descriptive - and lets not even discuss what the hell happens when the 'site' that is doing this additional translation of short URL into the real one gets compromised. Now ALL those short urls are taking people to places that are installing malware. Awesome.

Face it - the web is a giant mess. Yet we all seem to still so enamored with it and everything must have a 'spiffy' interactive, loginable web presence. When are going to wake up and truly solve the issues of attempting to make web applications be actual APPLICATIONS? I dunno, but I do know its going to continue to be a pain in my side for a long time to come.

It is the people, stupid...

There has been a great deal of conversation in the world at large about different ways in which to perform work (i.e. processes for tracking and getting things done). There are many and varied ways in which this has been attempted - processes such as WATERFALL, SCRUM, AGILE, CMM, RATIONAL... all of which are about the same thing, attempts to make software development managable and predictable. Most of them however fail at their attempt for a variety of reasons, but I wanted to take a minute to focus in on one aspect of why they fail - The people involved.

The People

It should go without saying that process is really only a small part of how software development in any company gets done or executed. The process is in place to attempt to guide and assist when questions come up or there are issues found during development. These problems can be with the intent of a feature or sometimes even with the 'code' implementation itself. In this respect each one of the processes above meets the need - they can all provide some level of guidance for an individual or group attempting to develop software. However with the exception of the 'agile' stack a good number of them miss the point... process is not helpful in dealing with people. Real people are doing the development and real people are hard to predict for over time.

The Process

Every software project I have ever been involved with attempts in some way to be predictable in its delivery of items. Items for the project may include documentation, code or a myriad of other things but in general the 'what is delivered' only matters in so much as this discussion being about software development. Some projects focus on Dates (not these or these) the times during the project on which certain "items" within the project will be delivered. New functionality or even the entire system development might be driven by these dates. Sometimes these magic dates are called 'Milestones'. These milestones are points in the project when supposedly major portions or steps of the project will be considered done (most of the time without a clear definition of what 'DONE' is). Gantt charts, carefully laid plans, deadlines, etc. etc. etc. all put in place to suffice a process that in the end is attempting to control and make predictable the delivery of software. All are attempts to stay in control of something that in most cases by its very nature is 'out' of the control of the person doing the planning.

OK - so maybe that last statement is a little harsh. Lets be realistic though, I am sure everyone reading this blog has been on one project or another where the schedule, deadlines and all, in addition to what was 'TO BE DONE' in the given time frame was essentially dictated to them by either management or a project/program manager that was being told to essentially get 'X' thing done by 'X' date. Addmitedly the world is full of deadlines - and some deadlines are needed, but having two of three sides of a triangle dictated doesn't leave alot of room for the 'last' variable to move around alot.

But in the end we plod forward, bad news is supressed because no one wants to hear it... and then everyone ends up on a DEATH MARCH to the end of the project. Everyone gets irritated because the work they may be doing is not of the highest quality (in some cases even mediocre quality) and everyone feels dirty about not adhearing to best practices when it comes to development. There are no unit tests, the documentation is shotty - and the delivered "thing" is held together with spit and bailing wire.

MOST Processes miss the point its not about the deadlines, its about the people - and maximising what they can do to get the most delivered possible with the highest possible quality.
Agile and people - some implementors miss the point

Most processes I have worked with and in focus on variables that most people think of as being easily controlled. Things like the delivery date or the number of people working on the project. It is true that these things are easily modified and very measureable but the item that most project/program managers don't consider is what happens when you don't fiddle with those things but instead work to fully understand the work and how much of it the development team can actually accomplish CORRECTLY.

How gaining this knowledge helpful or different from what most methodologies do and tout? First, having this understanding is a very agile practice in my mind. WARNING BROAD SWEEPING STATEMENT FOLLOWS: Usually project and program managers understand what needs to be done, but they don't understand the constraints in the existing software or sometimes even the existing systems if we are discussing full life cycle systems development. This is where controlling the work list is important and priority is KING.

Agile processes are all about knowing the priority work list and what the people CAN accomplish. In essence it is all about the people involved (project and program managers included in the 'people involved'). Agile is about knowing what the people are capable of doing, producing a measurement of that (velocity) and using it as a way to understand how much work a given group is capable of in a time box. This turns the tables and empowers the people involved to push back and say no to things because they have a definative measure of what they are truely capable of accomplishing well and correctly. That is not to say that on occasion some teams will go above and beyond, but that doing so becomes a CHOICE and not a MANDATE because the speed of the team is no longer a variable and if it is - it tends to be a very predictable one.

Agile is all about the people. People understanding themselves and the people they work with. Understanding what each one of them does best and putting those things together to get a deployment of working software out the door. Agile is about making the software delivery as predictable as possible. Agile is about adding the right process to the people to allow for that predictability. Agile is not about imposing or over imposing but focuses in on the people involved and helps them with the right 'touch' and guidance, the right process. In that respect - agile process is the hippy of the software development world - one that I am more then willing to embrace because it is the people that matter. Without the people - nothing gets done and if you have a process that works well with the people and not counter to them I would argue you are going to get alot more done with people being generally happier about it.

Intra-Office Male Genitalia Mesurement

Company A Purchases Company B

So this all starts innocently enough, one company seeing an opportunity to fill a gap in its own game plan purchases another perfectly running company, on the surface. The company doing the purchasing does their due diligence, reviews the books and game plan of the company they are planning on buying to make sure that everything seems like it is on the up and up. This whole process goes smoothly and everything seems to check out. The idea over all is awesome because it fills a hole that company A has in its offerings or business plans. The purchase moves forward.

The Excitement reaches a peek

Both companies are very happy that things are moving forward. The documents are being put together and everyone is having their lawyers look over and red line them. This is a time of satisfaction for both companies involved - a time of celebration. The final signed items are in and the purchase is complete. They are now a single company, this is when the measurements begin.

Making their mark

Company B (The purchased company) now starts to feel that they have to make an impression, show their metal and let everyone know that they have been very successful and that Company A purchased them for a reason. They try consistently to show how what they do in terms of development and process is the best thing since sliced bread. Company B goes out of their way to make sure that everyone knows that the way the do things has worked for them and they want Company A to know what their past experience and success is. This process does quite the opposite however and starts to make Company A staff think that Company B staff are pompous and think that they are better then everyone else. Both sides start to feel slighted and no one feels as if things are working smoothly.

My way or the high way

I once wrote about this very topic when I was talking about management but here, in this situation, it becomes a mechanism for how communications between both companies go. Company A thinks that they are right, Company B thinks that they are right and in the end - nothing productive gets done. If something productive gets done it is generally due to people pushing through their own personal preferences and differences and not because any of the communications or relations between the two companies have gotten any better. This posturing may eventually break down and one or more managers on either side step in and just lay down the law. This sometimes has a good effect and other times has the opposite feel. Without a solid direction of 'ownership' and decisions making however - this state of afairs gets set up to continue to repeat itself over and over and over with each project that is attempted that is inclusive of both sides.

Mine is bigger then yours

In the end the whole thing becomes some sort of bizarre mating ritual where both sides are whipping IT out and stating that theirs is the biggest in the room. In the end it breaks down into a childish US vs. THEM when it didn't need to.

What is gained? Nothing really... reality is that no one is going to get canned, ideas come and go but good people, when respected, stay. This makes for some of the best situations where really good things can happen if we just stand back and let them. Instead one or the other side feels as though they are being ignored or something else and bad blood builds and builds leading no where good. We spend more time measuring one another rather then just doing good work that we both know that we are capable of doing. Its a bit cliche but:

Can't we all just get along?

We need to stop measuring each others male genitalia and get down to doing the work that we both know we can, transparently, cohesively and without fear. Sharing all blemishes, pimples and high points in an attempt to pick the best of both sides and get the BEST possible answer for all rather then a semi good answer for one or the other.