Estimates Are Wasteful
Thousands of companies and organizations have been managing by estimates for decades. Do you think that you are smarter than the owners and managers of everyone of them?!?
I must admit, that question ruffles my feathers every time I hear it. Mostly because, that’s a direct attack on me, not my ideas, and a part of me wants to lash out back at them, or just glibly reply in the affirmative. I don’t. Discretion is the better part of valor, after all…
Today I just thought of a real good answer. Perhaps still a bit on the glib side, but at least not disrespectful or boastful.
Am I Smarter Than Pro-Estimate Managers?
I think that I have more knowledge, better tooling, and have learned from more failures, than whoever originally came up with the idea to estimate. And I have no basis to compare myself with those who simply estimate because that is what everybody else is/was doing.
What Do You Think?
Let me know in the comments.
A proper REPL environment is first and foremost, an interactive environment. This means that you should be able to simply drop into the environment, type in some code, and have an immediate indication as to whether the code does what you want it to do.
CShell
… as the saying goes. It seems that this proverb applies to our profession as much as it does to others. You’ve seen the doctor who smokes, the out-of-shape coach, the technician or plumber whose own wiring or plumbing is faulty, respectively. Perhaps it’s the same. Perhaps its just that proper ALM is more visibly useful when multiple hands are involved and they must all communicate and interact properly with each other, than when one person holds all roles.
Unless you are truly working on a hobby for yourself, you still need to be able to answer at least these two questions: 
Another saying that I’m fond of repeating, the former statement being a key reason to do so, especially when consulting and or training clients on the use of ALM tools, is to never let a human do a machine’s work (and vice versa). Anything a machine can do, we shouldn’t.
It’s all great when you’re hacking away at that pet-project of yours and you’re in the zone, but a week later, a month or even three later, once you start delivering a second or third release of your software, keeping track of what was done, when – not to mention writing release notes, becomes extremely difficult, if you don’t know what your changes are or were. In fact, if you use an ALM tool for tracking features, changes and defects, and associate them with automated builds, you can generate a release notes document automatically with every build, and not have to deal with it yourself.
In summary, I’d like to state my opinion that in most (again, all but the simplest and most straightforward one-shot) software projects, proper ALM is as useful and important when flying solo as when developing with a team. Lack of communication issues (though see point #5) are balanced by the increase of work of having to do it all by yourself.
Ok. So I have just right-clicked the word “HoloLens” and selected Add to Dictionary from the context menu. I believe that this word will be there for a while, and sooner or later, on everybody’s lips. 
Many people in various industries are victims of what seemed to bean-counters like a great idea. Cubicles, bullpens, hotel-desks. No matter how you call them, Work environments where people who are not collaborating on the exact same task are forced to endure noise and distractions from others are detrimental to productivity. At my current job I sit at my (small) desk, and am surrounded by people who are almost constantly on support calls that 90% of the time have nothing to do with me. There are also at least one man and one woman who seem to be chattering about non-work related issues, at least half of the day, everyday. The noise is annoying. Add to that the fact that there’s no privacy – my calls, my screen, etc. Personally, I hate having to think that someone may be looking over my shoulder while I’m browsing, reading, coding or answering emails (unless I asked them to). Finally, I miss the gigantic whiteboard that I had in my office, the last time I actually had an office. Just something that I could always look up to from my screen, so that I can verify or validate some design decision. So I work from home as often as I can (though I still miss my whiteboard. My wife just won’t let me put up one in the living room where I work…).
Enter HoloLens! Imagine coming in to work and putting on your HoloLens and sitting down at your… virtual office. That giant whiteboard? Hang it wherever you want. Might as well share a virtual strip of wall with anyone else in your office. It doesn’t matter. You see your whiteboard, I see mine. Or just hang it in the air. Look up to it any time you want from your 24” screen. No! Make it 48” or have several of them. It’s virtual anyway. Ever wanted your emails to be announced just not on your screen because you’re coding now? No problem – they can float off to the left, if you want. Your office can look however you want it. 
Ever had to explain to someone else how to do something? Ever had to do that when you were out of reach? 10 miles or half a world away, as is often my case, something always seems to go wrong just as soon as I’m away. The farther I am, the greater the problem. I go to work – any my smart TV cannot connect to the internet, leaving my baby daughter unable to watch her favorite YouTube nursery videos (mainly “Twinkle, twinkle little star”, and “
Adapting to change is difficult. Disruptive change, more so. When something that you know, and believe in may become invalidated and obsolete, it may feel overwhelming and scary. Other times it just makes you feel irrelevant – just like your (now useless) knowledge.
Change was always happening, and the rate of change was always increasing. But where in the past change happened over billions of years, until it could be measured in millions of years, and human advancement was then measured in millennia, at some point changes became so great and so quick that we started to notice. The industrial revolution was, I believe, the first such point in time, with change so great and so fast that it one could perceive life before and after it, within one’s own lifetime. Since then the changes began to happen every several decades – factories, the telegraph, automobiles, airplanes, radio, television, computers…
Saw this quote somewhere. It is largely true, I believe. For myself, I love change. I can’t wait to see what the next big thing is, what’s over the horizon? What new technology will come out tomorrow…While I appreciate my own generation’s unique stand point, being born on the cutting edge, riding the wave of technological change, We are immigrants to this brave new world. I would love to have been born today, to be a true child of the millennium, to be born a native child of the world of technology. What does my eldest daughter at 13 feel, never knowing a world without the internet? How will my baby experience the world, growing up in a world where scientific and technological advances I can barely imaging will be common place?
At any job interview, I will tell my would be employer that the biggest asset that I bring is adaptability, my ability to learn, knowing how to know. More than one customer asked me a question, and when he saw me searching the internet for the answer, he or she asked me something to the equivalent of “If you don’t know the answer why am I paying you”? My answer is always a simple statement that I’m paid because I know enough about my domain to Google faster than anyone he or she employs, I know where to search, I can understand what I read faster, and extrapolate a better solution to the problem than anyone else (perhaps a bit arrogant, but selling yourself short is never a good idea, and stammering any other answer would be worse).
An on-call technical support engineer wakes up groggily at 2am, when his phone rings. It’s a department manager. “Huhhhh? Huhhlllo?” he mumbles into the phone.
No, I’m not the new number two. I’m just another developer, who has to solve problems with software, and consequentially, solve problems in the software that solves the problems. I get bug reports coming from end users, testers, middle managers – sometimes even fellow developers – that leave me without anything more than a general sense that there was a disturbance in the force, and the software is not performing within acceptable parameters. 
I know that for many of you, the official language might not be your native one. Where I live, roughly half of the people are foreign-born (which is great, by the way – I like diversity). It’s fine. But please, please, do your best to write your bug report in a precise, understandable manner:
Jokes aside, we usually do not insert bugs into the system intentionally. At best it was the one defect that slipped the developers’ scrutiny. Often it is the product of being rushed to meet a tight deadline. At worst it is the result of negligent work born of the despair of either not knowing how to work properly and worse – knowing how things should be done, but not being able to do them the right way (see aforementioned deadline).
Yes, for god’s sake, we believe you. We don’t think that you’re off your rocker, if you have one. We need whatever evidence you have to help us identify the problem, find its source, and resolve it. So if you have it, give it up:
Especially if you are a developer or tester, you might have a special configuration file with specific setting that you are using. Please provide any non-sensitive configuration, or at least describe it. Anything you know about how you use the software can shorten the time it takes to fix the problem.
No, it’s not a cynical way of stating that that’s the way the cookie crumbles. We don’t always know what you believe the normal behavior should be. You may be right, you may be wrong. If you’re right, we need to fix it. If you’re wrong (i.e. the infamous “not a bug”, a.k.a. “by design” / “as designed”), we need to fix our documentation. So please let us know what you expect.
Okay, this one goes out to all you developers out there. There is nothing our coworkers hate hearing from us more than this line. It is not okay. It is still your responsibility to resolve the problem. I once worked with a manager that suggested that any developer that shrugs a defect off with “it works fine on my machine”, will be shipped off to the customer with his machine, in order to solve the problem. Said customer was in another country, where summer temperatures reached over 50 degrees Celsius (122°F!). To my knowledge the threat was never actually carried out, but the developers there used the phrase less than any other team I’ve worked with.
Sometimes a bug will consistently appear whenever the application is executed. In other cases it might be limited to happening only sporadically:
This one goes especially for corporate and enterprise users, as well as testers in teams. Nobody expects Joe Six-Pack to go knocking on doors in order to figure out if he’s special or part of something bigger.
