Wednesday, July 26, 2006

Open source nightmares

I think one of the biggest problems with open source (OS) development is the lack of proper and clear documentation. I've realised over a period of time that the biggest assumption that all the OS languages have is that every developer is a skilled developer and as such needs very little documentation or sample apps to begin with. I'm not saying that all of them lack the proper intro material but a bulk of them do.

The biggest culprit in my view would have to be the projects under the Apache foundation, by the way the projects these guys have are pretty interesting,the likes of Tapestry,BeeHive just to mention a few..By the way the guys at BeeHive do at least try and give you some form of documentation :-)

Every so often I get a chance to glance over the Apache Foundation website and see the new projects they have, hoping that with time they will have introduced better documentation but true to their nature they don't seem to care for the Beginner Programmer out there who has very little knowledge of the whole XML+Ant+War thingy...

Why focus on developing new frameworks when people can't get decent documentation on the current ones?

Microsoft has it's flaws but one thing I do give them marks for is that they do provide adequate documentation on all their frameworks. Take a look at the .NET framework, they've given you all the docs needed to start developing a basic web app within minutes of the installation. Then we have the website ASP.NET which is like your one-stop shop for anything and everything concerning the .NET framework, very nice stuff on it.

The guys at Interface 21 (Spring Framework) at least they tried by providing you with a sample application which even though isn't comprehensive it does get you started on the whole process. Matt Raible's Appfuse application is pretty good but lacks the start from scratch thing that beginners (like myself) want. Isuggest you head over to his blog and check it out, very nice stuff including some of his sample apps built using Tapestry,JavaServer Faces,Struts,Webwork and Hibernate not forgetting to mention Ibatis (easiest SQL mapping implementation I've ever used :-) ).

I recently started experimenting with Symfony PHP5 Framework, I didn't expect much but when I scooted off to the documentation section boy was I surprised. These guys have a fully developed web app Askeet.com and a day-by-day development lifecycle, what makes it even better is that it's all downloadable the source code as well as the tutorial (for those of you who don't have 24hr internet access you'll most definitely appreciate this). If you think that's not enough they have a One day tutorial showing you how to develop a basic application in one day damnit!! these guys are good. They even go a step further and give you access to movies describing how to perform certain tasks. Now this is what I call comprehensive documentation.
Some of you will notice the similarity between Symfony and RoR(Ruby on Rails) :-)

Why can't the guys at the Apache Foundation take time off and sit down to make some decent documentation??? Your projects are really nice but if am gonna spend hours trying to find out how to connect to a database and retrieve records then sorry guys I'll go to the next easy thing..

Other articles/posts written on the subject:

Friday, July 21, 2006

Is open source technology commercially viable in Africa?

"You'll never make money in Africa if you go open source" a quote from my former boss, who is the founder of the most successful web development company in East & Central Africa.

My boss told me this when I informed him that I had been offered a job developing web application on the LAMP stack, the statement made me really think and question whether open source technologies adn their adoption have any commercial value in Africa.

A couple of interesting article/blogs on the net:

Open Source In Africa
Open source rising in Africa

Websites:
Go Open Source

This is just the first of many posts I'll be having on this topic, so watch this space...

Sweatshop Experiences Part 3-Prototypes

Prototypes-the very mention of that word makes me shake in my boots. Don't get me wrong am a fan of making prototypes during every stage of development, the problem is that people abuse the very essence of prototyping.

Management use prototypes to bash the developer and add functionality that wasn't in the original specification much to the detriment of the developer without any consideration of how it affects development timelines.

Well my bosses basically used those prototype display meetjings to rewrite technical specifications because they would all of sudden get a wave of brilliance they hadn't encountered before!!..Imagine a situation where the IT Manager has been approving every stage of the development but when you meet his boss who automatically is your boss he immediately begins adding new stuff:

  1. Could you automatically notify the user once a record has been deleted?
  2. Could you let action 1 determine action 15 without it affecting all other actions?
Leave development to the developers and nudget meetings to the managers..

Wednesday, July 19, 2006

Sell yourself not your soul

"Sell yourself not your soul"-Quadimoso 06

The inspiration for this quote came from a chat conversation I was having with a former workmate of mine today, a fellow web developer, who informed me that the Creative Director (who has now left the company) told the production floor people to develop their own portfolios and put them on the internet as a showcase for potential employers :-) talk about marketing oneself!!

For those of you who don't know, it's an unwritten rule in the web design industry that you should never outshine or outsell your employer lest he smites you with one powerful blow!!..

And that is my moment of zend for today :-)... Jon Stewart Rocks :-)

Why PHP?

Why not PHP? that's the question which most people should be asking. PHP in my view has the following benefits:

  1. Open Source, meaning free and continous development by the open source community.
  2. Easy learning curve. In my opinion (yours could be different) PHP is pretty easy to learn and use, once you've mastered the curly braces look and feel your good to go.
  3. No setup challenges, download the binary and set it up and your good to go. I've done some basic web dev in Java, specifically using Struts and the Spring Framework, in as much as Java is powerful the setup of a web app can drive you insane and have you pulling hair from regions I can't mention here :-) If it's not the XML that will kill you it's the web app structure (/WEB-INF,/LIB,/CLASSES) that will have you wondering what's going on.
  4. Powerful collection of functions for every imagineable task you'ld like to carry out. Having come from a Classic ASP background where you have a handful of functions to work with, PHP is like a gift from the gods :-)
  5. Tight Integration with MySQL, do I need to outline the benefits of MySQL?...No..Just go to the website and read up on what it has to offer. For the skeptics out there, Craigslist runs on MySQL and Yahoo Financials plus many more..

    This isn't the whole enchilada, just a tip of the iceberg. Check out http://www.zend.com/solutions/why-php.php for more reasons to make the switch.




Five Steps To Kicking Off A New Software Project

I just thought this might be an interesting read for all you software developers out there. It's an article from Russ Olsen's Weblog you might want to check it out:

Five Steps To Kicking Off A New Software Project

Several times in my career I have lived the engineer's dream. A brand new project. A clean sheet of paper. New team. New technology. Although in each case the goal, and the technology, and the people were different, these projects all had one thing in common. They were sheer Hell.

Oh sure, a clean sheet project is wonderful challenge, a great way of stretching technical skills, a new start. But the first phase of every really new project is always the same: chaos. Nobody knows what exactly we were supposed to be doing, but we all know we need to do it in a great hurry. The tools are unfamiliar. Half of the team is frozen in indecision half the time, while the other two quarters are working overtime to duplicate each others' work. The infrastructure is missing or changing daily.

I don't know how you start up a new project painlessly, but I do remember a few things that helped:

1) Get the infrastructure up now

You just can not develop software effectively without a little bit of infrastructure, and the longer you wait to install it, the harder life will be. Get that subversion or CVS or whatever server up and running on day one -- I don't care if you only have a 486 to host it, get it up and running. Follow this rapidly with an automated build system. The best automated build system you can create is the one that is in place before there is any code to build. Ditto with those mailing lists: the first day someone sends a email to the acme-developers list suggesting we all go to lunch is the day you start to have a team. A wiki and a bug tracking system are not quite so critical, but why not stand those up while you are at it?

2) Now is not the time to build a framework

Tony Hoare is usually credited with uttering the classic bit of wisdom that "Premature optimization is the root of all evil." Well if that is so, then premature frameworks are the stems of evil. Or maybe the leaves.

The early days of a project are difficult for coders and one reaction is to run away, run far away into the well defined land of building a framework. I say framework building is well defined, because, well, it is usually the engineer, as opposed to the real customers, that do the defining. "I see we have some tough GUI problems here, let me go off and build a framework to solve them." Left unspoken is, "And I get to stop thinking about all this hard and confusing stuff."

The problem with this is that if you don't really understand the basic problem you are trying to solve, and early in a project you don't, then that framework you are building is unlikely to help. Leave the frameworks until you know where you are going, until you really have code that is duplicated and you know that if you step back and take a longer view, you can do better.

3) Frequent, short meetings

Reread the title of this section again. Pay special attention to that second word. S-H-O-R-T. There is a tendency early in projects to mete out death by meeting. If we are all ignorant and confused, let's get together and talk about it for six or seven hours. That will help.

The main problem early on in the project is that on any given day, each person will discover one more piece of a 10,000 piece puzzle. What you all need to do is to get together and share your pieces. But if you stay in the room for four hours or even one, you are taking up valuable piece searching time. Get together, show off your colorful new piece of the puzzle, and then get back out there and start prospecting again.

4) Don't change everything

I think it was Fred Brooks in The Mythical Man Month, a book written a very long time ago and still worth reading, who introduced the idea of the second system syndrome. This happens when engineers start over with a new system and are just dying to fix everything that was wrong with the old one. All this old junk, these old techniques, that old library, and certainly that ugly GUI, they all have to go. And it's not just the coders either: SSS can infect the configuration management folks -- God I want a new bug tracking system -- as well as technical writers -- Let's do all of our work on Macs for the new project!

These may all be great ideas, but do them all at once and you will spend the first 80% of your schedule making the bug tracking system generate bug reports in the right format for the tech writers. And bug reports you will have aplenty.

This is an area that calls for careful, controlled decision making up front. Your team has strengths, and one of them is experience. Experience of things that worked in the past. Build on that experience. Make sure you have some familiar tools and technologies in the mix. Don't always say no to new ideas, but don't always say yes either.

5) Walk the halls

If you are any kind of leader in a new project, anything from a task lead on a two person project, to the manager of development, and you are not talking to your folks daily, you are not doing your job.

And I don't mean email. Nor IM. I mean face to face. If you are not aware of when one of your coders has something particularly aromatic for lunch, if you don't occasionally suspect that Fred wore that same shirt yesterday, you aren't doing your job. The problem with a new project and new technologies and a new team is that everyone is in unfamiliar territory. You are either dealing with people you don't know, or people you do know who are dealing with a project they don't fully understand. Either way, the chances of electronic miscommunication are, well, high.

Don't believe me? Image you walk into Bob's office and ask him how his project is doing. Bob, who obviously didn't get much sleep last night, shifts in his chair, looks at the floor, rubs his face and says, "OK."

Now imagine you walk into Sally's office and ask the same question. Sally leans back in her chair, picks up her triple vente hazlenut latte, flashes you a big grin, and says "OK."

Now image sending Bob and Sally an email: "How's your project going?" Same answer in both cases: "OK." If you really want to know what is going on, get out there and talk to Bob and Sally.

There you have it. No silver bullets here today, but sometimes you need to say the obvious because the obvious is so frequently obscure. To get a new project started you need infrastructure and you need it quick. Don't let anyone run off to framework land too soon. Get the folks together for frequent, short meetings, and keep some of the underpinning familiar. Finally, escape from your important Microsoft Project work every day and check on how the actual project is doing.


Tuesday, July 18, 2006

Sweatshop Experiences Part 2-PIST

PIST short for "PIecing Shit Together" a little acronym I coined :-)

"A coder needs to be lazy"-Quadimoso 2006

A manager's idea of a constructive activity is to have very very long meetings just to discuss items that could have been summarised in a few minutes..My quote should fill you in on how we feel about wasting time talking when we could be coding :-)

I spend a few days going through the spec and trying to understand the direction these guys want the system to head..even before I can digest everything my boss keeps coming and asking me for "something,anything" which basically translates into a prototype..I'm wondering a prototype yet the tech spec is barely a v1(Version One), I resist the dude but finally I give in and do a small demo/prototypeV0.1 :-) so that his bosses can see that at least am working and I can justify my salary (not even worth justifying)..

Development Environment

I choose PHP,MySQL,Apache as the development environment because of the power of the whole stack, unfortunately I don't have any Linux to give it the complete setup but windows will do for now :-)

More on the development environment later


My boss, the IT manager drags me into a meeting to discuss the "Tech Spec" and basically show the suits what I've done so far, the meeting starts at around 9am and we finally conclude it at around 10.30pm, yes!!..you do the math we talking of more then 12 hours discussing a 4 page document where some other manager takes the lead and basically shoves his ideas down my throat..

Almost forgot to mention something, the IT manager is kindoff a wimp who basically wants to please his bosses so he just agrees to everything and gives me this look that to kindoff see if I agree when all along his basically screwing me over..


At the end of the day with me PIST beyond control they basically scrap tech SpecV0.1 and come up with a new one, don't forget I've done a sample demo based on the first tech spec..

Part 3..will be worth the read :-)

Sweatshop Experiences Part 1-Tech Spech Hell


A couple of months back I left a web design company I had working for almost four years to join an offshore call center, actually the first of it's kind in East Africa..A radical career shift you might think but I was basically going from external web development to internal web dev where my systems would be used internally..

I like referring to this new place as the "Sweatshop" because its one massive industrial godown with about 100 people behind computers wearing headsets..We do have air conditioning although during this cold weather in Kenya we closing the windows as though we afraid the cold will make us shrink :-)..

I have to admit the move from a commercial web dev hub to an internal systems development setup was a bit weird but I've managed to settle in.

When I joined I was given a flight reservation system to develop, lets jus say these guys had (eventually lost the client) an airline as a client who wanted a system developed to help them do all that scool stuff you see on www.kenya-airways.com never you mind that this airline only has a few domestic routes. I had to work with the IT manager and some Business Development dudes who had no idea about systems development and are in my opinion just paid suits who seat and yap all day.

I was given a breakdown of the system, the requirements and told to come up with a timeline for delivery, oh yeah! I was also given a "Technical Specification" and I use the term loosely since it fell far short of one, considering the scope of the system.

Let me just wander of a little bit:

The need for experienced technical specification developers is something we in Africa should address. Developers are handed over to Business Dev Mangers who see systems like excel sheets even when the system will be web based. We spend hours arguing over the smallest things even when the person we arguing with has no experience whatsoever in development. Trust me I've learnt the hard way.

Anyway, there I am going through this weirdly done document, not an experience for the fainthearted.

More to come in Part 2..

The Alpha

I've started many blogs, all of which died a very unnatural death..so I figured let me blog about what I like doing most that's coding..specifically web development..I've coding for more then three years and who knows may be my experiences might lead others to the "Honourable life of a Samurai Coder" :-)..hahahaha..that sounds so Last Samurai like..

By the way I'm no guru,techie,nerd or any other tag..but I do have aspirations of being a web development guru :-)

Anyway..thus begins my journies through the technology jungle south of the sahara..