Engineering Day 2 (Why we write Software)

Today  I’d like to examine the question of why we write software.

 Most obviously we write Software to represent a concept and to solve a particular set of need(s). I may write some software to represent when the buses at the bus station arrive and one of the needs I may be solving is not wanting to miss a bus’ arrival or departure. I can represent busses by designing a Bus class and store the information in a Database (or a file, if I’m not thinking properly)

Representing concepts (travel, food, housing etc.,) and solving business needs is expected of Software, but a seasoned Engineer has additional reasons of designing the software the way she does. When we write Software as professional Engineers we write Software with other Software Engineers in mind:
How will the next person use this class or interface I’m writing?
Are the functions/methods too complex?
Are the functions too long?
Is my function doing just one thing (recommended) or many things than can be put in separate functions?
Am I using enough comments?
Are my variable and function names descriptive?
If another Engineer passes in the wrong data to my function, will my function crash?
How can I handle wrong data gracefully (Exceptions)?

This can be the deciding factor in not just getting a job at top Software company but having great manageable software.

So here are some gentle guidelines:

Be EXPLICIT!
Don’t use variable names or method names that only make sense to you.  For ex if I have a variable for when a bus arrives I shouldn’t be lazy and use tta when I can use time_to_arrival. It’s longer to write time_to_arrival but it’s much cheaper and shorter in the long run than another Engineer spending lots of time not knowing what poorly named variables like tta mean.

*If you’re coding in Python use the Python standard (https://www.python.org/dev/peps/pep-0008/) if you’re using Javascript name variables the way commmonWayOfNamingThem. 

Assume no one knows what you’re doing!
Your assumptions aren’t someone else’s assumptions. Don’t assume other people using your code will always pass in the correct data to your functions or methods! Don’t assume other people will use your classes (or your App/Website) as expected So always Error Check!Check for errors.  Be competent enough to expect the worst. Believe it or not you will forget why you wrote some code you did 8 months ago, I do it ALL the time.

You are writing Software for other Engineers who will be using your code, and for yourself months and years from now!
Just 3 months from now you will have to look at your code again, and if you have hundreds or thousands of lines of code, poorly commented, poorly written, even you will be confused.

The take away:A huge part of Software is debugging, maintenanceand upgrades (new features). If you only write code that makes sense to you it’s essentially a waste of time –for everyone. Poor Design leads to Technical Debt (http://en.wikipedia.org/wiki/Technical_debt).
No proper company will hire an Engineer who’s poor design skills are technical debt.

It takes experience to know that you’re writing Software for yourself months down the road and for other Engineers. Just as in other Engineering disciplines, proper design creates maintainable structures.  Design properly and Stay out of debt :)

**we can talk about Technical Debt 
later.

Leave a Reply