Difficulty transitioning from academic to professional

Graduation by Baris Simsek @iStockphoto

For some time, my current employer had been sending work offshore. Specifically, sending some programming work to China. I’ve been tasked with handling these invisible developers on and off. These developers are mostly fresh graduates, with no experience and barely enough knowledge to write something in ASP.NET or C.

There’s also a high turnover rate, meaning there’s a lot of developers coming and going. Anything more than a few months, and you can consider giving that developer a long service award. I think the reason for this phenomenon is that the developers are finding it difficult to transition from an academic environment to a working professional environment.

In school, if they can’t solve a problem or do a task, so what? Now, they have to do it. They have to do it by themselves usually. The familiar teacher and fellow students are gone. Sure, we provide guidance and be mentors to them. But we actually expect them to perform and give results.

I have seen some seriously detailed specs to them for development work. My thoughts had always been that, by the time I wrote something that detailed in a Word document, I could have used the time to write the code. I’ve always believed that sufficient guidance is necessary, but if I had to think for them the programming logic, then their coding ability is up for question.

The points listed below summarise some of my observations. Take note that they’re based on typical education environments and typical work environments. “Typical” is also based on what I know. Feel free to let me know how your situation is like. I’d love to hear your side of the story.

Standard answers

In an academic environment, you were given standard questions with standard answers. Sure, the questions weren’t identical, but the differences were really minor substitutions. As such, the method of arriving at the answers were standard.

In Singapore, we have what’s known as the “ten-year-series”. As in, “Have you bought the ten-year-series for chemistry?” What’s a ten-year-series? It’s a compilation of questions from the past ten years. Of course, a more appropriate name would be 20-year-series (or more) now. Students would practice and excel on the questions in the compilation, and were almost guaranteed good grades.

My guess is that it’s hard to come up with new and challenging problems every year, so exams come mostly with standard questions, plus a few tough ones to find the brighter students. Any teachers or any readers associated with the pedagogical profession, please feel free to correct me.

The work environment is different. You’re thrown new problems everyday. There aren’t standard answers to these problems. Heck, there aren’t even standard consequences from your solutions, even if they are correct.

For example, you could have solved a difficult technical problem with a brilliant answer. If the customer suddenly didn’t want to do that project, you still failed. Or your superiors are unappreciative morons, and brushes your efforts aside. Be brilliant in the right areas.

Flexible hours

When you’re in university, your study hours were so fluid, you could have lessons packed one day, and be totally free the next. Some people took this uncertainty and developed self discipline. They were able to organise their time even though their timetables jumped all over the place from one semester to the next. Some people weren’t blessed with this fortitude, and whiled their time away.

Come working life, you’re expected to put in hours. You’re expected to be in the office at a certain time, and “allowed” to leave at a certain time. Googlers and other employees of companies with more open policies, you rock.

Suddenly, your freedom is gone. You feel chained, you feel like the creativity and the fire in you die… Stop that! You’ve obviously chosen a profession ill-suited to you. Take this opportunity to learn about what your work is, then move on to something better.

Or better yet, work with your employer and see if you can arrange something more flexible. Working from home or more flexible work hours are options you can ask for.

Theoretical

I don’t know about you, but much of my university days were spent proving some math problem. Or writing programs illustrating the use of some theorem (math or computational science). I didn’t know how injectivity and surjectivity was going to help me in life, but I learned them anyway.

Your job in a professional capacity is to solve problems. Real world practical problems. Your solution suddenly makes a difference, for better or worse. It doesn’t matter what your qualifications were, or how much experience you have. Real world practical problems require practical solutions that can stand the test of time (at least for a while). That piece of messy code you wrote? Go fix it.

Your education in academia should be treated as training your mind. You’re not so much learning those (boring) subjects as much as training your brain, forming new neural connections and creating new thought processes. Learning about injective functions and surjective functions made it easy for me to pick up the concept of joins in SQL. One-to-one and one-to-many relations between database tables became a snap to understand.

License to play truant

Do you skip classes? Watched a movie instead of attending a lecture? As a student, your grade was probably very much based on your exam results.

Not so when you work. Results still count, of course. Your attendance, your ability to come to work punctually now matters.

This really ties in with the flexible hours part. I agree some companies (alright, most companies) are still rigid in this area. Let me put this question to you. Can you go to work in the appointed period of time because you want to, and not because you have to?

I love my work. I love programming. Sometimes, I wake up and I can’t wait to get to work, to start on that code. I do it because I want to. It’s like playing. The standard working hours don’t really make much of a difference to me.

As usual, your ideas, thoughts and comments are most appreciated and welcome.

Office Christmas party

It’s the annual office Christmas eve party! I’ll be letting the pictures do most of the talking. First, when I reached the venue, this greeted me:
Christmas party prizes
Helllloooo prizes! The one on the extreme right is the 1st prize, a Brother printer.

Then I went checking out the place. Cupcakes!
Merry Christmas cupcakes
Of course, you weren’t looking at the cupcakes, right? You were eyeing the booze, right?
Wines

Next I moved on to the turkey.
Turkey dish
The other dishes were covered up, so I moved on to the view.
High view

I spotted some people playing with this contraption.
Roulette ball spinner
And no, it’s not used for the lucky draw. My guess was that it’s used to draw lots in a matching game, where they ask us for stuff and we’re supposed to come up with matching items. I realised how hard it was to find 2 mobile phones without camera functionality…

Just when I thought the only subjects willing to be photographed were inanimate, my colleague offered to be captured in bytes.
My colleagues
He also pulled in a friend. The one on the left’s An Le. The other one’s the brave soul Ming Chun. I was given explicit instructions to capture some of the background too.

So, how’s the lucky draw done? You see those balloons?
Prize balloons
One of them had my name in it. The organisers stuffed slips of paper with our names into the balloons. The fortunate ones would have their balloons pricked and names called out. The lucky draw would be conducted amidst exploding showers of balloon rubber, much clapping and hand shaking, and prize awarding.

And I won a notepad! Cool. I was running out of note paper at home…

Christmas office decoration

It’s about 3 weeks till Christmas and decorations are going up. Shopping centres and malls are decorating. Orchard Road (a major stretch of shopping venues in Singapore) is being decorated. Why not offices?

So my colleague took it upon herself as master decorator and whipped out her secret stash of decorabilia, and enlisted the help of another colleague and myself to help deck our portion of office space.

So here’s the obligatory Christmas tree
Christmas tree

She decided to spruce up the thin railing of our cubicle partition this year, with this result
Decoration along cubicle partition

Since we’re here, I might as well show you what my desk looks like…
Part of my desk
That’s the left wing. The right wing looks messier, with more stacks of files and paper. I’ll spare you the image…

Here’s my computer
My computer
Yes, it’s still with a cathode ray tube monitor. I take good care of it, so barring unforeseen circumstances, it does what it does. It’s getting a little cranky though, a bit slower than before…

Oh yes, apparently, the ground is not enough for my creative colleague. She attacked the ceiling too.
Decoration on fire sprinkler
The fire sprinklers aren’t doing anything useful anyway…

[There has been one made up word in this post]

6 degrees of separation in understanding user queries

Cube network by Andrey Prokhorov@iStockphoto Be grateful. Be flattered. Be outright ecstatic. Why?

Because users think you’re a mind reader.

For some reason, they think telling you “I can’t do X. Please help.” is enough. They don’t tell you

  • which application it is
  • where or which screen in the application it is
  • any error messages they see
  • what they did (before they got the error message)

They sometimes just don’t tell you enough.

6 degrees of separation is already too much. Users expect you to make amazing leaps in intuitive logic from their pathetic amount of information to whatever is ailing them at that moment. That’s one giant step of deductive debugging.

How do you understand their queries better? Just ask. Ask for more information. This is where your people skills come into play. You’ve got to ask them in the way that makes them feel good about themselves. Basically, you want them to feel like they’ve done everything correctly and it’s really the fault of the software, even if you think they’re complete morons.

You’ve got to coax them into telling you stuff. And it doesn’t help if you keep calling them an idiot.

This brings us to the next problem. Users lie. They don’t lie outright. They just don’t tell the truth sometimes. And it’s not because they purposefully and specifically lie to you. Sometimes they just don’t know they’re telling a lie.

The spelling misunderstanding

For example, I recently had this user say he couldn’t use an application X because of an error. I probed further and managed to pry an error message out of him. Something about a missing file. There was this part “Pls check and proceed”.

Well, I thought, the more unique the error message is, the easier for me to locate where in the code the error occurred. Ever since I took over maintenance of legacy programs, I love it when there are unique error messages. Incorrect spellings, short forms of words, unusual text (like two consecutive spaces), incorrect grammar. Searching entire source code with unique search phrases means there are fewer search results, increasing the speed of finding the actual code.

So I typed in “Pls check” into the search box and ran the search. Nothing. What? I looked at the whole error message and nothing stood out as unique. So I got the user to give me a screenshot. The actual error message was “Please check and proceed”.

Did the user lie? Not really. He read and interpreted the error message correctly. It’s when he’s conveying the error message back to me that information was lost. For him, there’s no difference between “Please” and “Pls”. For me, it’s absolutely critical that every single letter was correct. Sometimes even letter casing matters.

This is the heart of understanding user queries: Understand the user.

I maintain many programs and applications, and I work with different sets of users. These sets of users usually don’t know that I work with other applications and users, so sometimes they ask me something expecting me to know the context of their query (when in fact I have no clue).

Here’s a list I use for probing

  • Ask for screenshots
  • Ask for error messages
  • Ask which application they’re using
  • Ask which screen or web page they’re on
  • Ask which button they clicked to get the error

No information is redundant. Debug like a CSI because you should “Follow what cannot lie, the evidence”. In this case, any information you get is evidence. If their version of the error message contradicts the one in the screenshot, then you can ask further. One or the other must be wrong. Either way, you get more information.

When you’re trying to understand user queries, there’s no such thing as too much information.

Your lifesaver, the screenshot

There’s another case where the user was asking why the update button doesn’t work and the application keeps hanging. No error messages, and he told me which application and screen he’s using and even which button (the update button).

In the end, I asked for a screenshot. Everything looked to be in order. Then I looked at the taskbar in the screenshot. He opened 3 instances of the same application, performing the same task at the same screen. That was the problem. Due to data concurrency and locking, the application instances simply got stuck. I told him to use just one instance and everything was fine after that.

Did he lie? Yes, because he didn’t tell me that he’s running 3 instances of the application, which wasn’t designed for that. Was it really his fault? Not really. He thinks doing different updates with 3 separate instances will speed up his work. Like he’s multitasking or something (a mindset shared unfortunately by many of my users…).

What you should strive for is answering the user query with whatever the user first supplied. That’s ideal of course, and usually hard to reach. The next ideal case is this:

  • User sends you email with query (with insufficient information)
  • You understand whatever is given
  • You formulate intelligent questions
  • You call (or email) the user and ask those questions
  • You finally understand what the user wanted
  • You close off the query, whether it’s fixing bugs or answering questions

Calling is usually better than sending another email. You can save a lot of emails bouncing back and forth if you can just talk on the phone. Your ultimate goal is to minimise back and forth communication.

You may not be able to understand and answer user queries in 1 degree of separation. But with a little thinking first, you can do so within 6 degrees of separation.

My computer got sick

2 days ago, the computer at my work place got infected with a computer virus. It’s a fortune that I was able to get it out of the computer. It was a misfortune that I wasn’t able to get any work done since I was scanning my computer, and I didn’t want anything to disrupt the scan.

My computer housed practically all the source code ever written in my department. Alright, I’m exaggerating, but it’s not far from the truth. If the hard disk was wiped out, let’s just say either I will be assured of another year of contract, or I’ll be out of a job.

So anyway, a reminder for everyone reading this: Have you backed up your computer?

Piling programmers lead to devastating deadlines

Small red bomb Ever been in a situation where the deadline is getting closer yet the project is getting nowhere? Ever had deadlines looming closer and everyone’s attending meetings, doing discussions but nothing is really done? And the solution from management? Pile on more programmers.

This isn’t like hacking logs, where the more people who chip in to hack logs, the faster all the logs get splintered into firewood.

This isn’t like cleaning house, where the more people who sweep in to mop floors or wipe windows, the faster the house becomes brand new spanking clean.

This isn’t even like data entry, where the more people who come in to type information, the faster all the data gets into the computer database.

Programming is a thinking activity. Thinking activities call on quality, not quantity, of the people involved.

Synchronising actions is easy. Monkey see, monkey do. See log. Grab axe. Swing, splinter, repeat. See dirt. Grab broom. Sweep. Eye on data. Fingers flying on keyboard. Tappity tap, tappity tap. Synchronising thoughts is much harder.

Simply piling on more programmers doesn’t make the project progress any faster. In fact, it just leads to devastating deadlines. Why? It’s the human factor.

This reminds me of a time when I was in a team of 12 (I think). We were working on an enterprise web application (warning bells sounding), since I just joined, I was given documentation of the application framework to study. There were custom web controls, dynamic browser sizing based on user’s resolution, security logins, language resource handling, translations, workflow management class codes and on and on.

I was the new guy, so I was given all sorts of miscellaneous stuff to do while they decide how best to use me. Then I got something to work on. The resulting code wasn’t my best, but I learned a lot from the team and the experience.

Then the deadline started slipping, and management brought on 2 more programmers. While I had some professional experience to speak of, these 2 had hardly any, from what I had seen. She needed help getting a DataGrid sort and bind to work!

New staff, even if they’re experienced programmers, need time to get accustomed to the team and the project.

Me? I got relegated to testing the web application. Somewhere in my resume I stated I did test cases before, and that’s where I ended up, writing test cases. The whole application was finally coming together, and then some of the other colleagues were tasked to help with the testing.

At least management got this part right. Having me help with the coding wouldn’t have made much difference at that point. Testing the application would have smoothed the project’s progress back within deadline, while the last bits of coding were done simultaneously.

Estimating project deadlines is hard enough. Don’t introduce a new variable into the equation. New staff are new variables. And if you really want to hire new variables, make sure they’re polymath programmers.

Solve the actual problem, not the illusion

Have you ever finished a software project, only to find that the user really needed something simpler or even totally different? Ever solved your user’s software problem with an application only to find that it didn’t solve the big picture problem?

Are you solving the actual problem?

The one with the Excel report

There’s this project where my user wanted a consolidated report from one of the web pages in an existing web application. He just wanted to be able to have one more option from a dropdownlist, and he’d select that and be able to get the report he wants (there’s an export function to Excel).

I thought about it, and told him that it would require some effort as it affects some other parts of the application (even though it’s just one more list option). I asked further why he needed the report to have that functionality, and how he would use that exported Excel report.

It turns out that after he exported that report (once the additional change was finished), he’d use the summation function in Excel, and sum up one of the columns to get a figure. All that work just to get one number. I repeated what I understood to him, and he really just needed one number. It’s a monthly task he does, and he usually exports the entire report into an Excel file.

Due to the way the web page was structured, he had to export once for every option in that dropdownlist, then sum up the numbers in each of the exported Excel files to get that final number. Not very efficient, hence his request.

I want to emphasise this now. He doesn’t really want that extra dropdownlist option, because he would still have to do a summation. There are a lot of records and Excel has this internal 65536 row limit (pre-Office 2007), so it might not even be feasible to put all the records into one Excel file as he requested. What he really wants is a monthly sum total figure.

So I told him, I’d design a web page that specifically lets him export a report that is exactly what he needed: an Excel file with a month column and a sum total column.

If I had followed on his request as it was, I have done coding which didn’t help my user at all. He’d still have to do some calculations and manipulations with the resulting Excel file.

The one with the DataGrid columns

There’s another instance where the user asked me to do some table column width adjustments. The DataGrid displayed an HTML table that she didn’t like. She wanted me to shorten some columns and widen some columns.

And you know what? She doesn’t really want me to do all those column width changes.

What she really wanted was for all the displayed data to be on one line. Due to the column widths, the columns with more data (such as text descriptions) wrapped into 2 lines, making the HTML table longer in height. She’s still on her 800 by 600 pixel resolution screen, so scrolling up and down when there’s only like 10 records was making her cranky.

So I manipulated the table column headers instead. I broke some header text into 2 lines, thus shortening those columns. Hmm… let me show you instead. Say this is the HTML code

<table border="1" width="360">
<tr style="background-color:#eeeeee"><td>Text</td><td>Month Text</td><td>Total</td></tr>
<tr><td>This is the first description</td><td>200708</td><td>34</td></tr>
<tr><td>This is another description</td><td>200709</td><td>45</td></tr>
<tr><td>Oh my goodness, yet another description</td><td>200710</td><td>56</td></tr>
</table>

This is how it looks like
Shortening table column

What my user wanted was to lengthen the “Text” column and shorten the “Month Text” column. She believed it’d help a little if she gave more explicit instructions. What she really wanted was for all the data to be on one line, never mind the header text.

So what did I do? I forced the “Month Text” to break into 2 lines (even though it’s already broken into 2 lines by the browser) using the br tag, ending up with
Month<br />Text

With the forced break, the column “Month Text” automatically shortens, and because the table is on a fixed width, the column “Text” automatically lengthens, thus fulfilling her desired outcome.

If I had coded explicit widths into the td tags, it might not scale properly when other data is displayed. I’d also have the beginnings of a maintenance nightmare.

Afterthoughts

So what have you learnt? Sometimes, when users ask for something, they’re really looking to solve something else. What you need to do, is find out what that is, then solve the actual problem, not the illusory problem the user thinks they’re solving.

6 month long projects are so last century

Hourglass with spider web Recently, I received a company-wide email complimenting a few groups of people for excellence. Those groups worked hard together for a project and successfully launched it. There was this particular one praising about 10 people for giving their best and sticking it out for 6 months.

That, is freakin’ long.

I can’t believe anyone going through a lengthy project like that in these recent times. A console game, I can understand, and it typically takes about 2 years for a game to be completed. It’s extremely hard to correct mistakes after a console game is launched, so there’s a lot of coding and testing to do. I mean, how can one apply a patch after a game is out?

Start-ups are even more taxing. I was working in one such start-up software company, and the implied timeline given was one year. At the end of that one year, some product had better be launched and profits coming in, or the start-up company’s going under. Rent, programmer salary and flagging confidence of the entrepreneur will slowly drain the resources of the company for anything longer than a year.

The world is getting flatter. Individuals now hold as much power as large companies. Open source projects are on par with proprietary software, and sometimes at a fraction of the cost (some even free). Software management and development needs to move faster.

6 month long projects are just so last century.

If not for the fact that my company is large enough, I doubt that project mentioned above would have done anything to the bottom line. It would have taken longer to reap the rewards of that project. And sometimes, that’s a luxury smaller companies and individuals cannot afford.

6 months. 10 people to be paid. And nothing to be gained in between? Those rewards had better be good…

[start of small digression]
My colleague recently gave birth to a healthy baby girl (congratulations!). Nature has designated that 9 months is sufficient for a human baby to be fully formed enough to be born.

Baby in blanket
A baby doesn’t have to be born extremely clever. A baby doesn’t have to be physically strong. A baby just needs to be as complete as possible at the point it’s born, and have the potential to grow.

And no, that’s not my colleague’s baby girl…
[end of small digression]

How can a baby grow further? Be out here in our world. How can individuals, small businesses and large companies grow further? By putting themselves out here in the world. How can software grow? By being tested in our world.

All the documentation, design, coding, testing, meetings and discussions and opinions mean naught if the software doesn’t work in the real world. And you only know if it really works when it’s out here, in our world.

Faster iterative cycles

That’s why agile methodology recommends smaller and faster iterative coding and testing. Code, launch, test, get feedback, code better, relaunch, test again, get more feedback, and so on. Of course, there comes a time when launching into the real world works better than launching into a test environment. Well, release the software product, and get back to making it better.

Launch your software with as complete a feature set as possible, and as soon as possible. My users are usually ecstatic over a small launch into production, be it just a new interface that really helps their job, or a small web application catering to a customer need.

Why? Because with faster launches, they can garner more businesses at a faster rate. Sometimes, customers don’t need a million dollar application with 100 plus features (most of which will never used). They just want a 3-screen interface application that does a really good job of retrieving data, because that’s all the customer really wants. Anything else is fluff, nice to have but hardly earth-shaking if absent.

And when the application is launched, there will be real-world feedback from the customer, real suggestions and improvements to be made instead of the hypothetical business cases when planning the original million dollar application.

How do you get faster launches with your projects? Break it down into the smallest, most complete application that satisfies the requirements, and launch that. Then move to the next phase by implementing the next most complete superset of the features you cut out from before, and launch that.

In the process of doing this, you may find you no longer need some features, because then, you’ll really and truly look at what provides the most value for the customers and users from the application.

My real life example

There was this one project I did. My whole team had rescheduled everything else, because the customer was a huge deal, and the time given was one month. My users worked hard to obtain that customer contract. Sales people selling, customer service people servicing and administrative people administrating. My team was tasked with the IT part, porting data, managing data, calculations and processing. Me? I was in charge of the web application, the very interface that customer has with all that data.

During that period, I was in the middle of helping two teams with development work. Two teams, two projects. Torn between two teams and faced with looming deadlines, multitasking was definitely out of the question. I had to focus all my energy into completing one project before the other, because it’s the fastest way to complete both within the time period.

For my main team’s project, I had to come up with a fresh design from scratch, all by myself, and I had to make sure that it’s scalable. Knowing my users, they’re going to add more features so their customer remains satisfied and they remain productive. For the other, I had to do code reviews, code improvements and some documentation.

A one month deadline. Somehow, I managed to come up with a usable, scalable web application. Somehow, I managed to complete the development work for two teams. All in one month.

You know what? After the launch of that web application, my users started asking for more features. I’m sad, because I had to go through intense deadline cycles again. I’m also glad, because it meant the customer was satisfied, and my users found the interface useful. No corrections, just improvements.

Wrapping it up

Shrinking project deadlines forces you to think about the software, from requirement to design to code. Deadlines measured in months are for consultants. Deadlines measured in weeks are for real programmers.

Discuss.

Estimating software project deadlines

Target dateLet me tell you. It’s hard.

There are managers who never learn why software project deadlines sometimes can’t be estimated with accuracy. There are programmers who never learn how to estimate deadlines with any kind of accuracy. How do we deal with this?

Having an accurate project deadline means schedules can be planned. It means the future can be glimpsed and foretold, albeit somewhat uncertainly. It means we are in control.

Real life doesn’t happen this way. Real world applications are infused with innovation, or they should be for any kind of improvement. This means new concepts, new ways of interacting, new ways of thinking about data, new ways of improving existing processes. New, new, new.

I’ve worked on both long-term huge projects and small-term mini projects. I’ve learned that there are many variables affecting project deadline estimation and the actual project completion date. Some of them are

  • skill of individual programmer
  • understanding of the project/business logic
  • affinity with other programmers on the team
  • difficulty of the task itself

I’m continually given small projects and asked to give an estimate on how long I’d take to complete them. My experience is that the smaller the task, the easier it is to estimate. The more standard the task, the easier it is to estimate.

This doesn’t mean you can’t innovate. On the contrary, it means you must innovate even more. It means breaking down any project into bite-sized portions that you can estimate with certainty. It means you must understand the project on many levels, from how the project fits in with existing projects to how a single line of code fits in.

And it’s hard. Understanding on so many levels require a lot of thinking. It takes some serious brain mojo to figure out that on the macro scale, data is entered and stored in a certain way, and that on the micro scale, a particular if condition has to be coded, even though the condition is never mentioned, implicitly or explicitly.

It involves asking a lot of what if’s. What if the user keyed in this value? What if the user keyed in this combination of values?

The naive manager never understands how a simple project with simple interfaces require so much time, because hidden within the project are assumptions that manager thinks are obvious. The unskilled programmer never learned to gauge his work, because there are assumptions hidden within the project and need to be explicitly coded.

When I’m asked for an estimate, what they’re really looking for is, “How many man days are required?” So far, my answers range anywhere from 5 to 35 man days. In case you’re wondering, 5 man days means 5 work days. It can be 5 people cooperating to finish the task in 1 day, or 1 person doing the task in 5 days. This method gives a projection of the deadline and the cost involved (in paying the programmers).

So how can you improve the accuracy of your estimates? Two factors, skill and standards. Your thinking and programming skills make it easy to translate business logic into code. Which gives you greater confidence in estimating. The more standard a task is visualised, the more previous knowledge can be leveraged. Which reduces new concepts and code, and give you greater confidence in estimating.

Ultimately, it is simply a matter of reducing errors and uncertainty in project estimation. I wonder if L-1 linear regression or least square approximation can be used for projecting future deadlines? I’d have to go through all my documentation to find out what my estimate was and the actual time taken was for any given project… It will require enough data points to sufficiently draw a line.

On that note, FogBugz uses Evidence-Based Scheduling, involving up to 200 data points. Instead of giving you when a project can complete, it gives you a probability of likelihood that the project can complete on a certain date. For example, there’s a 50% likelihood that your project can complete by next week. But if you can extend it another week, there’s a 80% likelihood that the project can complete.

I neither have the time and effort to do least square approximations, nor the software to do historic statistical analysis of previous estimations for future estimations. I do have my experience and programming skill, so basically I trust my gut.

So, how do you estimate your software project deadlines?

Blog Action Day 2007 – Use less paper

It’s Blog Action Day, and the topic for this year is the environment. It’s a movement where bloggers around the world blogs about one topic, on one day.

So I was thinking to myself, “What can I talk about, relating to the environment, coming from a programmer’s point?”

I struggled a bit. I’ve thought of recycling bottles and cans. Never really put much effort into it, although I buy bottled or canned drinks infrequently. Using paper bags more often then plastic ones? Yeah, and not nearly enough to quite justify it. Paper? Hmm… now that’s something. I’m accustomed to scribbling down notes on something like an envelope or printing paper or notepad. Then I continue scribbling new notes on those somethings until I can’t find another inch of whitespace.

When I first started working, I was actually appalled at the amount of paper used every month. I was learning the ropes at maintaining an application, and every month, I was to print out several reports and tally the results with each other. After checking that they were correct, I would then file them, and they’d be stuck in some office room corner where they’d never see the light again. Unless a disaster came up, such as a fire or earthquake or some user complaining about incorrect figures.

Then there’s the code. For some reason, the programmers of yore coded with such brutality and inefficiency and unreadability, that sometimes I had to print the code out. I couldn’t make head or tail of what they were trying to accomplish. So I thought holding the code in my hands would give me new insights. It was unbelievably stupid of me. It is in the nature of program code to have lots of whitespace. Sometimes, a curly bracket is all that lies on a single line.

So I tried to be clever, and printed the code as two pages on one side of the paper (you know, the landscape orientation). It was another unfathomably stupid mistake. I reduced the font to size 8 points on Courier New, and the resulting printout was barely visible. I had to squint to make out printf() statements. Absolutely terrible.

I also had the opportunity to attend meetings. Arriving at the meeting room, I’d only have my notebook (the paper kind). Other people would be carrying files of papers and the entire email printout of the meeting notes. And let me tell you, some of the email discussions were very lengthy, and with Outlook doing automatic indents for new replies, text were word-wrapped like crazy. A meeting with ten people probably used enough paper to kill a young sapling.

Another observation I made was the reliance of “hardcopies” of some users. They feel unsafe if there were no printouts of whatever it was they wanted, be it documentation or reports. Reports were printed out even if no one would ever read them. It was the monthly routine, and someone continued to print them out and file them neatly in a nice ring folder. It’s a waste of program resources, human effort and paper.

I understand it if you need to print something out. I’ve printed documents before, like program specifications. It’s just easier to have the business logic printed on paper in your hands, then code on the computer. Alt-Tabbing between a Word document and the Visual Studio is tough, even if I am getting better at it.

What can you do? Simply print less. You don’t have to forgo printing all together. A page saved here, a page saved there, and a tree could have lived a little longer. I’m sure there are parts of the document that you’ll never ever need. So print out the parts that you do need. Sometimes, program specs change, and then what are you going to do? Print it all out again?

Recently, I had the occasion to organise my desk into some semblance of neatness, and I finally decided to do something about a pile of files with documents that were like 10 years old (not mine though). I very nearly took them to the shredding machine and then I stopped. I flipped the document pages over, and they were blank on the other side. I suddenly had an enormous pile of rough paper for scribbling notes! Now to get all the staples out of the way…

I think that ultimately, going all out to save the environment may not be the answer, nor even necessary. Just use less. Use less bottles and cans and paper. Starting small means it’s easier to actually start.