Software Development: planning Projects Software Development
by Daniel
leave a comment
Estimation and self delusion
Here is an interesting exercise for you to try next time your estimating something e.g, task duration.
- Write down your initial off the cuff estimation, without thinking about the estimation in any detail.
- Think some more about the task and how long it could take if everything went wrong (within reason e.g, discounting riots, natural disasters, coups etc) then write down your new worst case estimation.
- Think about how long it could take to do if everything went right and write down your best case estimation.
Since I first started performing the exercise on myself and team members when estimating I have noticed the following:
- That answer one and three are almost always nearly identical and that answer two is usually significantly different on average from answers one or three.
- Those planning based on estimates prefer accurate estimates to an immediate answer: especially as the immediate answer is usually significantly inaccurate.
- I don’t like causing myself massive stress by making inaccurate estimates that I then have to try and meet and I’ve met few people who enjoy self inflicted stress.
- It is acceptable to ask for some time to think about estimates, even if it feels awkward at first.
- Thinking about similar tasks you have done in the past can be a very useful tool to help contextualise your estimation, if you don’t think about previous experiences you can walk into the same miscalculation again and again…
My mice over the years
My earlier keyboard post made this post inevitable. Unfortunately Google image search has failed me and I can’t find images for my first few mice: starting with the mouse for our Acorn Archimedes 440 (IIRC single button), then it was a generic dual button serial mouse for my family’s Windows 95 PC, followed by an angular blue Microsoft serial mouse with a scroll wheel for the same PC then…
A new PS2 Microsoft Intelimouse for my first PC.
Followed by the first optical Intelimouse, finally no more jamming mechanical components with USB or PS2!
Then the explorers cheaper descendant, USB only now.
Sore hands and RSI like symptoms lead me on an ergonomics drive which led me to abandon mice in favor of a trackball, in this case a Logitech Cordless Trackman Optical, which I still use at work (I keep a mouse hooked up as well for those people who can’t use trackballs). The only drawback is that it is wireless, which means replacing batteries which I don’t like and Logitech, in their wisdom, do not offer a wired version.
Now at home I’ve made the switch to a Wacom Bamboo tablet, which I’m still learning but enjoying the change again. Obviously this is not a good input device choice for gaming, so I still have my trusty Trackman hooked up to my iMac.
Becoming unstuck
In my previous post I talked about being bored and dealing with that, now its time to talk about being stuck and how to deal with it effectively. For me there is a few flavors of being stuck:
- The brick wall: you’re working fine and then suddenly you’re stuck and you’ve no idea how to continue.
- Recursively stuck: this one is hard to spot. You’re trying solutions to something but each attempt takes so long to work through that by the time you’ve tried it you’ve forgot what started that attempt, you then try the first thing that comes to mind which often is the last thing you tried, repeat until you notice…
- Too many options: something that appeared straight forward on closer examination has multiple potential solutions and you’re not sure which.
My approach to becoming unstuck is as follows:
- Take Notes: As soon as I realise I’m stuck I start taking notes: what I think I know, what I suspect, what I’ve tried and what I want to happen. Doing this helps me prevent myself getting bogged down by attempting the same solution repeatedly. Also by recording what you think and what you’ve tried you give yourself an agenda of potential solutions to work through as you attempt to solve the problem, as once you’ve ruled everything on your list out what you are left with is usually the issue, although at times that may seem ridiculous!
- Ask Google: There are very very few new problems in the world that haven’t already been encountered by someone else and chances are there is something Google can find for you that may give you the pearl of insight you need to solve your issue.
- Ask the community: Chances are unless there is some sort of general community for the language and/or technologies you are dealing with, which you can ask via email, forums or IRC about your issue. A lot of the time Google will give you results from these communities if their archives are somewhere the Google spiders can reach.
- The cardboard programmer: This solution sounds silly but it works, find anyone (they don’t need to be technical at all) and then step through your problem with them talking over the source code. A lot of the time you will realise your error mid way through your explanation!
- Ask an experienced co-worker: Find a more experienced co-worker and ask them about your problem in an intelligent fashion e.g, giving details on the issue and what you’ve tried.
My golden rule for becoming unstuck is:
- Never be stuck for long! I can’t emphasise this enough, this is an industry where programmer productivity is the number one priority, not solving the issue yourself. If you’re totally stuck don’t sit for more than an hour (ideally half an hour or less) before you start involving more experienced people in finding a solution. Don’t believe me? Watch the most productive programmers around you, I would put money on them never sitting for long if they are stuck before they start asking for help, it is not a weakness, it is simply more efficient!
My keyboards through the years
My first experience of a computer keyboard was with my family’s ZX Spectrum.
Next came an Acorn Archimedes, with strange non-rubber mechanical keys!
Then a new family computer: a Windows 95 PC, with those weird extra windows keys.
Finally my own PC with components selected by me, bought by me and built by me, paid for with a student loan. I liked the look of the ergonomic keyboards so I gave one a whirl.
Eventually I was forced to upgrade from my trusty natural keyboard to a more fancy model also by Microsoft when production of the natural model stopped, which meant getting used to a ‘normal’ cursor key layout again.
plus
And finally my current keyboard with a triple action foot switch, which is also my most expensive by far. I upgraded to this model after too much typing and some over indulgence with World of Warcraft (I’ve since quit) in the evenings which robbed my hands/wrists of any rest from typing: left me with sore fingers and tendons. In addition, several programmer friends the same age as me were succumbing to RSI at the same time which worried me enough to make me take the ergonomics of my input devices and my usage patterns very seriously or find a new career which didn’t need my hands!
Thankfully, since using this set-up at home and at work (which my employer provided) combined with the most excellent WorkRave rest break management program my hands are almost completely healed, which I’m really thankful for as so many other people I know didn’t get off so lucky at all with RSI like symptoms. One friend even needed experimental surgery to try and relieve the pain caused while typing….
In my opinion it is never too early to start thinking about your working ergonomics and break patterns as it can literally cost you your ability to work later in life if you’re not careful
Productivity Programming: productivity Software Development
by Daniel
leave a comment
Combating boredom
We’ve all been there, working away trying to solve some an implementation issue or design detail and suddenly realise we’ve been browsing the web or the building, chatting with co-workers for no reason, surfing the email inbox, going for over-long breaks or otherwise avoiding the task at hand. The most likely diagnosis? You are either stuck or bored, today we are going to look at dealing with being bored.
Boredom is common, especially during tedious tasks that involve repetitive tasks. The solution to this is automation, either with tools or a scripting language. A good software engineer should be lazy and by this I don’t mean they should do no work, I mean they should not do the same task more than twice in recent succession before they start looking for a way to automate the task so they don’t have to do it again manually because its just plain boring:
- Doing lots of copy and pasting?
Chances are you are either copying the same code snippet around, if so that is screaming out to be factored into a separate function: copy and paste duplication of code is evil, especially if you don’t fully understand the snippet you are moving around. Are you sure it is safe to put that snippet there in that method? Or have you just renamed something and are now searching for and replacing each instance with the new name? Don’t do this manually! Invest in some refactoring tools. Most good editors and IDEs now come with some form of refactoring tool sets built in, find them, learn them, love them they will save you tons of time! - Calling a n step pipeline of tools manually?
Invest some time in learning a scripting language like Python, shell script, php or Perl (my favorite is Python): n step tool pipelines are the tedious problems that scripting languages were designed to solve by automating them into a single script call. Scripting a pipeline becomes an investment especially if this pipeline is being run a lot by many users, think of all the time you are saving all those users and the removal of operator error by taking the time to automate it. - Waiting on an external dependency?
Are you waiting on something from someone else that is blocking you? First off: do they know they are blocking you? It may not have been communicated to them, don’t assume they know: check. If they know but they can’t give you their deliverable yet, is there anything you can do to help them or to prepare for the coming integration (e.g, refactoring)? If all else fails, do you have any other task you can do while you wait? Maybe something you’ve been meaning to do but didn’t have the time? Still nothing? Find your lead or manager, there will be something else for you to do while you wait, if there isn’t I’d be worried! - Waiting for bugs and in code base lock down?
So you’re near the end of development in your current cycle, most of the bugs have been found and fixed, your code base has been locked down and you’re not allowed to change anything except for bug fixes? You have several options here still, the most immediately useful is to see if anyone else has a bug they could give you to keep you going. Then if there is no spare bugs start testing your application yourself, be pro active, find bugs, torture your areas or responsibility to make sure they work. Bored of that now eh? If you’re near the end of a development cycle chances are there is going to be a sequel: start your own mini postmortem of the project, think about what went well, what didn’t and what you would do differently next time.
Next we will look at being stuck…
Programming Software Development: Lists Software Development
by Daniel
leave a comment
Development Tools: The Essentials
I thought I’d put together my list of essential items for any software developer:
- Text editor
As word processors, type writers and stationary are to journalists, so text editors (e.g, CodeWright, Scite, VI, EMACS or Visual Studio) are for programmers: the tools closest to our hearts. They are the main way we interact with our medium and they are one of our most personal choices as every individual has a different way of thinking and working. Having an editor that you are an expert with is probably one of the biggest productivity gains a programmer can make by installing a single piece of software. If you are just starting out as a programmer finding and mastering a text editor (or IDE like Visual Studio or Eclipse) should be one of your goals early on. - Debugger
Debuggers are essential to accurately investigate, diagnose and fix bugs as they allow programmers to step into executing source code: follow the execution of the program, inspect variable values at run time and set breakpoints to halt executing programs at interesting points of execution. Debuggers and text editors often come bundled together in the form of an Integrated Development Environment (IDE) examples of which would be Visual Studio or Eclipse. - An efficient way of finding information
Finding information is a common theme from software developers whether it is finding all instances of the use of a particular class in your program’s source code or finding workarounds for a particular compiler error: search tools are essential. Fortunately internet search has been made dramatically easier by Google, and programs like Grep that use regular expressions have helped ease the chore of finding information quickly on your computer. Some advanced text editors and IDEs also feature regular expression based searching, which is great as it gives you one less tool to learn. - Unit testing framework
Unit testing frameworks like the xUnit family of test frameworks (e.g, NUnit for .net applications) have rapidly become essential tools in the continuing battle to improve source code quality and avoid implementing the same bugs repeatedly during the course of development (regression). Unit tests relieve the programmer of having to manually test all the program components every time they make a change in order to verify the quality of the change. This is both a huge time saving and a great confidence booster when all the tests pass after a change, this does not mean that no ad hoc manual testing should be done. Test frameworks are also starting to be included in IDEs or integrated into existing IDEs via add-ons or plug-ins which again makes them even slicker. - Source Control
Source or version control software is an essential part of any project that is more than a script that will only ever be used once. Version control allows a programmer to check in source files into the source control repository at regular intervals, access the history of those files (e.g, see what they’ve changed) and for other programmers to sync copies of those source files onto their computers. Source control is essential in any team setting or for any complex work as there is otherwise a significant risk that work will be lost, due to either re-factoring disasters (it worked before but now it doesn’t and you can’t remember your changes) or synchronisation issues when trying to share files between multiple programmers (especially if two or more programmers edit the same file). Source control is also starting to be integrated into IDEs and text editors which is great as there is nothing more jarring than having to leave your editor to find and check out a source file.
My personal quiver of tools is as follows:
- Text Editors: Visual Studio (for C, C++ & C#), Eclipse with PyDev (for python) and Scite (for XML & misc. scripting languages).
- Debugger: Visual Studio or Eclipse with PyDev.
- Search: Google (www), Visual Studio, Scite or occasionally Google Desktop.
- Testing: NUnit or the xUnit for the language and platform I’m working on.
- Source Control: Perforce, pretty much on any platform, for any language.
