Kjartan Mannes

In my mind, what is true of Python holds true for PHP also. Furthermore I can train a C or Javascript programmer to code in proficiently PHP in 2 days. I cannot say the same for Python. Python enjoys a certain intellectual cachet among the digerati, but I think PHP is the better language, especially when PHP's support for threads and unicode is fixed.

I'm so tired of this really. Every language is "better" at some things and worse at others. The sooner programmers start thinking of the language as a tool and not a religious debate the better.

"Why all do all your MySQL table definitions include NOT NULL all over the place"

Each column in MySQL saves one byte if it doesn't have to concider the NULL value.

"But that is insignificant? Even with 10000 rows you have only saved 10000 bytes which is 9-10 KB. Why bother?"

Ahh, but you do the math wrong. It is per column. On average our tables have 15 columns. That is 15 bytes saved per row, or 150000 bytes, which about 145KB.

"That doesn't really matter much though? You have to have a lot of rows before it becomes an issue. We have plenty of disk space"

Yet again the thinking is too narrow. Databases are not just saved in disk, they are loaded into RAM. How else do you think MySQL accesses them so fast? We have a limit on much RAM each MySQL process can use, and we generally have 100 MySQL proccess active. Even with 10 rows it starts to add up. 10 rows * 15 columns * 100 proccesses = 15000 bytes saved. We have thousands of rows. Of course this isn't fully real as what MySQL caches is a bit differnet, but we want the databases as compact as possible. Also disabling NULL means our queries and applications have one less value to worry about, which can add up to precious seconds when processing.

Also any simple things you can do early on to optimise you should go ahead and do, but only if they are simple and don't take any time to perform. I know people say to optimize as the last step, but in real life the last step is usually done under intense time pressures and high stress. Some optimization has to be done during the process to make sure the application isn't a mess at the end of the development cycle.

"So why does NULL even exist?"

It has uses. Concider keeping track of the age of people. If you don't know the age you don't want to record 0 as that will tamper with the data in case you need the average date. In MySQL AVG(age) will ignore NULL values. Sure if everyone is at least 18 you can do AVG(age) WHERE age > 18, but then your query is more compled and might take longer to run. So use NULL when you need it to perform queries on the data.

"Thank you master."

I recently took over a development project as the former manager had one of his other projects become so large it required a completely different focus and structure. (At least that is the official reason ;)

The first think I've done is asking questions to the developers. Nothing gets you in more trouble than asking "Why?” The list of activities left on the web application was fairly long. Some minor things estimated to take 2 hours and some large things that are supposed to take 100 hours or more. So I started with the biggest activities and asked a simple question. "Why will this take so long?" I had figured that there was some design document behind each change that explained the details and I just hadn't found out where it was. Its always fun when 4 people just stare at you with astonished faces.

They must have had some basis of estimating a task to take 100 hours. It’s not like developers just to guess wildly at how long something will take, right? Whatever. Not getting any answer I changed question from why to, "what needs doing to make the database structure more modular so future development?" Worthy goal, but you don't just modify an existing projects database structure without thinking about it first.

I got some answers and entered them into a spreadsheet. Then once they felt the activity was well defined we started estimating how long each of those would take. Now I was starting to see estimates of 4 hours there, 6 hours here and 40 hours there. 40 hours?! So let’s refine that one even more. My goal is to have every activity down to 10 hours or less. Why? Simple, makes people think things though. Nothing is more dangerous to an existing application than a developer making large changes without having any idea of everything involved. (Except a few exceptions!)

Then I started asking control questions to see if they had thought of all the other components of the application would be affected. This caused some more changes to the list.

Now I have a nice plan with this 100 hour activity split into 15 sub activities all less than 10 hours. Also its not 100 hours anymore, its 124. Not that it matters, because without taking the time to plan it out it would have taken even longer and with plenty more problems. Now I and take this mega activity and assign various independent parts to several developers, making the total real time spent less. Also when I promise something to marketing and sales I feel more confident we can deliver on time. Since I also handle customer relations to some extend so I also don't end up promising too much too fast.

This is a mistake I made once and wont make again. Last year I had to resort to external developers to assist on a project that had doubled in requirements but kept the same deadline. Thankfully the project consisted of several parts that were virtually seperate. There was some clue in the middle but the exact specification for that had been worked out from the get go. So there was no problem for the external consultant to get cracking on the system. There was only one problem. The application was very tied up to insurance laws and calculations. All the in house developers had worked in this area for a year or so already so they had picked up the basics and knew the logic behind how insurance works in Scandinavia. What I forgot was that the new developers this was all new and we were expecting them to figure out specs that were not detailed enough for people without the knowledge of the field.

Needless to say a lot of extra time went into explaining strange issues, and they didn't have the knowledge to notice when what they got explained by someone in sales or marketing wasn't what they really wanted. A lot of development go tossed out since once it was supposed to be ready it wasn't what was really needed, or it was too ridgid to easially expand to handle future additions or exceptions to the rules. It was frustrating for everyone. It is no fun being a developer on something that you don't have the ground work to figure out.

It worked out in the end once I focused more on being a part of their tasks instead of supervising the guys who knew what to do.

If I had to do it over again I would have sent the new developers on a 1-2 week course at our insurance academy for them to understand the basics. I think it would have been cost effective in the end. Less time spent on useless code and extra meetings, as well as increasig their knowledge and moral. If angled correctly it might even have been possible to have their employer pay for the course. It would also make it more likely that we would have employed their services in the future, but because the first experience wasn't great who knows. Mangement doesn't care about reasons much, just the bottom line. Bad impressions are hard to overcome.

So the next time I have to use someone to develop an application with a focus on a field of knowledge they don't possess I'm taking the extra time to teach them first.

Time for a name change?

As things stand now this seems to be the only way to go. I've seen Dave agrue that it is the "other side" that is refusing to work together, but Dave doesn't even take part in the conversation.

I think in the long term that it will be for the good of everyone that the two versions of RSS diverge and let the market choose.

Note to the RSS 1.0 WG: develop proper libraries for developers to use, and make it easy to use and find! That is where the energy should go, and thats how you will attract others to move to the format. Currently its not easy to find a good parser and writer for PHP. Haven't looked for Perl or Python but I would guess there is some work to be done there too.