 |  |
Tuesday, April 26, 2011
Monday, April 4, 2011
Tuesday, March 29, 2011
What's your METHODOLOGY?
How do you organize development to reliably meet your goals?
Usually, we all develop with an approach that can be charitably characterized as pragmatic, and not-so-charitably as somnolent. Most organizations develop the way they've always developed, with very little introspection into how they do their thing, why they do it that way, or how they might improve.
It's worthwhile to see if you can clearly describe your development methodology, just as it is useful to design your product before you build it.
I've been privileged to work in many organizations. They've run the gamut from strictly waterfall, with formal gates, reviews and signoffs; to completely ad-hoc and unstructured. What works in a particular group, I find, is largely determined by the culture of that group. A company selling into the staid, risk-averse world of telecom or storage is likely to take their time getting the designs right, the Ts crossed and the Is dotted. In contrast, a purely-software organization selling a Mere App may find themselves proceeding in a more Agile fashion, with constant integration and regular, frequent releases.
Of course, these are generalizations and are as correct as generalizations often are. Exceptions abound. The interesting point is that each approach has its advantages and disadvantages, and each has valuable practices to offer the other.
I like to develop in a more agile fashion. The source is continuously integrated; the builds do not break. On the other hand, I have learned that significant time spent on design and up-front testing (unit-, system-, and stress-) is time well-spent in the grand scheme of things, and will help avoid issues in the product further on down the road. The up-front focus needs to be reinforced. We all (me included) have the tendency to want to set fingers to keyboard too quickly :)
I haven't worked in a purely Agile shop; it seems to me to be more appropriate for pure software, and most appropriate for online applications rather than something downloaded and used locally by users. It's certainly inappropriate for long-term development of items such as chips (although it could well work for FPGAs). It seems to me that Agile, without appropriate discipline, could descend into Chaotic.
On the other hand, the classical waterfall model seems way slow for today's market, and its lack of constant feedback from users is a clear weakness.
I think my preferred methodology is a combination: not pure Agile, but using aspects of it, particularly the focus on sprints to numerous smaller goals on the road to "completion".
Perhaps the most important lesson, though, is to think about how we do what we do, and constantly optimize--just like tuning software, tune your process regularly.
Usually, we all develop with an approach that can be charitably characterized as pragmatic, and not-so-charitably as somnolent. Most organizations develop the way they've always developed, with very little introspection into how they do their thing, why they do it that way, or how they might improve.
It's worthwhile to see if you can clearly describe your development methodology, just as it is useful to design your product before you build it.
I've been privileged to work in many organizations. They've run the gamut from strictly waterfall, with formal gates, reviews and signoffs; to completely ad-hoc and unstructured. What works in a particular group, I find, is largely determined by the culture of that group. A company selling into the staid, risk-averse world of telecom or storage is likely to take their time getting the designs right, the Ts crossed and the Is dotted. In contrast, a purely-software organization selling a Mere App may find themselves proceeding in a more Agile fashion, with constant integration and regular, frequent releases.
Of course, these are generalizations and are as correct as generalizations often are. Exceptions abound. The interesting point is that each approach has its advantages and disadvantages, and each has valuable practices to offer the other.
I like to develop in a more agile fashion. The source is continuously integrated; the builds do not break. On the other hand, I have learned that significant time spent on design and up-front testing (unit-, system-, and stress-) is time well-spent in the grand scheme of things, and will help avoid issues in the product further on down the road. The up-front focus needs to be reinforced. We all (me included) have the tendency to want to set fingers to keyboard too quickly :)
I haven't worked in a purely Agile shop; it seems to me to be more appropriate for pure software, and most appropriate for online applications rather than something downloaded and used locally by users. It's certainly inappropriate for long-term development of items such as chips (although it could well work for FPGAs). It seems to me that Agile, without appropriate discipline, could descend into Chaotic.
On the other hand, the classical waterfall model seems way slow for today's market, and its lack of constant feedback from users is a clear weakness.
I think my preferred methodology is a combination: not pure Agile, but using aspects of it, particularly the focus on sprints to numerous smaller goals on the road to "completion".
Perhaps the most important lesson, though, is to think about how we do what we do, and constantly optimize--just like tuning software, tune your process regularly.
Wednesday, March 2, 2011
How to retain guest focus in VMware and still use CTRL-ALT.
My needs are modest, straightforward, and oft-thwarted.
Today's hope was two hours--two hours, I say!--of straightforward, unencumbered forward progress. Forward progress, in this case, ending in a decent hour-long training presentation with a few performance numbers thrown in. Like I say, modest.
Instead, I spent nearly an hour monkeying around with VMware's VCenter (it says 4.0, but I am guessing this is actually the 4.1 vintage, which comes with ESXi 4.1), which for reasons inscrutable, no longer seems to be able to pass the CTRL-ALT key combination to a guest operating system, instead taking the key sequence as a universal focus release. I think this behavior changed when I installed the 4.1 Vcenter client, but haven't spent the extra HOUR it might take to verify that. My old trick, pressing ALT-CTRL instead, no longer works. Someone suggested (in 2007) CTRL-ALT-space, letting up the space key, then hitting the function key....nope. No dice. Function keys don't work either.
KVM's Virt-Manager, while a ludicrous toy in nearly all respects when compared to Vcenter, at least has the power tool "send CTRL-ALT-F2, dammit" menu option.
So, you know what the workaround is? SHIFT-CTRL-ALT-F2.
That allows you to switch from the GDM screen to another pseudo console where you can actually log in as root.
But it doesn't work to get you back.
Sigh.
Today's hope was two hours--two hours, I say!--of straightforward, unencumbered forward progress. Forward progress, in this case, ending in a decent hour-long training presentation with a few performance numbers thrown in. Like I say, modest.
Instead, I spent nearly an hour monkeying around with VMware's VCenter (it says 4.0, but I am guessing this is actually the 4.1 vintage, which comes with ESXi 4.1), which for reasons inscrutable, no longer seems to be able to pass the CTRL-ALT key combination to a guest operating system, instead taking the key sequence as a universal focus release. I think this behavior changed when I installed the 4.1 Vcenter client, but haven't spent the extra HOUR it might take to verify that. My old trick, pressing ALT-CTRL instead, no longer works. Someone suggested (in 2007) CTRL-ALT-space, letting up the space key, then hitting the function key....nope. No dice. Function keys don't work either.
KVM's Virt-Manager, while a ludicrous toy in nearly all respects when compared to Vcenter, at least has the power tool "send CTRL-ALT-F2, dammit" menu option.
So, you know what the workaround is? SHIFT-CTRL-ALT-F2.
That allows you to switch from the GDM screen to another pseudo console where you can actually log in as root.
But it doesn't work to get you back.
Sigh.
Monday, November 29, 2010
neuron
beware: extrapolation at work
You're probably already forgotten the news story about Bill Nye. Sorry, I'm not firing fast enough these days.
So here's the deal. Bill Nye is talking at USC, and he passes out. Bad sushi or something. Whatever. He's fine, apparently.
But here's the interesting part. Instead of everyone rushing the stage to see what's wrong with him, or call an ambulance...apparently everyone tweeted. As one.
The Yahoo story characterizes this response as "the digital public's civic indifference" and "youthful digital passivity".
Maybe. Or maybe we're evolving. It strikes me that our constant, incessantly connected, instantly messaged habits are becoming more and more like the behavior of another life form: The neuron.
In Nicholas Carr's new book, The Shallows, he mentions the idea that our tools mold us and may--in fact, certainly are--evolving us. As we grow to use maps and globes, our directional senses wither, making room in our brains for other functions. As printed language becomes prevalent, our memory capacity shrinks, making more room for other cognition.
This evolution is not under our control. We are formed by our tools--consciously or not. The thought comes that perhaps it's not us that is the end-goal of evolution. Maybe some other entity is evolving. Maybe, as Marshall MacLuhan put it, we are becoming "the sex organs of the machine world". Or of some other world.
What if we're evolving into a world brain? I'm serious. Here are some numbers.
| Service | Population | connections per unit | Message Rate (per day) |
| 160 million | 126 | 7.5 * 10**7 | |
| 500 million | 130 | 10**9 | |
| Human brain | 100 billion | 7000 | 1.8 x 10**17 |
A couple of notes: my number for Twitter users and message rates assume continued expansion at a rate of 300,000 per day, and corresponding increase in update rates. This is, admittedly, a sketchy proposition. Twitter and Facebook are actually similar in terms of number of users, richness of connection and frequency of communication. They are both distinguished by anemic connectivity, when compared to the human brain's 7000 inter-neuronal connections. It's also hard to guess how many times your entire brain "fires" per day. I guessed 1.8 x 10**17, assuming an active firing rate of 400/second, and the brain is "active" 1 hour per day. That's 180 million billion firings per day, compared to Facebook's paltry 1 billion.
OK, so Facebook is off the mark at becoming a human brain by several orders of magnitude. On the other hand, a neuron firing is a single impulse. Binary. The average Facebook update? Rather more . Between text updates (a couple hundred characters--say 1000 bits, at 8 bits/character and 125 characters in the average update?) and videos (megabytes and megabytes), most Facebook updates, I guess, are pictures. The Facebook picture limit was 720x720 pixels until recently, so let's say that a picture on Facebook takes 720*720*8 = 4 megabits. Take that 4 million bits as the average message length, and the daily Facebook "firing rate" is 4 million billion. Facebook is only off the human brain, in terms of raw information flow, by two orders of magnitude. Now that's a little scary.
If rate of neuron firing were all there was to intelligence, then computers would be intelligent already (which they may be--see my earlier post).The rate isn't apparently as important as the richness of connectivity.
There are 500 million Facebook users, each with 130 axons--er, friends.This compares poorly to the brain's 100 billion neurons, each with 7000 connections--200 times too few, and 50 times too poorly connected.
200 and 50 are starting to look like small numbers, though. There are 500 million folks on Facebook--and 6.9 billion on Earth, growing, according to UN's medium estimates, to 10.5 billion by 2050. That's more people than there are neurons in a human brain.
So. If Facebook acquires a significantly larger portion of the world's population, and if we become more friendly and talkative, then the connectivity of that organism approaches that of the human brain.
H.G. Wells wrote a series of essays in 1938 about a "World Brain", but his World Brain was a tool created by people--an informational repository for improving human welfare and achieving world peace.
The real World Brain seems more Orwell than Wells. More like a beehive than a Utopia. The neurons are there to comprise the brain--not the other way around.
Sweet Dreams.
Thursday, October 14, 2010
A Babel of Coding Standards
Interesting pluralities for the day:
- a flotilla of handymen (all late)
- a Babel of coding standards
Interesting lesson of the day...Python. I know, being a hep systems programmer type, I really should know All Things Scripting language, but I've put off Python for a while. C and assembly are more my modus operandi. However, I've got a nifty, small little project and it seems a nice test subject for learning the language while I am stranded at home awaiting my flotilla of handymen.
Brief observations of the morning:
1. Any language where white space matters is ontically evil.
2. When one has directly-conflicting coding standards such as the Python recommendation and the Linux Kernel diktats, confusion ensues. Also side-diversions into mode-sensitive editor settings. Hence, a Babel of coding standards.
Now, I am sure that Emacs has some sort of artificially-intelligent agent inside it that automatically queries all currently-relevant authorities on coding standards and properly formats your code for you (once you issue the
Today's word of the day is "ontically", in case you have not noticed.
Here's an interesting way to set your VIM settings depending on where you are in the directory structure (courtesy of the VIM wiki):
That's neat, and would be handy for those cases where your personal C coding standard differs from the Linux standard, for example. However, what I really want is something that senses the language in which I'm writing and sets VIM up accordingly. And that's much easier.
Turns out that VIM has a filetype plugin that lets you bring in specific settings based on what type of file it is. Put
Oh. One more thing? If you invoke Vim as "vi", as I do (creature of habit), it tends not to bring in the hip new Vim functionality. I fix this by aliasing "vi" to "vim" (e.g. for bash):
- a flotilla of handymen (all late)
- a Babel of coding standards
Interesting lesson of the day...Python. I know, being a hep systems programmer type, I really should know All Things Scripting language, but I've put off Python for a while. C and assembly are more my modus operandi. However, I've got a nifty, small little project and it seems a nice test subject for learning the language while I am stranded at home awaiting my flotilla of handymen.
Brief observations of the morning:
1. Any language where white space matters is ontically evil.
2. When one has directly-conflicting coding standards such as the Python recommendation and the Linux Kernel diktats, confusion ensues. Also side-diversions into mode-sensitive editor settings. Hence, a Babel of coding standards.
Now, I am sure that Emacs has some sort of artificially-intelligent agent inside it that automatically queries all currently-relevant authorities on coding standards and properly formats your code for you (once you issue the
<alt>-<meta>-\\-please-format-my-code-o-genii-of-coding-standards-<ctrl> command). However, current estimates from the National Bureau of Editing Standards indicate that you need 16 gigabytes of memory to run Emacs these days[1], and anyways, it's ontically evil.Today's word of the day is "ontically", in case you have not noticed.
Here's an interesting way to set your VIM settings depending on where you are in the directory structure (courtesy of the VIM wiki):
" Set directory-wise configuration.
" Search from the directory the file is located upwards to the root for
" a local configuration file called .lvimrc and sources it.
"
" The local configuration file is expected to have commands affecting
" only the current buffer.
function SetLocalOptions(fname)
let dirname = fnamemodify(a:fname, ":p:h")
while "/" != dirname
let lvimrc = dirname . "/.lvimrc"
if filereadable(lvimrc)
execute "source " . lvimrc
break
endif
let dirname = fnamemodify(dirname, ":p:h:h")
endwhile
endfunction
au BufNewFile,BufRead * call SetLocalOptions(bufname("%"))
That's neat, and would be handy for those cases where your personal C coding standard differs from the Linux standard, for example. However, what I really want is something that senses the language in which I'm writing and sets VIM up accordingly. And that's much easier.
Turns out that VIM has a filetype plugin that lets you bring in specific settings based on what type of file it is. Put
enable filetype plugin in your ~/.vimrc, and then create a file ~/.vim/ftplugin/python.vim containing, e.g., the following (recommendations from the inestimable VIM wiki, again):
" File ~/.vim/ftplugin/python.vim
" ($HOME/vimfiles/ftplugin/python.vim on Windows)
" Python specific settings.
setlocal tabstop=4
setlocal shiftwidth=4
setlocal expandtab
setlocal autoindent
setlocal smarttab
setlocal formatoptions=croql
Oh. One more thing? If you invoke Vim as "vi", as I do (creature of habit), it tends not to bring in the hip new Vim functionality. I fix this by aliasing "vi" to "vim" (e.g. for bash):
alias vi=vim
[1]Alas, my personal experiments show vim using 3/4 the memory of Emacs. It's catching up. Sigh.
Friday, September 17, 2010
panic: out of coffee
This message has been automatically generated in response to the creation of a trouble ticket regarding:
"Bwoop bwoop bwoop. Coffee machine DOWN. Productivity CRASHING. Bwoop Bwoop Bwoop."
There is no need to reply to this message right now. Your ticket has been assigned an ID of [rt.thecompany.com #19892]. Please include this string in the subject line of all future correspondence about this issue. To do so, you may reply to this message.
To view your request or check current status, you can visit:
http://helpdesk.thecompany.com/SelfService/Display.html?id=19892
-------------------------------------------------------------------------
Please address this critical IT-related issue with the Utmost Urgency. Coffee Machine has CRASHED with a kernel panic, saying "Water Level Error". We may need kernel patches or something. Meanwhile I am struggling by on an ersatz Americano made from the half-carafe of sludge that actually emerged from our erstwhile drip machine before its untimely demise. Any apparently-hysterical ramblings on my part can be blamed on an uneven caffeine supply.
Subscribe to:
Posts (Atom)