Feb24

What I Use for Screen Magnification

Those of you who know me probably know that I have low vision - or to put it another way I'm as blind as a bat. :-) Those of you who don't might have been able to figure it out from my picture. It's true my vision is pretty bad. (It varies from about 20/100 to 20/120 with my glasses on.) However, I know there are folks out there who have it far worse than I do.
 
Recently, a colleague of mine here at the IMF asked me what software I use for screen magnification. She has family members of varying levels of computer literacy who have a need for such things.
 
She was thinking about buying JAWS. I don't recommend this unless you are totally blind. JAWS is expensive unless you get a government grant, due to its fairly small base of portential customers - mainly progressive governments and a handful of blind folks who happen to be wealthy beyond reason.
 
Instead, here are three alternatives I suggest for low vision adaptivity on the cheap.
  1. Use the native features of Windows. Most people do not know this, but there are color, font, and magnification tools built straight into Windows nowadays. To find them, go to Start Menu > [All] Programs > Accessories > Accessibility. Mind you they aren't the best I have ever seen, lacking features and sometimes even becoming unstable, but - hey - you can't beat free.
  2. Use this nifty Magnifying Glass application which I believe comes from IBM's ThinkPad or maybe Microsoft.

    Download from ThomasCarpe.com

    It also seems that some other folks posted this on one of those file sharing web sites, but obviously I can't vouche for it being free of viruses or spyware.

    4Share download
    FreeDownloadsPlace download
  3. Dana Hanna, a very talented colleague I worked with while I was at Constellation Energy (he and I have both moved on since then) wrote an amazing little magnifying app, for which he graciously provided source code as well. I've been using this one for quite a while, because it has both features I wanted and the ability for me to add more as I think of them. Of course it's always been just a little buggy, and I guess having source is only an advantage if you happen to be a programmer.

    Torian Magnifier (download and source)
  4. Finally, maybe try this. They seem to have an interesting collection of FreeWare and ShareWare magnification tools, althought some of them appear to be effect filters for Photoshop.

    http://text.software.informer.com/download-text-magnifier-shareware/
Anyway, I hope people will find this list helpful, and if I find any new resources, I will try to keep it up to date.
Published: Feb-24-09 | 0  Comment | 0  Link to this post

Dec01

My Annual Review: Revisiting the Idea of the "Job I Love"

Some time back, I wrote this little gem as a musing about what kind of job I would enjoy.
 
At the time, I had a job that wasn't particularly thrilling. Here were a few of my reasons for daydreaming.
 
  • Stagnant pay: In spite of positive reviews and even awards, I'd received no raise for two years. In fact, I observed a general trend towards stinginess, particularly towards those who demanded the best compensation up front. To me this begs the question, if you are competitive about acquiring talent, wouldn't it be prudent to be as-or-more competitve to keep it.
  • Abusive management: I had seriosly considered giving some of the people I worked for copies of The No Asshole Rule for Christmas. (Work Matters, Bob Sutton's blog is also a good read.) In my line of work you have bosses back at the company and at the client; there were no shortage of jerks embedded in both places.
  • Few (if any) prospects for promotion: With plenty of competitors, relocation out of the question, and my path blocked by immediate superiors, realism demanded that I did not delude myself into thinking I could move forward by moving up.
  • Allies leaving the company: when those most willing to defend or make a place for you are finding better opportunities elsewhere, it's time to pack your chute.
If you start to see signs of any of these things, take my advice and do whatever it takes to find yourself another gig quick.
 
Looking back, it was almost as if my bosses were reading my blog, because only a few days after I made that post, I was shown the door. I have heard stories of such occurrances.
 
I was lucky. Despite a very strong desire to be loyal to the company, I had never fully come to trust in them to do the same for me. After alternately witnessing and being on the wrong end of a number of instances of office "unpleasantness", I had resolved to stay on my assignment only throught the 1st of March and had prepared myself for the market, so by the time I was dismissed I already ahd everything in place to find a new job.
 
And so I returned to the world of independent contracting from wence I had come two years prior. I can't be bitter at my former masters. For one thing, losing my job was the best thing financially that could've happened to me. Also, as it turns out I think I am better suited for the life of an independent consultant.
 
So, as I come up on one year from that time, I want to take a look back at what my goals were, and make some observations about where my work life has met them and where it has fallen short.
  1. A+: Work mainly with SharePoint
  2. A: Don't work (directly) for the "Evil" Empire
  3. B: Variety in work
  4. B-: Limited practical and social impact of assignemnt changes
  5. C: See lasting changes (transformation) from my work
  6. B-: Focused mostly on the new and "yes you can" and less on the existing and "why you can't"
  7. A: Autonomous commute
  8. A+: Show me the money
  9. D: Leadership, example to others
  10. B: Fewer conflicts with others
These letter grades are relative to last year; so "A" means I made a major improvement, "C" means little has changed, and a "D" means that my attempts were fristrated. (It wasn't in the original list, but I threw in #10 "just because".)
 
I'd say overall, the changes have been good. Perhaps I'm best sutied to working independently after all. I'll be making my resume a standing part of the web site, so no need to repost a link here. Anyway, here's the drill down - more for myself than in case anybody cares.
  1. MISSION ACCOMPLISHED I want to work with SharePoint most or all the time, because it's really cool!
    Well, the demand for SharePoint has seen to that better than anything. There's been such explosive growth in this product line that it's just insane. I never did spend much more than a week on the bench lat winter, and even during the wall street meltdown in September/October I was only seriously looking for work for a few weeks. (My biggest error was in taking a much needed inter-gig vacation in late August.)

    Having my own consulting firm means being able to make a choice to turn down any assignments that don't make good use of the skills I have. That anyone at my old job ever for a moment thought it was a good idea to assign me any work that didn't include SharePoint proved to be completely short-sighted; in doing so, they had sacrificed both long term profitability and my marketability.

  2. MISSION ACCOMPLISHED But, I don't want to work for Microsoft.
    It's easier than you'd think, but I did get a call about a couple of jobs from one of their people in Reston.

  3. DOING BETTER I like working on lots of little short-term projects. Veriety in work and in solving different problems for different types of users is exciting. For that reason, I could probably spend my whole life building nifty web parts and showing people how to use them.
    Well, being an independent contractor does lend itself to changing tasks and roles at least as well as working full time for a consulting firm does. I would prefer to have things mixed up a bit more while on a single project. DHS had so much variety it was almost a problem. Here at IMF it's less so, but I suspect that as I grow into the role that will change somewhat.
  4. MODEST IMPROVEMENT But, I hate having to think about my commute [or the people I have to work with] changing whenever the project ends.
    I still hate this aspect of changing jobs, but there have been some improvements. I've had some mixed success. I did form some lasting friendships while I was at Constellation, and I try to keep in touch with people that I enjoyed working with. I've had trouble keeping in touch with some of my old colleagues - John, Erin, I am lookin' at you - lol. Joining a local user's group helped too, but I haven't been to a meeting in quite a few months now. One good thing is that my current gig is only a few blocks from my previous one, so I can get together with pals from the old gig every now and then.

    As for the commute changing, it was for the better. These days, I have more control of the locations where I work. Though there were moments when I worried that finances would force me to take an assignment that would make commuting a challenge, fortunately things worked out differently.
  5. STILL ABOUT THE SAME I truly enjoy using technology to help transform a business. Getting only little wins is really frustrating, so buy-in from the top is very important to me. If that means part of my job is to fight for that support, then so be it. Unlike many people, I find debate invigorating.
    In many ways, SharePoint lends itself to "little wins", so I see a lot of those. Transformations can be hard to fight for and take a while to happen. I think the trick is to keep the little wins lined up so they keep coming. Give a day or two each week to doing the little things that impress the people who are easily impressed, and use the remainder to take on the big challenges.

    I am very fortunate that here at the Fund, the CIO is a big advocate for SharePoint, so maybe I will get to see some of that awesomeness soon.

  6. MODEST IMPROVEMENT I like doing work on proof of concept and design. Finding out what can be done is fun. Finding out that you *could*, except that you *can't* because there either a) aren't the skills, b) aren't the resources, or c) isn't the time is no fun at all. So, a place where there is a real investment in technology (as opposed to band aid solutions) is a real plus. (Update: Add "lack of political will" to that above list of frustrations.)
    So what else is new? Many companies large enough to truly leverage SharePoint run into the problems of bureaucracy, process, and political willpower. The ones that are small enough to be agile run into the time-skills-resources roadblock. Part of the challenge of working with SharePoint is finding a way in spite of this conundrum, so I am learning to accept this.

    I still prefer development over software maintenance, so I am making the use of TFS and wiki for documentation at part of my mission here. I want other people to take over my stuff so it does not weight me down later.

  7. MISSION ACCOMPLISHED I would like to either have a very short commute to downtown Baltimore, or else a reasonable train ride to Washington DC that I can do myself. I am tired of relying on my wife for transportation. I wouldn't mind working in my boxers either, but I need an excuse to get out of the house once in a while, and some things are better done face to face.
    I spent about twleve weeks of the year working in my boxers. I also did a short term part-time gig that was mostly telecommuting - though it tried like hell to become full time or worse. Later, I took an eight week unpaid vacation and sat around the house.

    As for the commute, all my other work has been either very local to my house or in Washington DC. Only a few visits to Booz Allen in McClean, VA in the early part of the year were outside that spec - and although they were quite a haul, they didn't undermine my autonomy. These days, my wife only gives me a lift to the train station, and I'd love to find a way to save her from that.
  8. MISSION ACCOMPLISHED I'd like a job title where the median base salary is in the neighborhood of $150,000/yr. Software Engineering Director looks nice, though frankly I have never seen anybody hiring for that one. They always use terms like Developer, Analyst, or Architect. Sorry, but the pennies don't spend like they used to, and wages don't seem to be going up to meet inflation. I guess I could accept a lower salary for the right perks, but the money is pretty important.
    I won't go into specifics, but I am making much better money as an independent contractor. Even with the two month gap in employment this fall, I am well set this year. The net compensation is about double what I used to make as a salaried employee. Although, one thing I really need to be mindful of is the taxes.

    This is important though, and I can't stress this part enough. I would not be able to pull this off if my wife were not working. Her job provides the health insurance, taking that worry off my plate. Also, even though her salary covers virtually nothing beyond the mortgage and day care, it provided the much needed butress which allowed me to go through extended unemployment without sinking irrecoverably into debt. Given enough time to amass some savings and shop for benefits, I could possibly take care of both of these issues on my own, but this year it was an indespensible aid.
  9. NOT QUITE WHERE I WANT TO BE Funnily enough, I like managing technical people, and I am good at it too. That's an aspect of work that I miss when being stood up as a lone gunman in consutling gigs. You rarely if ever have the authority to direct a team. Well, at least sometimes you can act as the trusted advisor; that can be nice.
    I have to be honest, this is the one thing that hasn't been everything I'd like from a job. Being realistic, that's probably a good thing, since this year has been full of challenges that would've made taking a stronger leadership role difficult. I did get some technical leadership responsibilities at DHS. Due to the practicality of working with govies it wasn't what I was originally promised, but what it morphed into was acceptable. There is a good chance that some leadership duties will emerge here at the Fund, but it's too soon yet and hard to predict at this point. There is some of this in running my own business, but I need to find a way to profitability beyond my own hours if I want it to have any measurable role in my daily life.
  10. DOING BETTER Work in an environment that is less hostile and/or stressful. Have fewer conflicts with others and resolve them more amicably when they occur.
    Life as an independet is absolute not conflict free. For starters, I had one client who got to be over $12,000 in arrears early in the year when I needed the money most, and he practically begged for conflict. I mean how many times was I supposed to accept "it's in the mail" as an excuse, anyway? Another client tried to bully me into working more hours than we'd previously agreed on - honestly more than I could handle while trying to run and grow the business. Finally, the security clearance process at DHS will just wreck your sanity - especially if like me you are prone to explaining things in detail and have a lot of petty baggage to disclose.

    That said, I will take all this in trade for one abusive boss, or one client who thinks it's funny to tell his developers to go wash his car. There is a different power dynamic at play when a business is your own and you are (at least on paper) supposed to be independent. For one thing, it is much easier emotionally to stand up for yourself.
Published: Dec-01-08 | 0  Comment | 0  Link to this post

Jan25

I Thought I Was Done, But I Had Another Thought

So, I guess I am not finished my brain dump. Given my previous post, what do we know, and what's to be done about it?
  • Because people don't accurately remember times for compelting small tasks, programmers should measure their own productivity.
  • This is boring work and should be done using software.
  • Programmers will resist having their true productivity measured by management, so they should have the tools to do it for themselves.
  • The measurements of one programmer are utterly useless for anyone other than that programmer, as code production can differ by a factor of 10:1 depending on the individual and circumstances.
  • If programmers do not share their individual data, then it isn't possible for management to make accurate estimates.
  • This information is most valuable to the programmer themselves, because it would improve estimaties.
  • Management is more concerned about creating reliable estimates than in comparing individual output.
  • In programming, low level tasks of different types are not necessarily interchangeable in terms of time. Individuals have different specialization even within a lagnuage or a framework.
What's this mean? Should we just give up? That probably won't fly, but here are a couple ideas that might help.
 
It would probably be better if we don't ask programmers themselves to provide estimates. Instead ask a programmer to describe the tasks involved in getting a project done and then use reliable large-scale data to determine how long a project should take given a average level of productivity.
 
Forrester or the like may have done some of this research or found studies done at universities. I have read some general studies on this topic that were produced by Corporate Executive Board during my time on their SharePoint project in 2003, but I don't know if they have drilled down on specific activities. Another good source would be to follow Fredrick Brook's references and see where they lead and if there have been any modern updates.
 
Why would programmers not like this done within an individual company? Well, it's basically along the same lines as truck drivers having GPS in their trucks or weight detectors under the passenger's seat. I think that while the programmer who knows or believes that he is 10x more productive than his peers would welcome such a system, there would a majority of others who wouldn't want to give that person more ammunition or ego fuel. In the end, I think even the super-programmer knows that it is better to have solidarity with his brothers if he expects their help later on. 
 
Sidebar: Some of the lady programmers out there may have noticed my assumption that my hypothtical programmer is male. Well you ladies are unfortunately still very rare in our feild, though I do wish that would change. In any case, being so rare, you're probably going to get our help no matter what you say or do, so it would be survivable I think to lord your superior productivity over the group and demand that everyone count their code lines. (Of course, I hope by now you all understand that I am kidding, right?)
 
We could probably all benefit from a large scale (open source?) project that would allow the entire IT community to provide details about how long tasks take. There could be plugins for popular tools like TFS/vs.net for task management to make participation easier.
 
If the data is collected in large anonymous sets and each developer has access to their own numbers, then it would remove much of the resistance to the idea of managment grading everyone. This would be much more like the way insurance groups are created. You're boss doesn't have access to the information about your health that the insurance company uses to determine how much they will charge him or her for your medical plans. (Actually, the insurance company doesn't get the whole picture either, but that's not the point right now.)
 
To make such an idea work it would have to be easy, it would have to be reliable (fake proof), and it would have to be fun.
 
Food for thought. I'll come back to this again some other time.
Published: Jan-25-08 | 0  Comment | 0  Link to this post

Jan25

Why Are Programmers' Estimates Usually Wrong?

Okay, I don't have a ton of time for this post today, but I wanted to get it out of my headspace so I can focus on other things. I'll just be summarizing my ideas here very briefly, so if you can't keep up I'll understand. I plan to come back and write something more formal later on.
 
Here's the basic idea. I've been thinking about why programmers tend to come up with estimates that are always too short. This is a problem that is pretty well known in the IT community.
 
Many programmers apply the Scotty Rule to their estimates (take what you think it will take and multiply by three). I can tell you that I've tried that, and it's still very possible to come up with an estimate that is still too short.
 
Fredrick Brooks has gone into detail on this topic in several of his essays. If you aren't familliar with him, I suggest you run out and buy a copy of the Mythical Mon-Month (Wiki, Amazon) right away. There are also some discussions of the problem in the book Dreaming in Code (Amazon), which I have only half-read.
 
Here's a summary of the discussion I've had with colleagues about this, based partly on the sources above, and partly on my own and others' experiences:
  • Programmers aren't capable of coming up with solid estimates because they are too optimistic. Their nature leads them to believe the impossible is possible and to chronically underestimate the level of effort required for any task.
  • However, without this (psychotic? disassociative?) optimism, they would not be capable of taking on the burden of creating large and extremely complex systems that must function [nearly] perfectly [mostly] all of the time.
  • Further, estimates are generated at the start of a project, when very little is actually known about what specific small scale tasks will be required. Even if the design is known, the detail level where the actual work lies is generally not fully understood.
  • Update Added as a caveat to the above item: obessive listmaking does not help. It is inevitable that a single person drilling down into the required tasks will overlook something, somewhere, and that thing will likely be important. Peer review or collaboration will only help this to the extent that people are actually willing and capable of reading such a detailed laundry list. Imho, the best lists would be generated by logging actual tasks done on several similar jobs, and combining the results into a superset - with notes about when and why certain tasks were only sometimes necessary.
  • A good programmer would rather try to do something that is hard.
  • There is a real transition along the lifespan of a project, from a learning and creative process at the start to a controlling and list maintaining process near the end. Programmers who are talented at design and early development are not necessarily well suited to do stabilization, but are frequently required to.
  • We actually know a lot about estimating software and managing development projects, but for the most part we don't actually act on that knowledge. Brooks is correct in asserting that his book is the software development Bible (everyone reads it, nobody follows it). In 30+ years since its publication our tools have gotten better, but we really haven't learned to actually *do* things much differently.
  • Yadda, yadda, the list goes on...
I am adding an item to this list today, after having read this New Scientist article about research into how we perceive the passage of time. My premise is that one of the important reasons programmers can't accurately give estimates is that they can't accurately remember how long any particular low level task has taken. To support this idea with facts will require some more research, of which there isn't that much available.
 
But, I think there might be enough to support the idea that we can chronically underestimate how long a future task will take if we chronically mis-remember it as having not taken very long in the past. In other words, being in "the zone" or acheiving a flow state (which are good things, right?) can make it harder for you to remember accurately how long a task actually took you.
 
Perhaps some enterprising student of Management Science will stumble on my blog and figure out ow to arrange the experiment and get some funding.  For now, I'll have to keep digging until I have exhausted the pool of data that is out there today.
 
If this theory is true, then it is possible that estimates could be greatly improved by programmers simply keeping detailed logs of their activity. Sadly, that doesn't seem to be consistent with the "flow state" behavior and might undermine it. I am thinking that software might provide an answer for how to gether the data without disrupting concentration.
 
For example, could we use TFS to measure time taken for work items, and how might one incroporate such a tool into development so that it is a true habit and not disruptive to the creative process? I guess I'll have to answer that some other time though.
Published: Jan-25-08 | 0  Comment | 0  Link to this post

`