CREOtive Thoughts

Yeah, it's been a while. My apologies, but life has kept me busy.
It seems like it took a severely rantworthy incident to make me blog again, and such a marvelous event has been taking place during the past few days (for large values of 'few'), so here we go.

I may have mentioned (in not so kind words) a certain client of ours who mightily profited from our willingness to to invest lots more energy than we got paid for in exchange for the opportunity to showcase our abilities to come up with extraordinary solutions to ordinary problems. This person, for clarity's sake let's call her Suzy, was able to make us get a tremendous load of work done for peanuts. Suzy clearly had a talent of recognizing people's weaknesses, and ours was our lack of references. Suzy therefore came up with the truly ingenious plan of promising us a very interesting, and reasonably big project, and we were inexperienced (some might call it naive) enough to jump at what seemed to be an opportunity. To make a long story short, by mentioning this imaginary project whenever our motivation seemed to fade, Suzy successfully kept us going and literally working for free on whatever small task would come up for months. Suzy would usually conserve energy by using a pre-prepared template and just slightly adjusting $reason, $excuse and $date in what approximately sounded like "Hey guys, unfortunately I can't meet you as agreed and postponed 5 times already, an appointment at my hair-stylist unexpectedly came up, but here's the thing: I need $this and $that done, and it's quite urgent, so can you please get this done quickly? I would appreciate it, and don't forget, we need to meet soon to talk about this very interesting and well-paid project of mine that you will be able to get the contract for if you behave nicely. Cheers & Hugs, Suzy!".
Well, we started to notice certain similarities in these emails, so after a while we told Suzy that due to company rules we required a written confirmation of the task to be done, so that we could bill her correctly afterwards.
As could be expected, this promptly changed Suzy's attitude towards us, all we have heard from her since was a one-liner, "Folks, I have found an alternative solution. Bye."
The latter probably could be translated with "I have found somebody else eager to demonstrate their capabilities, and I shall profit from that as much as possible until it is payday and I shall set out on the quest of finding somebody else". No, Suzy wasn't of the loyal kind.

Anyway, when I just said that that was all we ever heard from her, this isn't quite true. Firstly, we were interested what said alternative solution was. As it turns out, there was none. The project never got anywhere.
Secondly, a two or so weeks ago, we received a kind email from some countryside-webshack asking us about user credentials to Suzy's website. We didn't quite know where to put this - Suzy had all the user credentials necessary. In fact, it had been Suzy who had transmitted those to us. After answering somewhat along the lines of "look at the code dude, the password is there!" we received some rather helpless answers telling us that the big bad password wouldn't work, and that we were the bad boys who had changed it. Which - unnecessary to say - wasn't so. We forwarded to credentials to Suzy, to avoid handing out user-credentials to strangers knocking on our doors. Suzy did not think a "Thank you" would be appropriate for the guys who had so cruelly abandoned her a year earlier. She did however forward the information to the poor guys now in charge.
Now, these vacuum-cleaner-consultants-become-web-developers introduced us to the details of their problem: they couldn't access the 'phpMySql-Console' (phpMySqlConsole seems to be an actual project, though not a feature offered by the hoster in use, and probably not what lumberjack-developer meant). The reason they wanted to do so is because they were migrating the whole site to a different hoster. The provider-supplied password did not seem to work. Our advice of just using the credentials found in the php-configuration-files which had to be up-to-date as the Site would otherwise not have been up and running was answered with a "but it doesn't work! Really!". We didn't have anything to say for 10 days or so, because quite simply there was nothing to be said. After having received another email begging us for advice I typed a quick line into the terminal, successfully connected to the server, briefly looked at the tables and was positively puzzled. What on earth did our new buddies want from us? Being able to connect and read a database should be enough to migrate it to somewhere else...right?
All that was left for me to do was to re-iterate that we had not changed any passwords, that the credentials found in the source-code were indeed working perfectly, and that I could just suggest the obvious - having the provider reset the admin-password.
I expected an angry reply, but what I received was pure thankfulness. That's what they're going to do, as it apparently is less trouble than dumping the database on the commandline. I'm standing here in awe and admiration, feeling thankful for having been given the opportunity to make somebody happy.

Some brief, random notes and questions to complete this post:

-) How on earth can you run a software-business without being able to take over a project from somebody else because "the password doesn't work"?
-) Why is it so hard to find clients even if you have skill and ideas, and why does it seem to be so easy to those with the extra lack of clue?
-) Why is the weather so bad these days?
-) I'm learning ukrainian now - damn hard, that.
-) I was on holidays in Canada in September - 'twas awesome!
-) Suzy - but we can still be friends, right?!
-) Just kidding.

Well, we fucked up. As always - we just haven't accepted yet how nonsensical and absurd a Client's requirements mostly are, we haven't learned yet how to interpret them correctly and we still don't know how to do precognition properly - but that's what's expected of you, it seems.
This time, our project was to make "some small changes" to a custom content management system written in our beloved (beware of the irony) PHP a year ago. Before accepting the contract we not only had a chance to see the functionality of the system, but also the code. While it was quite unimaginable to us how you could still write code like that in 2005 we didn't investigate any further - granted, it was ugly, badly (if at all) designed, not secure, not using any of the web's newer features, using a mixture of all PHP-Versions available while avoiding to use the newer features in a way that actually made sense, using indentation as a kind of graphical, artistic element unrelated to syntax or semantics and mixing PHP and HTML in a really clueless old-fashioned "let's quickly write a dirty script"-fashion quite unsuitable for a "professional" project. But hey - the small feature-changes we were asked to do wouldn't require us to change any of that...right?

Well, it wasn't until we actually began coding that we discovered sweet examples of "I ain't got no clue - but I took the money anyway" of our predecessor. Like the following fields in a database-table:

date, time, date1, time1, date2, time2, date3, time3, date4, time4.

It seems like our dear colleague just changed the database every time he discovered that an item could appear more than once. Of course he also hardcoded those things into the code.
What's even nicer was that he hadn't managed to centralize database-access, he just kept writing the same queries and mysql-statements into every file. Which meant that when we began normalizing the database we had to touch about every file, change it, test it, etc. It was of course work we weren't paid for because we hadn't expected we would have to do it. Further along we discovered that code he hadn't managed to get to work actually didn't work - he'd just created dummy-functions without any functionality. Users weren't supposed to be able to enter more then one entry of typeX per day - but in reality nothing prevented them from doing so because

function checkUserPermission($user) 

  {      /*hm...this ain't working 

	   blahb, lahblah; 

	          blah; 

	blahblah; 

	               */ 

	return true; } 

didn't really care. (And yes, the crappy formatting is genuine, that's the way the guy writes code! Python should be compulsory for weirdos like him)
His use of javascript was especially heartwarming. In short, its only purpose in the CMS was to make it non-accessible to JS-disabled browsers. No, I'm not exaggerating even a little bit. To submit data to the server, for example, he would use a hidden form in the page, monitor updates to fields outside that form via javascript, update the hidden-form with the new values, and then monitor clicks on links via javascript as well and in case of a click call submit() on the hidden form! The hidden form would have an onsubmit()-handler defined, but you can already guess its definition:

function validate() 

{

	return true;

}

It really made no sense at all. You still had all the page-reloads the standard-use of forms would have given you (but those would have been accessible), you had no additional value (the checking functions didn't do anything), but with JS disabled you wouldn't have been able to do anything at all because not even the simplest link would have shown any function. Yep, of course the JS wasn't used in an unobtrusive way, it was just intermingled and hardcoded in the middle of all the PHP and HTML, the guy hadn't even bothered to set href-attributes in <a>-tags, he just used all the tags as event-targets.

Well, I could go on for hours, but I guess all I'm trying to say is that not only is a good design (and I ain't talking about graphical designs, for all you webdesign-only guys) at the beginning of every software implementation process, but a thorough examination of requirements, the environment, available code, flexibility with respect to changing requirements needs to be a cornerstone of any work on legacy code. Unnecessary to mention that course the "small changes" were just the beginning of what we've been doing for weeks now. We've implemented several new features, and in the course of that we had to touch the old code many times. The side-effect of that is quite some improvement when it comes to overall code-quality, but all in all the legacy-stuff really slowed us down so much as soon as we began making major changes and adding features that it would have been better, cheaper, faster, and it would have boosted quality-of-life if we'd just sat down and properly re-implemented the whole system from scratch. Even more so when thinking of the side-effects like producing good-reusable software-elements that we could have used in future projects. Now much of our new code needed to be tied to the legacy-code in ways that would require at least some modification to make it reusable.

Lessons learned: Don't trust your clients - they want a lot more than what they're telling you. Don't continue to use a hacky-crappy-bad codebase, if it isn't really that large. And the size of the existing code might be irrelevant anyway. Just look at the functionality - maybe you can implement it with much fewer codelines.

It was a rather unconscious decision to do a whole series of about-clients-stories. In fact, I hadn't even noticed that I had done just that. I was using the blog-features of Textmate to post to my blog, and if I went through my articles again at all it was via Bloglines, so I really couldn't see the series develop. It's interesting to see though what's obviously the biggest issue when launching an enterprise. It's the clients. It's how to find clients, how to make them trust you, how to make them understand the advantages of your product, how to make them value quality more than cheap&dirty-hacks, how to make them understand why they can't have their way if they want a decent product (because what they have in mind is no good at all), what to put into a contract so you can still have a life and actually earn some money, how to deal with your client in a general manner (what a client expects is sometimes far from what would be logical), etc., etc.
During the past few months we've certainly learned a lot, but it wasn't so much fun at times. I wish we could have avoided one error or the other.
The latter wouldn't have been impossible, I think, if only all the business-stuff we're told at university didn't suck so much. In our study programme we have to do quite a lot of business/economics-related subjects. But instead of telling us about how to get a company going (in a real sense, not the "Once you have your many thousand Euros together, decide about who's going to be your CEO and start renting offices and hiring employees"-kind-of-sense), how to find clients, how to deal with clients, what's expected, what's necessary and what's avoidable, we're told lots of things that simple aren't applicable. They're either too theoretic, or too simplistic. It helps of course too have a general understanding of things so that when you delegate that kind of jobs to specialists you can still understand what they're doing - but here we need to learn things by heart that we'll have forgotten 3 days after the exam, but we're never told about basic real-world stuff.
I'm totally aware of the necessity of finding your own way of doing things, and making your vision of things what makes the company tick. But I still think a hands-on-course about the basics of starting up would have helped (wheres I can't see myself EVER applying the stuff we were actually told about in the courses we had).

"I want an accessible website"
"No, I don't like it this way - I want popups!"
"No, I don't like it this way, I want you to take this image and put it online. No, I only want the image, nothing else. Why wouldn't that be accessible? I can see the image just fine. Enough of it now! Image!"
"No, I dont like it this way. I want a layout just like the paper-flyer I had designed by a graphics artist. Well of course I know that the medium is a different one, of course I know that the possibilities are different and you need to adapt - what d'ya think, that I'm stupid? But frankly - I don't care. I want my paper-flyer online. And I want it to look exactly like it would on paper. 'nouff said"
"No, I don't think you heard me. I don't like it this way. I don't want to scroll down. And please, I want the page to fill the screen horizontally. On the other hand I want the text to be even narrower. Would you please work some magic?"
"I believe you're incompetent. I said I don't want to scroll down. I prefer to have all the content in a little, tiny part of the window, and when there are unusable, usability-nightmare-scrollbars there that's just fine with me. I probably just wanted to make a point."
"Yes, I'm aware that you're probably beginning to notice that I don't care a single bit about my handicapped readers and that I don't even know what accessability means, it's just - when I was talking to the CEO about the website-project I thought it sounded pretty cool"
"Yeah well, I kept bugging you for weeks to come up with a color combination that at least wasn't soooo ugly, because it was really hard to find colors that would match the pseudo-gold from my paper-flyer. But now that I have my CMS I'm using all the features it has to make the site look ugly by using 10 different colors (that don't go well together at all) on every page. I guess you can't use my site as a reference after all, huh?"

Should clients really have their way? Is it better to refuse and to lose a customer, or to deliver a product where you know it's bad, but it's exactly what the client wants (and despite all the consulting we did he didn't want it any other way)?
This project taught us a lot. I'm not sure it was worth it, though.

So...we were asked to deliver a proposal for a new website including a CMS for a real-estate agency. We really were interested, because a short while ago we'd been discussing a row of nice features for that kind of clients, features that the competition doesn't have yet (at least not the relevant, local competition). So we sketched up a 10-pages offer with a detailed description of the features, in simple, non-tech-language, pointing out all the advantages for the client. And we weren't just trying to sell something - far from it. We truly believe that the feature-set we came up with would simply transform our client into the real-estate agency with the most useful, most usable website in the whole city, which according to our beliefs would give them real advantages in terms of satisfied customers, returning customers, happy customers less reluctant to pay a (usually steep) price for good service - in short, we think the system would have helped them to make money. I believe that the (very justified and relatively low) price we would have taken for the project would have been amortised in a few weeks, months at most.

Well...we neither got a "hey, we like that", nor at least a "hm...it's a bit expensive, but interesting". No. What we got was a "cut the crap! I don't want any of that fuss, I just want the same website I had before and I want it to look better. And I don't want it to cost anything". Well, not in that words, I'll admit, but in the end it amounted to the same thing. "We want low costs. No, lower than that. No, you're not quite there yet, lower! Features? Naaah, we've been doing quite well without those for the past 50 years, why would we start having them now?"

I can't imagine how someone who's incapable of thinking more than a day ahead can lead a business, and explicitly demands a mediocre product for a low price, when for 50% more money they'd get a really decent product, and for twice the price they'd get a really good product with probably all the features they'll need during the next five years. (And when I say twice the price I'd just like to remind you that we're not talking real money here, the project's size equals one or two month's salaries of one of our client's (lowly paid) employees.)
It is equally mysterious to me why "traditional companies" can't seem to make the little step across their old-fashioned ways of seeing things and accept that for a large fraction of today's customers getting information and further services using the facilities the internet offers is a necessity, not an option. It's what Herzberg calls dissatisfiers in his famous theory about satisfaction of employees (1), something that makes you rant and complain when missing because you just expect it to be there. I strongly believe that customer satisfaction equals money, at least to some degree. Our client obviously disagrees. For them, only money equals money.

(1) Herzberg's theory