Monday, February 28, 2005

libPM update

It’s evening.

 

I’m done with 75% of the WebService functionality for the C# library. What’s left is just the postback, that actually posts a subtask back to WebPM. This has been sort of fun in C#, tho I have serious beef with having to use the ugly (compared to python’s alternatives) WebClient class.

 

I don’t know why Dynamic Languages still havent’ generated the required industry clout, when without a doubt they are the easiest to establish REAL abstraction in. I mean, I want to simply get a web page. In java, I have to use HttpConnect, and still obtain a stream from it, and do some fancy buffer acrobatics before I can read back the plain text contents of the page.

 

 

In C#, (there may be other ways which I don’t know), I have to use a WebClient class, and get first a Stream then get a Readable Stream from the basic Stream. At least, I don’t have to do the buffer acrobatics, but its just plain silly.

 

I would love to just do something like  handler = url.open(url). Then handler.read(). This is the natural way to deal with data content. And its basically the way languages like Python, Perl, PHP, etc, do the stuff. Its so easy, I don’t see everyone’s not using them. 80% of the time, when I’m working with Stiff languages like C# and Java for application development, I have to go about creating my mostly used Higher Level abstractions into small utility libraries before I start doing any real work, but in languages like Python, Perl, PHP, I just start coding, most of the abstractions are really high level and incredibly sufficient for me.

 

Uhh.. if you doubt this, try using the SANE (scanner) library in Python, and then try doing something similar in C#... EWWWWWW!!!

 

Ok… gotta run now, I’m gonna try to finish that last function before I go grab a byte J, then prolly tmrw, I’ll put together the small app that will help fill my PM. Phew… here I come guys.

 

The real thrill will actually be doing the Python version, and actually measuring how much time it took from start to finish.

Relay for WIN SMTP Server

 

Sending mail is supposed to be a joy, but if your SMTP server is remote and your bandwidth is low, it can quickly turn into a pain. You have two choices, switch to Linux NOW!!! And use Sendmail (ok, I was kidding, don’t touch this beast), Qmail, Postfix (my favourite), or.. okie, if you must, use the SMTP server that comes on windows with IIS I think.

 

The problem with that server is that by default relaying is turned off without proper authentication. Well, if you can vouch for access to your SMTP machine, like, you always work behind a good firewall, and there’s no danger in being turned into an unwilling BlindSPAMMER, then you can set relaying for all.

 

 

  1. Bring  up your IIS manager
  2. Right click the ‘Default SMTP Virtual Server’ or the SMTP server you want to change relay settings for.
  3. Go to the ‘Access’ tab, and click the ‘Relay…’ button
  4. on the relay restrictions pop up that appears, change the ‘Only the list below’ to ‘All except the list below’ if you want to be lazy

or

            on the relay restrictions pop up that appears, leave the ‘Only the list below’ selected, then click ‘Add…’, then either add your ip address(es), or network address with subnet mask, or the domain name you want to be able to relay from.

 

Uhh… hope that’s helpful, because it just stopped me from pulling out my hair from the roots a couple of mornings ago… uhh… ok… that’s not possible, I’m on extreme low cut J

 

libPM

I woke up extremely early this morning to start working on the C# implementation of libpm. This is an interface to a webservice we use at work to report our time. I actually wanted to work on the Python version this morning, but I think if I finish the Python version first, I’ll never get around to working on the C# version, since I will always be in this Quasi-irritated comparison between the two languages, not that C# is a bad language, just that it doesn’t have some of the extremely kewl functionality of Python.

Anyway, its time for work anyway, so I’ll continue it this evening. The idea is to have libraries that any of the other developers can use to craft their favourite interfaces to PM at work. I prefer the commandline interface and the mail interface via a normal text file. Anyway, I’ll continue in the evening. Should be done by tmrw morning, complete with a commandline client that uses it.

Friday, February 25, 2005

Mobile Services - A broader view of the webservices phenomenon

In one of my prior posts, I talked primarily on REST and what I
percieved where its strong points, but i made some remarks in passing,
which I want to concentrate on now.

The point I'm referring to was the Anology i drew between TCP/UDP and
Webservices/(Email,SMS) services. This is to me a very important analogy
on the Application Layer. I think that everyone is getting carried away
with just the Webservices part of it, which ofcourse is very important,
but then, we seem to be missing the apparent fact that this is just one
part of a larger equation. I'll call this larger equation 'Mobile Services'

Take this blogging service for instance. I prefer to use the Email
service to post my blog. I know i could write a small python script to
give me commandline or anytype of interface i wanted, with blogger.com,
but posting is not a time critical application, so i want to just type
up a mail, hit send and move on to something else then probably 5 or 10
mins latter (actually, its waaaaaay much faster), i get a mail
notification that says that my blog has been published.

Lets take this a step further, imagine i have this Home Control System
i've written, and its running on my server in the house. I travel to
Timbuktu (is that the end of the earth? :) ), and i decide to send it a
programming for the next weekend, when i'll be comming back. This
programming is not in need of immidiet response, since it really to be
queued for latter, there is really no need to use a Webservice to do
this. I could just type up an email, with the programming, and send it
to myhcs@myhouse.bleh. Latter in the day, when the programming is
accepted, my home control system can send me a mail to let me know that
the programming has been queued, or it failed or something.

If i want to do a quick override, I will just have to use a WebService
anyway, but for other kinds of interaction, WebService may be overkill.
also, i could use SMS.

Why am i bringing all these up? Well, because i'm not sure anyone out
there is tackling this problem space as a viable problem space. There
are kinks to iron out, like Authentication, when using Email and SMS,
(SMS Especially), general Standardisation, and the awareness that this
is actually a path that can be taken to solve real problems.

I think 'Mobile Services' are the future, and even tho WebServices is
the preferred method for lots of interaction, non-connection-oriented
protocols like EMail and SMS are in existence, and are being used all
the time. A mailing list is a typical example of a real life Mobile
Service driven my Email. Google has a Mobile Service driven my SMS as well.

In conclusion, folks are using 'Mobile Services' in an informal manner.
I think we should formalize them, and we'll suddenly be able to see
clearer into the whole mix, and I'm sure even WebServices will benefit
from this broader formalization.

As for me, Email remains my favourite interface to 'blogger.com'.

[epilogue: Essien finished typing up his blog, then hit Send in
Thunderbird, with a little smile on his face, knowing it was just a
matter of time before his new blog post hit the World Wide Web, and
Mobile Services became a new Buzz Word]

It works!!!

kewl!!! its still working :)

Mail interface to blogger.com bad?

It seems the mail-in interface to blogger.com is borked recently. I've
not been able to post by mail, and this is incidentally, my best way of
posting.

hmm.... :(

Monday, February 21, 2005

REST, SOAP, Email - Webservices the way it should be?

REST, SOAP, Email - Web services the way it should be?


I'm not exactly a web service Don or demi-god, or anything like that,
but I'm really a good programmer. I know what pains me when working on
projects, and what can help me get good results. Recently, I had to
build a device application that would work with a remote database to be
accessed via the web (naturally), and of course the word web services
poped up.

Long story short, I finished it. And during that course, i learnt some
important lessons. This weekend, I decided to read a bit more on
web services to try to close up any gaps in my knowledge, and some
interesting stuff has come out from that reading.

Instead of actually closing gaps in my knowledge, i have come to the
conclusion that what i need to know is not more SOAP/WSDL or XML-RPC,
etc, but what i actually need to know, is just more of my basic network
protocols, like PUT, DELETE, etc, (HTTP), MIME processing
(SMTP,POP,IMAP,etc), and other related stuff.

To get to this conclusion, these are the articles i came across thanks to
our big brother.... Google ;)


http://www.xfront.com/REST-Web-Services.html

http://www.webservices.org/index.php/ws/content/view/full/39565

http://www.onlamp.com/pub/a/php/2003/10/30/amazon_rest.html

http://webservices.xml.com/pub/a/ws/2002/02/06/rest.html

http://www.peej.co.uk/articles/rest.html


After reading all these articles, there seems to be a general consensus
that the way things were done earlier with Web-Services was inherently
wrong because of tight/close coupling. These days, it seems there is a
more to the document/literal paradigm when developing web services.
These also seem to have come about from the REST community making logs
of noise about lots of faults they found with SOAP et al.

I'm not going to repeat all those things, because first of all, i
haven't used SOAP really extensively to complain about it, but i do know
that the first time i actually sat down to think logically about the
concept of web services, the thing that came to my mind actually turns
out to be REST.

Its interesting to me because of the way i usually learn new concepts. I
believe that to a large extent, new concepts have subtle precursors in
things we already know. When i come across a new concept, i try to
relate it to something I've come across before, trying to get a rough
match, before i proceed. Sort of like being offered a new kind of fruit
and you go like, "Well... dunno if i'll like it, but lemme try...
mmmhh... tastes like Mango, only... a little... bleh.... ". Anyway, the
point is in relating to things in the most obvious ways.

Before my present job, I had worked in an Oil Servicing company, and one
of my projects, had been to build a low cost always present
communication system, complete with near-realtime status reporting. It
was an interesting project, and although I left the company before the
project was 100% finished, the idea was sort of novel in solution (i
think). The solution i came up with, was to use Phones, Email and the
Web. For these, the company acquired some satellite phones with ability
to send and recieve email. The remote worker would send email to a fixed
account, with specific subject line, to post information. The programs
would recieve the mail, probably send forward them to other quarters if
more action was needed, other wise, post them to a status website.
Questions to the remote worker could be sent via the website, or via job
specific email, and the programs would deliver them.

Why this example? Because, i see that simple scenario also as a web
service. Well... its email driven and all, but all the application is
doing, is sending data across resources accessed via known URI's (email
addresses in this case).

Scoot back to present. Without much of reading on Web services, I built a
webservice that looked just like the Amazon REST webservice (see the
onlamp.com article above). How did that happen? Well... because that's
the natural way to think about Web services for anyone that has done even
the slightest amount of network or related programming. Of course, in my
case, i couldn't afford to pass XML message, since my device was limited
and bandwidth precious.

Combining the email and web scenarios above, leads me to think about TCP
against UDP. Connection oriented vs Non-connection oriented. I don't
know if its just me, but does any other person see these similarities.
The email based app i described above, didn't need to be in real time.
Results were generally expected in Hrs of requesting, so there was no
need to establish a connection and return results immidietly. In the
case of the device that needs to interact with a database, we need
results, right now, so we use HTTP. It just seems... natural for me to
think this way.

Now, i may be seriously short-sighted, and to this I admit, but I really
can't think of a problem that i can't solve with these methods (i am
classing EMAIL delivery as a non-connection oriented REST architecture).
It seems any other thing should just be a neccessary abstraction of
this, in forms of libraries to make these easier to do. Infact we
already have a wealth of opensource tools for dealing with most of what
we need. Wget, mailx, fetchmail, getmail, etc. There are also libraries
in almost any sane language you can think of to make these easy to achieve.

Without diving deeply into SOAP/WSDL, I've not yet seen what I'm
missing. Maybe its because I've never really been a fan of RPC. I just
don't like it. I prefer message passing, and not object passing and in
all my years of programming, I'm yet to see a scenario i couldn't
elegantly solve with message passing, that was also not simple.

Of course, I could be missing a point, but I'm yet to see it. I think
sometimes when "Software Architects", get together to come up with
ideas, they get carried away. Maybe it is because some of them have left
active coding for a while. They seem to look only at systems, and ignore
the easy (permit me to say lazy), truths which would be otherwise
obvious. The also ignore that sometimes, implementers/developers who
actually use these technologies, prefer transparent solutions that they
can hack at, and are easily layered on what is already simple, known and
proven. HTTP has that quality, EMAIL has that quality (what's more, the
GSM service - SMS, also has that quality). I always believe abstraction
should make transparent solutions a breeze to work with, not introduce
yet another layer you have to learn all about on top of what you already
know.

In conclusion, Web services are here to stay, this is a given. Is the
future SOAPy or RESTfull? I don't know, I can't say. What i do know is
that REST is truly transparent and simple. Also, I hope that the REST
definition of Web services, should broaden to include such communication
channels as email and sms. This I think should be the next step of
Application development and delivery of information, even as our need
for information and our ability to communicate increases.

REST is very simple, as such, i don't see it fading away anytime soon.
The new direction SOAPy web services seem to be taking is also good and
somehow has the advantage of being transport mechanism agnostic.

What I say? 'tis all good :)

Wednesday, February 16, 2005

Ramblings on Good-Code (Non complex code)

Ramblings on Good-Code (Non complex code)



What you see is actually what you get.

In an
earlier article of mine, I talked on programming style as a method of producing good code and harped on the idea that bad programming style can be identified by looking at the code it produces. Of course the obvious corollary of this is that good programming style can also be identified the same way. My key identification trait was that bad code is inherently COMPLEX in a whole lot of ways, but probably most glaringly, and easiest to identify, is that bad code is VISUALLY complex. In this article, I go to more depths in defining what I call Complex code and non complex code.



1. White Space

When you take a look at a program source code, the main things you see are the identifiers, keywords, etc. But there's also the things you see that you don't know you're seeing: Whitespace. Now this is probably a hilarious proposition, but whitespace can make any piece of literary art (of which I say programming is one. you don't agree? BYTE me :P ) look good or bad.

If I compress all my code without adequate spaces between them, in languages like C that have statement separators, the compiler will have no problem with that what so ever. The problem is that programs should be written to be read by other humans. So while the compiler has no problem reading and compiling that code, another human will have enormous issues just trying to find where what ends and where the other what begins. This you will agree with me is important, but few people consciously make sure that their code is spaced properly.

Usually when I look at wrongly spaced code, or rather not so well spaced code, my lazy brain does a quick back track, and my mind goes into "Oh no!" mode. Then I usually shift closer to the screen and try to look more closely, while under my breadth, secretly saying not so amazing things about (cursing? :P ) the person that constructed the horror I’m being forced to decipher. Wouldn't it be much better if I could lounge back in my seat and understand the code? At least for me, it would be way preferable.

Consider:

/*...other code here...*/
long *c=(long *)malloc(SIZEOFLONGBUFFER);
for(int i=0;i<=MAXSIZE;i++){
array[i]+=*(c++);
}
printf("array[%d]=%d",i,array[i]);
/*...other code here...*/


compare this to:

/*...other code here...*/

long *c = (long *)malloc(SIZE_OF_LONG_BUFFER);

for(int i=0; i <= MAX_SIZE; i++) {
array[i] += *(c++);
}

printf("array[%d]=%d", i, array[i]);

/*...other code here...*/

Correct me if I’m wrong, but don't these two code segments actually seem at first glance to be two totally different programs doing two completely different things? The first one, seems to be a rather nifty program doing some complex stuff, but the second one, looks like a regular cheap program.

Well... My point exactly. The first program looks complex, while the second one doesn't PERIOD.



2. Variable Naming and code homogeneity

In the Unix world, lower case rules. I figured it’s because of laziness at hitting the SHIFT keys. The problem arises when your variables begin to get long. For instance using lower case on 'variable' is not bad, but using lower case on 'aratherlongvariablename' is plain wicked, and forget it, there's no how I’m going to read that variable name each time I come across it. This is the reason why I may not pick up that there is actually another variable like 'aratherwrongvariablename' or another one like 'aratherlongmaredname'.

Hehe, see? You're already tired of deciphering the names. Of course, good programmers don't do stuff like this. They have various ways of solving this problem. UNIX and C mainly 'used' to do use the _underscore_. So transforming becomes 'a_rather_long_variable_name', 'a_rather_wrong_variable_name', 'a_rather_long_mared_name'. These are much easier to look at. Java and C#, and I think in general OOP languages prefer the Capitalized approach of: 'aRAtherLongVariableName', 'aRatherWrongVariableName' and 'aRatherLongMaredName'. Well, I’ll leave you to figure out which you prefer (I prefer the underscore because of the simulated white space, since I can read it while lounging back in my seat, but that is another matter altogether, so lets not get religious now).

The other part of importance is that no matter which you prefer, in any single project (and preferably, related projects, or projects done by the same team), that the style you choose be pervasive and consistent throughout the project(s) to cut across as pleasant.

When these styles are mixed, the results are rather unpleasant to the eye. Basically, mixing these styles makes the source code look haphazard, and introduces the "Oh No!" factor yet again. Probably more importantly, it sets a precedence of confusion on a non-thorough attitude in the life of the said project. It then easier for a programmer coming behind you to get worse at what you’ve started, and it will make a brilliant hacker have a bad first impression of the project.


3. Code Density and Contained Units

Now this is a very interesting one for me, but anytime I have more than a certain amount of code before me on the screen, I begin to panic! I myself don't know the particular code per screen density that finally gets to me, but its there.

Dude!!! Get Real!!! Well, I’m getting very real, and when I write my programs, I try to ensure that I don't have too much before me at anytime. Another good thing is that if you use white space properly, you won’t reach that point.

Well, this is just one part of the story. The other part for me is that once a source code file begins to get long, I panic while debugging it. Well... now you're certainly a joker! But wait, let me explain things a bit.

The human mind has a large capacity, but usually, we don't remember a lot of things, in fact, we usually only remember things that make us think of other things that we like. This is called Association. If the human mind can associate a vast amount of things it can remember them very clearly. The point I’m making is that I usually find myself thinking that a source code file is long anytime I begin to find unrelated information inside it.

Okay, so you don't get my subtle point yet? I'm talking about Code Modularity at its very aggressive best. By all means, use functions in programs, and let those functions be short and straight to the point, also let them do one thing and do it well, and then also, group related functions into a single file (for OOP guys, these goes for classes).

Imagine a file that contains functions for manipulating JPEG images, and at the same time contains functions that manipulate the serial port. Each time you open that file to look at it, you brain is pulled in two directions, and you have the feeling, (at least I do), that this file is too long. On the other hand, If I split this file into two, the way any sane person should do, apart from getting a physically smaller file, I also stop my brain splitting in two directions. Another true fact, is that once I’ve split up the functionality in that file into two separate files, those two files, can ONLY grow SO MUCH during the life of that project, hence capping your code density per file again.

On the OOP front, I don't have to cram all my Classes in my Namespace into one huge file called Namespace.bleh. I could and should probably split them up into various classname.bleh files or something like that. You'll find that doing this actually puts a real constraint on how large a source code file can actually become. Sometimes of course, it will still grow very large, but I’ve written a number of software, and I find that once a particular file starts becoming very large, there is usually another file inside it itching to come out or the coder is not being lazy enough to refactor repetitive tasks out. And the same goes for Functions... once your function starts becoming large, there is usually another function inside it, dieing to get out.



4. Global Variables, Debug-ability and Function Parameters: (My beef with OOP Class Member data)

Usually, talking to an old programming hand, you hear such phrases as “GLOBAL variables are evil, avoid them at all cost!”. Hmmm... why do they say that?

Now imagine you have this 1000+ source file (uhh... couldn't Point 3 have helped us reduce this, unfortunately, not always, and like we’ve seen, if you keep related information, it won’t actually cut across as too large), and you're stepping thru this segment of a function somewhere at line 870, and you suddenly come across a variable with a value. You're trying to explain how it got there, and you can't. You look at the function itself, and it wasn't declared there. You look at the function parameters, and still it isn't a function parameter, alas, it has to be a global variable, well... you scoot up to the top of the file, and true enough, it is defined as global (or worse, an extern global!!!), but alas, you don't know where that value was modified, and you've set your break point so far below in the file.

At this point, you begin to hunt thru the file looking for where the variable may have picked up its value from. Finally you find it. Phew!!! Again you've wasted valuable time. If this is just a single variable or a few, no problem, but imagine when you have them everywhere in your program, you have to keep scooting upwards and downwards in a file, looking for various variables. I really don't like that.

My solution to this, is to pass variables around via function parameters. This really helps debugging, since it’s probably easier to tell where a function got called, hence where its parameters where set, than to find out where a variable that is global was assigned to or modified. This is another time ‘shaving’ feature that I usually appreciate anytime I encounter it in a well designed program. Moral of the story... well... I don't know if Global Variables are EVIL or anything so exotic, but I do know that they can make my debugging session more hard work than it should be.

Now what of my beef with OOP Class Member Data?

Well... OOP Classes makes it possible to use Global variables under a new name, but of course the effects are the same. Without good design, Class Member Data pervade a class, and turns debugging into a serious nightmare. It is usually a huge joy to me when I use a class that minimizes its use of Class Global Variables, and even when it uses them, it sets their values in easily deduced places.



5. Libraries

A library is in my opinion, the most important outcome of a software project. Why do I say this? Well, the problems you solve today, are still going to be around tomorrow, so if you've solved it today, why tackle it all over again tomorrow? Why not just solve it once for all today, and reuse your solution tomorrow?

This may seem like an obvious truth, but you'll be surprised how many software projects get finished these days, and there is ABSOLUTELY no library developed during the period it was being built. The excuses normally range from Time Budget, to Deadlines, to "those things need a bit more planning".

NONSENSE!!! That is my reply to those excuses. A good programmer is supposed to be always on the look out for functionality that can be factorized out. These functions/classes make up your library for solving specific problems.

For instance, I just started a personal project to help me manipulate Shellcode on Linux in various interesting ways, during the short time I was researching, I was adding functionality to the program as I progressed, but at each stage, as I added functionality, I was always asking... hmmm.... should this be a function? Won't I need to do this again? Aha! I've done this before! Uhh... I really don't want to solve this using this long method, what have I written already that I can modify to solve this as a generalization.

The result of this continuous introspection, which I didn't have to stop and plan for, is currently a library with 5 functions, at the time of this writing. When it became obvious that I was saving myself, was when I had to extend the program to manipulate some environment variable address, and I suddenly discovered I had already written the functions to do smaller parts of what I wanted to do, I just needed to combine them in the main program.

The art of creating libraries as you write, is so important to software development, because in my opinion, it marks a truly active mind that is constantly searching for innovative solutions. The other approach, is to plan the library and tackle it like a project on its own. Well... I guess this works too, but I’m beginning to see that libraries built while solving an actual problem seem to have more utility than libraries built to solve a problem. Hehe... that seems like a contradiction, but take some time to think of that and you will get what I mean.

That is also in my opinion, the crowning difference b/w TOP-Bottom and Bottoms-Up programming. But so many other people have done justice to that topic, that I wont' bother delving into it, at least in this article.



6. Idea Cohesion and Single Point of truth (SPOT Rule)

I learnt about the SPOT rule in Eric Raymond's 'The Art Of Unix Programming'. It essentially says that one thing shouldn't happen in more than one place in a program. Of course, this is serious paraphrasing, but that's essentially what it means in my own understanding.

Practically, it means being on the lookout for multiple areas of code performing the same function or almost the same functions that could be easily made into a function that will exist in only one place, and can be called from many places. This way, there's only one place in your code that you'll ever make changes to, and once you've located it, it keeps debugging and maintaining interesting and relatively stress-less.

Well idea cohesion is very similar, but it’s broader than just actual code functionality. It’s more like Single Point of Logical Truth. What I mean by this is, to keep closely related functionality (logically related in terms of the problem scope), together. This again may seem trivial to some, but imagine if you're looking thru an Class Definition that overloads operators, and right after the constructor, you see an overloaded + operator, then you run into some property definitions, some 3 to 4 functions latter you run into the overloaded - operator. Hmm... sounds funny? Believe me we sometimes do something akin to this. The problem with this is that, it gets hard to predict where in the file a function will be. This may not seem important, but personally (and I believe lots of programmers are like this too), like to think only once about something. I like to be able to say, with a 98% certainty that something will happen in a way, or be in a place, after I’ve studied the situation. This translates to my being able to intuitively know where in a jungle of source code a particular functionality will likely be. It really saves me debugging time.

The other major part of this, is grouping ONLY closely related functionality into ONE source file. I know I mentioned this in point (3) above, but just to emphasize it here again. Being on the lookout for this, works two ways, it helps tell you when your file is getting too large and it can serve as an indicator that you should probably be building another library that is dependent of this one, instead of adding to this one.

Doing this also helps force you to properly define boundaries between your code components. This will come in handy especially during maintenance and debugging where it can help to keep things focused and simple.

7. File Naming

This one can go unnoticed for a long time, if developers on a project doesn’t change, but once developers change, you find that its helpful to give files the most obvious names possible. I was recently working on a C# project (legacy code), that had slight variations of a single data processing engine. Apparently, when the project started, the first processor class: AEngineClass was built. The class file was also named AEngineClass.cs. As time went on, another class of the engine grew up for a slightly different scenario, and was called: BEngineClassWeb but because (okay…I have no idea why), the file was also named BEngineClass.cs. This may seem trivial, but currently, for that project, there are many of these XEngineClass.cs files, and you’re never sure which one contains just the XEngineClass or XEngineClassWeb classes. This recently took my PRECIOUS time because I was setting a break point in the wrong file!!! It would be simpler and better if all XEngineClass classes were stored in XEngineClass.cs files and XEngineClassWeb classes were stored in XEngineClassWeb.cs files.

Anyway, apart from that, giving your files obvious names, can help tell you in refactoring code!!! I’ll say it again… naming your files correctly, with obvious functionality driven names, can help you refactor code. On a java project I worked on recently, I had to build some custom libraries, and one of the classes was a Utilities, class for collecting odd functions I could reuse across other projects. I started by dumping all kinds of functions there, pretty soon, I had a couple of Persistent Data handling functions, so I decided it was time they had their own Class and file. I pulled them out into a separate file under a separate class. Once there were there, I started seeing a pattern in the code (that had always been under my nose, but was sort of cluttered up with other code), and immediately I refactored most of the functions there. Two things happened here. Firstly, I delayed pulling out the Persistent Data handlers into their own class and file, till there was a real need for it (my Utilities class, had gradually started looking like a Persistent_Data_and_Utilities class. Secondly, once the handlers where properly separated, refactoring needs became obvious because of reduced code density. It’s easier to see stuff when there’s almost nothing to look at.

Right now, I’m aggressively chasing away all my wrongly named files in any project I’m working on, and I’m seeing returns immediately, both from me and from my co workers.



Conclusion: (For Now)

At this stage, I’ve (probably not exhaustively) described what makes me feel that a code base is complex, and that I’m wasting precious time on it, that could have been used to do more interesting things.

So far, I know I’ve said a lot that will make some folks grin with recognition and other shake their head in pity (for my ramblings?). Well, I've tried to articulate my own observation as realistically as possible. The key here is in developing a good nose while programming. A good nose (hmm... I should write on that too), will help save your valuable time in future and a bad nose... well... it just blows… literally :)

Friday, February 11, 2005

Enterprise Devices and The unplugged Enterprise - The final Frontier

Someone remind me again, why, oh why, do I love programming?

Well... silly, because it provides a whole world of challenges daily, that are different and satisfying to conquer.

Well... that was till I came across some kind of programming that TO ME is very boring :(
This is what some people tend to call Enterprise Development. I don't know if its just me, of its the type of enterprise development that i've seen, but all the usual Create GUI, collect data, stuff into Database, retrieve and print report, is sort of tiring.

Don't get me wrong, GUI apps in their own right are not exactly boring, or are database apps boring... but when the same kinds of problems keep being solved over and over and do i need to add over again... my!!!! its kind of brain deadening... its caused me to commit the most cardinal siin of all programming - Resort To Cut/Copy and Paste :(, then edit to make sure it runz.

Sheesh!!! that's how low, boring can actually get.

Anyway... I just sent in the last milestone on a darling BlackBerry project i've been working on, that took me away from the uhh... other drudgery i mentioned earlier (no offence guys), and wow... its really been a breath of fresh air. So i decided to ask myself, why did i really enjoy working on this project? By the way, I had to use Java, which I don't realy like, and work on Windows, which I really dislike, so why did i really like the project?

I think it was because first of all, it was a new area to me... I've never worked on the BlackBerry before. But that's not the most important thing I found out. The most important thing I found out was that it demanded various divergent knowledge from me that i've acquired over the years, and not used in a while.

I had to build a poor man's simulation of an embedded database, among other things. I had to write some PHP webservice like exposures, which were connecting to a real database, and ofcourse, there was the BlackBerry's limitations in size and speed to keep me in check. But these things kept bringing out the fascinated kid in me. (Is it a coincidence that back then when computers where very limited we had few bad programmers, and plenty good ones, but these days the reverse is the case?)


Something else that i think mostly facinated me during this project was that i wasn't thinking only on this project. I kept seeing other BlackBerry projects, and each time I made a decision, i would wonder how much i could factor out into a library that will make my life waaaaaay easier later on. Infact, I think i had the most fun building the library I ended up with.

I think the best way to make software development fun, is to code correctly. If you have repeatitive tasks... for the sake of all that is scriptable and runnable, automate it, or probably, continously factorize and build a library... you then free your mind to serve higher more interesting and important problems... like... e-beer? :P

Part of the reason why I disliked the other 'Enterprise Apps' i've been working on, is because they are legacy code, and the code base is very unfriendly, and not-so-well-done. Its a pain to maintain that. Its a huge waste of valuable brain resources, which are bound to ebb up and down during the course of the day, on uncovering the wit of a badly written program :( it just makes me want to cry, but I seem to see that this apparently is what 80% of programmers go thru everyday. I'm not alone it appears, but can't we change that as we move along? So others that come after us, don't suffer like we did?


Scoot back to the topic. The other probably main reason why I loved the project (hehe... i have a lot of main reasons flying around this article), is just simply because I love programming devices. They are like toys to me, and most importantly, I believe they are the future of pervasive computing. I think Enteprise apps should begin to involve/include device enablements. Enterprise apps, with the help of webservices, email services, SMS services, etc, should begin to enable the rugged road warrior so he/she can work from anywhere.

This last frontier, is probably the most exiting part of computing, second probably only to the first frontier (system programming and OS's/device drivers). I feel so strongly for this aspect of development I want to see it come to fruition. The company we outsource for, is beginning to sell the idea of the unplugged worker to their existing client base, and I tell you... there is soo much that can be achieved. Business Intelligence reports and indicators can be PUSHED to devices, coporate knowlegebase searches can be initiated from devices, alerts can be broadcast to field workers... the potential is limitless... realy limitless.

Oh well... now that the little bit of Python Hasish i took earlier while at work has cleared, i think i can now wind down to a lovely Friday nite and let you o dear gentle reader off the hook too... :D

Adios :)

Thursday, February 10, 2005

Testing and The Tao Of Programming

This evening and yesterday evening, I came across some articles by Martin Fowler, Kent Buck and Uncle Bob J

http://martinfowler.com/articles/designDead.html
http://www-128.ibm.com/developerworks/java/library/j-beck/


This has really set my mind alive and thinking… Xtreme Programming huh?

Well… if I had to say something about Xtreme Programming, I’ll say that Xtreme Programming is a covert operation, mounted by pure hackers, to introduce hacking at its hackiest into coporate bodies. I’m kidding right?

Nope! I’m not. Why do I say this? Well… I first started programming on DOS, back in the day, then naturally went on to Windows, and UNIX then was like a fairy tale to me. When I finally happened upon Linux, and started using GNU tools and read The Art Of UNIX Programming by Eric S. Raymond, I was rudely awakened from my fancy world, into a world I had always wanted to be in. I suddenly started learning to program in what I would call the ‘UNIX’ way. The experience was transforming. I never really wanted to program any other way again. UNIX among other things advocates small programs that do one thing and do it well, then with the help of powerful paradigms like pipes, source, filter, drain, these small programs can then be combined in ways the author never even thought was possible.

Well, I discovered also that building programs like this, reduces programming to tool development, so that a software project results in a set of tools that can be reused latter. Truth is, I slowly learned to love the C language because I was using it like it was supposed to be used. What am I getting at? I’m getting at the fact that apparently, a lot of the things I’m seeing in XP materials (not all of them ofcourse), have been exiting in the UNIX C and Perl worlds for ages, but relegated to ad-hoc hack projects. Infact, no serious programming house would hear of such practices.

After delving into some of the XP materials, I’ve been having this sense of Déjà vu, like… wow… hackers have finally found a way to sneak our secret lives and programming practices from our personal projects back at home, into the office environment, so now, we can work the same way at home and at work… big thanks to Kent Buck and all the proponents of XP.

I worry a bit though, about why this didn’t take off much earlier, why now, and why the big noise, when really its not sooooooo new (UNIX is basically a result of Xtreme Programming, before it was called Xtreme Programming, IMOHO). I think it’s a big pity that so many of us get caught up with buzz words, and we only needed another ‘buzz word’ to awaken us to the way things should be done (as they’ve been done for a long time too), I’m not reducing the effectiveness of Xtreme Programming by calling it a buzz word, but I was always wary about it since It was buzzing around me, till I decided to find out some more. If this is of any importance, I think it’s one of the few buzz words around that merit to be a buzz word, but the danger is there that since it’s a buzz word, there’s going to be soooo much misinterpretation and misappropriation. Good thing is that at least… its here finally and is being accepted corporately, so one doesn’t really have to fight much, to introduce personal hacking practices that U KNOW works, into the work place.

Now about the topic, there’s a section in The Tao Of Programming that says:

Prince Wang's programmer was coding software. His fingers danced upon the keyboard. The program compiled without an error message, and the program ran like a gentle wind.
``Excellent!'' the Prince exclaimed, ``Your technique is faultless!''
``Technique?'' said the programmer turning from his terminal, ``What I follow is Tao - beyond all techniques! When I first began to program I would see before me the whole problem in one mass. After three years I no longer saw this mass. Instead, I used subroutines. But now I see nothing. My whole being exists in a formless void. My senses are idle. My spirit, free to work without plan, follows its own instinct. In short, my program writes itself. True, sometimes there are difficult problems. I see them coming, I slow down, I watch silently. Then I change a single line of code and the difficulties vanish like puffs of idle smoke. I then compile the program. I sit still and let the joy of the work fill my being. I close my eyes for a moment and then log off.''
Prince Wang said, ``Would that all of my programmers were as wise!''



When I first read this long ago, I used to ponder and wonder, yeah right… this is good writing but it isn’t practical. Still a part of me kept trying to strive for this kind of programming perfection. I realize one thing now. It is possible (With Test Driven Developement).

I’m not right now going to strive for the one-write-on-compile-no-error part, but the run-once-like-a-gentle-wind part is what I’m striving for. Before reading up on Unit Tests, I’ve been doing it somewhat improperly. What I’ve bee doing while coding these days is that, write small sections of code, and run them with various inputs independent of the rest of the program before I move on to the next stage. I’ve not been using Unit Test frameworks and collecting all those tests properly, but I’ve been doing it, and my code has been better, without even much need to use a debugger to debug.
I picked that up from adopting what I called earlier the ‘UNIX’ way. Well… now that I’ve learned a bit about organizing the tests more formally, I’m going to adopt it, its just going to be a mere scripting of what I’ve been already doing. One of the huge benefits I can see about formalizing it into the source tree is that, its going to help some other programmer latter, and that is always good.
In conclusion, I’ll say… hackers are finally taking over the world J

Wednesday, February 09, 2005

Moving BACK to the future

I just spent the whole day indoors…. Was I sick? Nope…. Was I snowed in by a crazy blizzard? Nope, was I even Tsunami’d into hiding? Nope… wat I was, was CURFEWED!!!! Yup… I was grounded by the indigines (is this spelling correct? I think not ;) ) of Abeokuta, because the King of the town is dead, and part of the ceremonies demands a ONE DAY CURFEW!!!!

Yup you read me right… a one day curfew… not a public holiday, not a general relaxed sort of work free day, but a blatant curfew… ok… I’m just getting to the point where 4 lettered words may begin to flow, so I’ll stop there.

But this got me thinking… come on.. guys… we have a democratic system and people from all over the country residing in this town, but why the heck will the government allow this to go on? Don’t get me wrong, I’m respectfull of tradition and values and stuff like that, but I think this is waaaaaay overboard… what happens if someone came in from the east, and didn’t get to hear of this, and drives into the town?

Oh well… I was just sooo strange to me, because where I hail from, when our king dies, the curfews are at night… which is reasonable… I think.

I just think that today we zapped quickly Forward to the PAST, or BACK to the future… depending on how you prefer to think… and whatever justifications may be put forth, I’m totally peeved L

Anyway… ‘tis my blog J

Tuesday, February 08, 2005

minor Ramblings on Documentation

Project documentation can not be over emphasized I think. One of my worst nightmares came upon me while at work today… namely: The only one that understands the code is the guy that built it. L

 

Not very good. What we’re trying to do at work now, is to include a document that gives a high level explanation of the overall workings of the code. The last time we discussed this, there were lots of talks about UML diagrams, Use Cases, Object Relationship diagrams… phew… the whole works… well… I think they’re all cool, but I have some beef against them.

 

Some of them take for granted that you’re working with an OOP Language that has all the bells and whistles… classes, interfaces, inheritance, polymorphism. Well… I may be wrong, but I think in so doing, they are limited to only truly defining problems solved with these languages. Presently, I work (by day), in a mostly .NET outsourcing company (tho, we’ve been expanding recently, I guess due to guys like me self J uhh… who am I kidding? ), so it would seem unnatural for me to critique these tools with this particular line of thought.

 

 

Well.. why I went in that direction, is that I KNOW from experience that not all problems are best solved with OOP languages… so a better method of documentation SHLD capture non OOP based solutions. If a method exists that can do this, its probably a better method of documenting code.I probably need to read more about UML and the rest, but right now, I think Eric Raymond’s Advice resounds in my ear really loudly, “By All means… be textual”.

 

This I believe has its pluses and minuses, for instance we all know that a picture can be worth a thousand words. I think a neat way would be to combine them neatly.

 

I favour textual because it mostly forces the developer to think about the implementation and then describe it in words… there’s in my opinion no better way to reflect on something you’ve done, than writing about it. Diagrams should be used to describe areas that would really benefit from using diagrams too. As you can see this approach doesn’t really have a name, but its simple and doable (I think…)

 

With this approach too, problems solved by Functional thinking can be described fully… and also norminal imperative approach is not left out. And probably more important, is that the implementation idea is conveyed, not the nitty gritty of the implementation which should be apparent in good written source code.

 

In conclusion, I’ll say, ofcourse, I may be blind to many existing facts, since I’ve not researched this, and I’m just writing after a hard days job, but why I think its important is that this is field experience… as opposed to theoretical stuff… so maybe there is something of importance afterall in what I’ve just said.

 

Just ramblings from a guy trying to get better at his job, and make life easier from those who come after him.

Monday, February 07, 2005

Mad crazy monday

Oh boy… today is off to another crazy start.

 

I managed to squeeze off another release for BerryTime today (my baby BlackBerry project), no word from QA team yet, I guess they’re busy on other stuff, but I’m pretty confident it’ll pass thru first round. The way I’ve been applying testing to my code these days… things hardly break. I’m learning a lot from lots of open source guys.

 

I’m pretty much confident that any programmer that wants to be a better programmer should get involved in some (oh men.. this one might get my hide and skin :-s), non-windows-driven open source project (unless its GNU for windows prolly, or some real C hackers project). You’ll learn a LOT of good coding habits.

 

I’m also seeing more and more that UNLESS you have good mentors, OOP Language only code-slingers are not very good overall coders. I’ve been using Java for this BlackBerry thing, and yeah, I’m not exactly a java guy, but man… the language is really tempting in the bad manners its encouraging me to use. In C, I’m very wary about Global variables, but men, these guys are really disguising themselves as class wide variables, package wide variables, etc. I can see the mistakes about to happen, and I just can’t see a more OOP way of avoiding them without having realy crazy looking code, at the expense of modularity and reusability.

 

I’m very interested in what will happen to the language ‘D’ [http://www.digitalmars.com/d], that allows you to mix up OOP and non OOP code. That’s the way I would have solved some of the problems I’ve been encountering, and also the reason why I’m crazy about Python. These languages don’t force concepts down your throat. Anyway… enuff said there I guess.

 

I still have to trash out lots of fixes trickling in on a HUGE database related project we inherited (oh men… do I hate dirty inherited code L ), and more are still trickling in. lets see if I can make myself into a hero by fixes most of them before morning… darn… here I go again, after a near breakdown last week J I guess I just can’t learn now, can i?

 

Yeah, did I mention I finally subscribed to the linux-kernel mailing list hosted at vger.kernel.org.  yup… it means I get to be on the same mailing list as Linus, Andrew Morton, Robert Love, Chris Wright… wow…. Right now, I’m just listening on conversations and trying to learn from the technical stuff and the non-technical aspects. For instance, Linus seems like a very respecting kinda guy, and Chris seems rather humble… its interesting… ahh.. okay.. its just cool J

 

 

Whooo… I’m planning to start contributing somewhat, but I’ll not rush things so I my enthusiasm doesn’t get swept away by a mood-tsunami, instead, I’ll just allow my interest to mount gradually, and I’ll prolly start cleaning up with other Kernel Janitors… so hey… wish me luck ;)

 

 

 

 

Sunday, February 06, 2005

Code Hangover

I’m just recovering from a code hangover.

 

A what? Yep you heard me right a code hangover… ok… some may call it writer’s block, creative burnout, whatever… but in the latter part of last week, I had one of those very irritating seasons during which nothing creative can occur in your mind.

 

The annoying thing about this is that sometimes, you can feel ideas just floating out of reach, but the mind refuses to grasp and hold onto them. Baaaah.. coupled with some minor headaches etc, I think I came to the conclusion (AGAIN!!!!!), that I’ve been pushing myself a bit too hard for no reason at all. Uhh… well… not too true, but for the sole reason that I love what I do so much I don’t even know when its harming me.

 

Well… this week, I’m gonna have to get thru with more brawn than brains, as I have some rather interesting/plentiful problems to tackle on the work front. Oh well… there I said it.

 

I’m going to have to study how frequently these burnout sessions occur, lets see if I can isolate a pattern to it, and have a logical explanation, tho I suspect this last one came because I’d not been exercising as usual in the past one month or so… I think what happened was my muscles went lazy first, then my brain got used to it… pretty soon, my mind locked up.

 

Moral of the story: No matter the excuse, don’t break you exercise schedule especially if you do lots of brain work J

 

Naaaa… this is not really me in my all ranting glory… so for now… I’ll leave with a parting comment shamelessly burrowed from – U KNOW WHO:

 

“I’LL BE BACK!”

Tuesday, February 01, 2005

Code Ramblings: On Coding Stlye

Code ramblings: On coding style

[Due to an interesting comment by Stan, I changed this title. It was formerly 'On Programming Style']




I've been thinking a lot about how to program and program properly. I've read a lot of material about various approaches to programming, combined with the very basic introduction I was given in school (Top-Down Programming), and I’ve had to rethink a lot of things. I've come to a conclusion that the most important thing that a programmer can learn about programming is not the language, not a paradigm (OOP, Functional, etc), not even how to debug (NOTE: these are very important things), but the Programming Style.

I’ve also come to the conclusion that what eventually differentiates a rookie from a master, a code-smith from an apprentice is the very thing – Programming Style. But wait a minute. Are we really interested in style? Is it not product above style that we’re keen on? Well, I say good style gives good end result. And a code-smith with a formidably excellent and effective programming style will at any given time be much more productive than a set of mediocre programmers with mediocre programming styles. But let me not get ahead of myself.

In this article, I’m going to just ramble about programming style in an effort to bring it to fore as a stand-alone concept, not as a part of other concepts. This is actually important, as once someone realizes that there actually is something as programming style, and that it can aid your productivity, you can begin to actively seek to improve it.


An ad-hoc definition

What is programming style? I think of programming style, as everything the programmer does, in the particular way he/she does it, from the moment a problem is encountered, till the moment a version of code that solves the problem is released and throughout the lifetime of the code base. This definition encompasses language choice, solution paradigm, documentation, every single thing that will be done. It starts becoming a style when you use that process more than once, and even more so, when lots of other smart programmers adopt that same methodology.

To be very effective, your programming style has to evolve into a habit, such that it is now done unconsciously, instead of as a series of steps you're following from a company documentation manual.

Making time for important things – The lazy programmers creed

In all my writings, I especially clamor for a type of laziness. In fact it would be correct to say that I advocate certain laziness. This is the flat out unwillingness to do more than I have to do to solve any given problem. If I have two bags to carry upstairs, I WILL carry them with both my hands (hopefully, I’m powerful enough), instead of taking two separate trips. Trivial example? You’ll be surprised to what this translates to when coding.

With this in mind, allow me to say that first and foremost, I think the best programming practice is the one that frees you up to do more important things (we could also say that the best programming style encourages laziness – not slothfulness). What is my definition of more important? I think important == interesting. Why I increasingly take this stance is that usually people are more productive when they do things that they like, and those things are generally interesting to those people and to them, it is very important. Imagine a house with a youngster and his dad. His dad probably wants to watch the News (which we all know is very important. no?) but the youngster is keen on catching up with the latest Johnny Bravo flicks (ok... scratch the youngster... I’m a Bravo fan meself :D). In the scheme of things from Dad's perspective, News is more important, and you may disagree with me here, but I say, that's because he LIKES and is INTERESTED in events. From junior’s perspective, Johnny Bravo is WAAAAAYYYY so much more important, again because he likes and is interested in Johnny Bravo.

So what has this got to do with programming style? Well... programming, depending on your reasons for getting into it in the first place, can be like a door to fulfill your dreams of assistant-godhood (hellooooo?), or it can be just a means to pay the bills. For those that are aiming for cyber immortality, they usually have some specific areas of interests. This doesn't come from the first day you start programming. For instance, I’m certain that most engineer-programmer types have solved matrices programmatically, and it was mentally stimulating to do that, but as you grow and your specific strengths begin to shine thru, you begin to get fascinated by a problem area. For instance, some programmers are crazy about Application development, advancement in user interface designs, while some get something akin to a drug-induced high, when faced with writing their own OS Network Protocol drivers. (I mean, how else can you explain someone who implements an IRC chat client in Assembly? uhh... okay I confess, I want to do this too...) These various programmers are bound to regard different problem areas in a project as more interesting (interpret as important).


Let’s imagine jumping these two groups of guys to implement an IRC client for a modern GUI-drool-able OS. The usability guys will be concerned about Look feel, placement of widgets, colors, general feel of user, while the net-heads will be concerned about what they (wrongly?) believe to be the main push of the application. Both these guys if they can complement themselves will actually make a very good piece of software. More importantly though, will be if the resources working on the various parts of the project are aligned to their particular areas of interest. Of course, since they work in the same company, they probably know very much of programming and can work on any area, but if a sworn protocol-freak is solely responsible for GUI development in a project that COULD have had a true usability faithful on it, then I’m very convinced that results will be less than desirable. Maybe not glaringly so, but it will be there.

One question arises: how realistically-achievable is this? In a small programming team, the argument is that this is a fantasy that can not be indulged and that programmers should get realistic. True to an extent, but I’ll "ramble" about that at another time.

The main thing I’m about here is that the net-head that is working on a GUI project will prefer a programming style that enables him to finish the project quickly enough, so as to start on an area/project that he's been told is waiting for him and is more of his area of interest. Or to get home to his pet project (which these days is probably an Open Source project)


Identifying Programming Style

Programming style is IMHO more of an art than a precise science, as it becomes more obvious that GREAT programmers can be more likened to great artists... in a lot of ways... and a quick and dirty hack is generally more understandable if you think of it in terms of a rough art sketch. With all the subjective things flying around, it’s very difficult to have a precise definition of Programming Style. So instead of giving a precise definition, I’ll examine its end product.


Code Complexity

A lot of beginner programmers are first intrigued by how complex things can get in their beginner programs, if they just get a little bit more imaginative. In fact, I used to play an unnecessarily-obfuscated-complex-code-segment game with myself back then. I would try to see how many tricks I could use to solve really basic problems. Of course, as maintainability becomes an issue, complexity shows itself like a not-so-good thing. Of course some areas can't do without being complex, but when complexity is the norm, not the exception, then that is one programming style that can result in some rather difficult to maintain projects. But this is not totally all I’m referring to when I say Complexity. The complexity I’m referring to is more subjective than objective, but nevertheless, it’s very important.


The “OH-NO! Factor”


As a result of programming style, I feel that if I look at a piece of code not written by me or not, and I get the feeling of "Ohh... men.... do I really have to figure out how this thing works?", then it’s probably more complex than it should be. Now I say this in a balanced way, and I’m not using myself as a benchmark. Typically idiomatic constructs can look complex to a beginner, but perhaps more than the actual coding constructs itself, you take a look at the source code and you just get a feeling. It’s like what can happen if you look at a runaway Perl programmer’s code - Your initial feelings are "OH NO!!!" (I have not said all Perl programs are like that, that's just an example). It just feels and looks complex, eventually though, if you take time to look thru it, it may REALLY NOT be as complex as you were thinking, but the time you spend looking at it, could have been well spent doing more important things (interpret: more interesting things). And don't forget that the best programming practice works to free your mind for more of these things.

This complexity for me particularly is a great deterrent. It normally takes me more mental preparation to begin to get into this kind of complex code, and already I have a bad feeling about that code. The effect? It causes me to switch of my creativity and go into damn!-just-finish-this mode. In this mode, I produce results, but I’ll be the first to admit they are not the best they could be. Other programmers may look at it and say it is good code, but I know, and like an artist critiquing his own work... only he knows what he could have done, or someone else, that has a true understanding of his potential.

What I’m trying to bring out here is that Complex Code (Code that Initially Feels Complex Just by looking at it), is badly written code, and from some limited experience, I’ve found that there are usually lots of bugs lurking just beneath the surface of these creations.

In a nut-shell, I’m saying that no matter what approach you take to programming, another programmer (who could be yourself in a couple of months time), should be able to look at your code, and not feel it is complex. If the programming style you use, results in this, then it is a good programming style. If it does not, you'll need to do something about it.


Excuse me. Do we have a problem here?

The problem sometimes is that we don't even see this as a problem. We believe, especially in small programming start-ups, that once the job gets done, it is okay. Well... when you start seeing the problem is when a couple of years down the road, you're still having the same or variants of the problems you used to have when you started. The same kind of bugs, the same kind of issues, the same kind of customer complaints (this actually shows that you have not embraced the right kind of laziness, hence you’re inventing the wheel each time you need to move over great distances).

I believe software is something that evolves, but even more than that software development is also a process that evolves. If I as a programmer keep wasting time when I encounter a problem today that I’ve been encountering in the past, then I’m definitely not evolving, and I’m a bad programmer. If this happens to a software development company, then that company is a bad company, with bad programmers. If this problem is not addressed, that company will keep having its best programmers leave them for more interesting (important), job opportunities.


In conclusion

Programming style should alleviate the programmer, free the programmer, make the programmer feel useful and creative not lock in the programmer. Once your programmers or you as a programmer is complaining about code base, there is something wrong with it and if that code base was created by you or your programmers in the not so distant past, that is a big alarm going off. Check your programming style. You should be churning out elegant code that works well but probably more importantly is pleasant to glance at, and also to visually debug.

No programmer wants to be caught up with boring (interpret: not interesting, not important), stuff. But bad programming style may be causing this rut. Worse, you may not know that this is the problem you're having.

Finally, I think it is paramount that every programmer and programming team should take a look at the code they are generating and ask themselves: "Are we proud of this? Does this look/feel complex? Will maintaining the code mean that we rob our programmers of valuable time for important things, and use that time to de-complexify this code?” The answers to these questions can give a lot of insight into your current productivity levels. And if the answers are not too good, this may be a pointer to change your programming style/habit.



In another write-up, I’ll take on what makes me feel a code base is complex into detail some more.
In yet another write-up, I’ll document my perception on where I seem to have found good programming style resulting from. I'll discuss my perception on buzz technology and its relation to Tradition and good programming style.