Tag Archives: documentation

Happy Ada Lovelace Day

Posted on by

Wednesday was Ada Lovelace Day! (UPDATE: Apologies for the late post.)

In a nutshell, March 24 is set aside to promote the achievements of women in IT and software engineering.  And we can start by looking toward the achievements of Ada Lovelace.  Ada Lovelace-the daughter of the famous poet Lord Byron-was the first computer programmer and worked with Charles Babbage on the theoretical underpinnings of computing.  Without her contribution, modern computing probably won’t exist today.

Now I’m not into the whole feminist movement.  I don’t think the movement really represents what the majority women think or want. And the feminist equation of “woman == man” doesn’t make sense.  Neither does any equation that tries to equate one person with another.  All humans should have the right to own their own bodies and not being owned by others.  And I won’t get dragged into a libertarian versus non-libertarian political theoretical debate here.  However I was brought up thinking that women can think as well as men can.  Therefore women can do engineering, mathematics and computing as well as men can.  (<flamebait>Maybe even better.</flamebait>)  So I want to acknowledge in this post, women who I highly regard and who have achieved great things in IT.

@Home: Mom

OK so my mom doesn’t work in IT.  She in fact dislikes computing in general.  We still disagree over the fact that I chose software development as a career.  However I regard her highly and without her work I would of never been able to work as a software developer.  Mom not only brought me into existence, she also taught me.  She as someone with a Masters degree in Civil Engineering, she could of worked on engineering amazing structures. For various she gave that up, to teach and raise me and my brother.  When two public school boards gave up on me ever reading or writing, Mom taught me.  She taught me mathematics and gave me a solid base that carried me well into university level math.  And she always would point out how weird it was that Canada didn’t have as many female engineers as Poland did.  While there are many reasons why that was the case, it was Mom who taught me to believe that women can and should be engineers if that was their calling.  So while she doesn’t work in IT or software development, Mom brought up a pretty decent (IMO) software developer.

@Work: Jennifer Chung, Salina Behera , Safa Siddiqui & Monika Schigel

I am privileged to work with the above ladies at my current workplace, VisionMAX Solutions.  Jennifer and Safa works as developers.  Salina is one of our talented DBAs.  And Monika works in that dark, arcane magical realm known as data modelling.  Not only are they great people to interact with, they also possess a wide body of knowledge.  Jennifer is a whiz at Java and ExtJS, and I often find myself asking her for advice on how to solve various tricky problems.  Monika has a way to cheering people up and I’ve never seen her without a wide grin on her face.  Also she and Tom, our two intrepid data modeller have been initiating me into the dark art of data modelling and the business of retail and mobile telecos.

@University: Katarina Halan & Megan Foote

While studying Computer Science at the University of Toronto, I had the opportunity to study and work with these two incredibly talented ladies.  We helped each other out on assignments.  I can not stress how well they understood the various aspects of computer science.  Also they introduced me to some interesting parts of Japanese culture, namely anime and DDR.

In the Open Source Community

Finally, two ladies that inspire me to get more involved with the open source community as a whole are: Emma Jane Hogbin and Celeste Lyn Paul.  Emma works on creating and managing documentation at various open source projects.  Celeste is a HCI expert who helps make KDE applications have the best user experience of any desktop related project.   I’ve only had the opportunity to meet Emma in person at Ontario Linux Fest 2009.  But Emma, you sure inspired me to look at the various components of documentation.  And yes documentation can be sexy.  I don’t get the ponies though.  Celeste on the other hand inspires me to one day get back into university and work on getting a human-computer interface design.  Her work inspires me to improve the UIs and workflow of any piece of software I am involved with.

To all these ladies, I’d like to personally say thank you.  You made me a better software developer.  And you are an inspiration for all women in or thinking of working in IT and software development.  Thanks!


The Seven Sins of Software “Engineering”

Posted on by

On Monday, my class discussed about using software “engineer”for software writers. I naturally argued against it. My mother finished civil engineering, and I strongly believe in the elegance, timelessness and excellence of engineering. This morning, as I struggled with and later killed my groupware program over a dispute of syncing with my Palm, I solidified my stance against the idea of treating programmers as engineers. Here are seven reasons why programmers are NOT engineers.

Sin 1: Documentation
Most programmers do not document their code. Some of them say that code is self-evident, self-describing and self-documenting. Tell that to the poor souls trying to extend or maintain that glob of code you brain-dumped.

Now take a look at a blueprint of an engineer. What would happen if some of the measurements disappeared or someone forgot to label the room that holds the AC.

Sin 2: Testing
Programmers do not test their programs effectively. You wonder why your state-of-the-art PC keeps on crashing, as soon as you plugin that expensive computer card? Or just randomly? Testing frameworks, and concepts exist, but with the exception of a few individuals, no one does a decent job of testing. Whining about different configurations and different users does not help.

When an engineer designs a skyscraper, he/she needs with the whims of people, animals and nature. That is why after an earthquake, skyscrapers and bridges still stand in San Francisco.

Sin 3: Research
Programmers rarely research anything. They simply build a new toy program, and expect everyone to love it. They expect that they can experiment away, and deploy an untested and unthoughtout innovation.
Then surprise and dismay occurs when their innovation is unwanted and even hated.

In engineering, most innovations need a huge amount of research. Engineers need to design, test, and re-test ideas until they know they work. An engineering innovation never builds upon a brand new untested technology.

Sin 4: Meeting Requirements
“I’m the programmer. I know what my client really wants.” Wrong! This cocky behaviour of coding what the programmer wants, and not what is required happens way too often. User requirements often go unresearched or ignored. The users become upset at the developers. Company gets into trouble. And the programmers are forced to fix their mistakes.

Engineering anything revolves around meeting some need or requirement. These requirements and the challenge of meeting is at the heart of engineering. If the client wants a skyscraper in the form of a glass inverted cone, the engineer has to build it. But the engineer must find out, understand and then build according to the clients and the universe’s requirements.

Sin 5: People Skills
When things go horribly wrong, who gets the blame? If a building falls (without an obvious catastrophic uncontrollable reason), the engineer gets the blame. If a user’s data vanishes in a simple operation, the user gets blamed. Programmers always blame their clients of incompetence, even when a problem is caused by bad programming.

This behaviour goes beyond just blaming. Programmers ignore the advice and problems of their users, and keep their jobs. An engineer who does likewise, gets fired.

Sin 6: Reliability
Programmers suffer from terminal featuritis-o-philia. They program a new feature and continue on innovating, all when their program lacks stability of any form. User start believing that programs and computers have a mind of their own, with data disappearing, malware crippling systems and hardware crashing inexplicably.

Engineers strive for reliability. Ever building is designed to last the harassment of humans, nature and even “acts of God”. Every vehicle should not kill its occupant, unless a total, catastrophic disaster occurs. Wondering why to this day, the crash-proof operating system and program is still a dream? Reliability takes second step to “innovation” and “coolness” in the minds of developers.

Sin 7: Overall Cuteness
If there is a single profession I can think of when you can get away with unprofessional “coolness”, it is software development. Programmers love to use obscure shorthands, bizarre implementations and wacky ideas, even competing annually for the “cutest” piece of code.

Cuteness is a sign of un-professionalism, and often immaturity in the real world. A cute engineer is a starving engineer. A cute programmer is a thriving one. See why programmer’s can not become software “engineers”?

Finale
My rant ends now, and I know many will complain that I overexaggerated. True, there are some programmers that do not sin in the above ways. They are the exception. Most programmers pass themselves off as good, and still sin terribly along the way. An engineer who sins as such is a bad engineer, and rightly so. I claim that if programmers ever want to earn the distinction of software engineers, they need to raise their standards considerably higher.