I started the new job at Industrial Logic. In addition to receiving online training from my peers here, I'm getting into the source code of our products (some cool stuff in there). Yesterday I got to exercise my google and stackoverflow skills as we dug into a windows-based product. My .NET work until now has been web, not native, so this was new territory for me and I had a great time.
In addition, I'm getting involved in contract work here and strategy. It's only day 4, and I'm feeling like I'm really a part of the team. You would not believe how much we are in contact even as remotes. I probably talk to my coworkers ("boss" included) much more often than you cubicle-dwellers do. I still get think-time alone, but I'm getting to know and enjoy people pretty well.
Enough of this, there's code waiting...
Tim Ottinger's thoughts on Software Development.
Thursday, March 31, 2011
Thursday, March 24, 2011
Industrial Logic
Your agile otter has joined Industrial Logic. We have so much in common that it didn't make sense not to join forces. I will be neck deep in products, courseware, metrics, and all of the other work that makes them so cool. This will be like chocolate and peanut butter, friends. I can't wait to join all my new best friends!
Friday, March 18, 2011
Uncle Bob's Clean Code Video
The latest Clean Coders video by Uncle Bob Martin covers Chapter 2 of the book Clean Code. This is a chapter that is near to my heart, since it bears my name and Uncle Bob even presents some flattering introductory material with a decidedly unflattering picture of me (all in good fun). The video is $12.00, but is quite well done and interesting.
The less entertaining version which was the source for the well-edited version in Clean code is still available, and has examples in Python rather than Java. Bob's presentation has some thoughts not included in my paper (and which I endorse). The paper is not a replacement for watching Bob's zany and entertaining video but it can give you some of the same material while you ponder spending your hard-earned ten-spot-and-change.
The less entertaining version which was the source for the well-edited version in Clean code is still available, and has examples in Python rather than Java. Bob's presentation has some thoughts not included in my paper (and which I endorse). The paper is not a replacement for watching Bob's zany and entertaining video but it can give you some of the same material while you ponder spending your hard-earned ten-spot-and-change.
Wednesday, March 16, 2011
Make the Retrospective Effective
With my last employer, we had noticed that our retrospectives were starting to lag in effectiveness and attendance. People felt like they were too busy delivering stories and solving problems to do anything substantial toward meeting retrospective goals. I knew that it wasn't the kind of company that would accept stalled improvement, yet developers were instinctively afraid to invest time.
To resolve the problem, I talked with the CIO. Our discussion ended up with this set of triage rules for retrospective follow-ups:
This triage system worked, and for the next several months we had items in all three categories.
No retrospective technique I've found will be able to single-handedly keep retrospectives fresh and vibrant and productive in perpetuity, but this one was useful to shake off a fear of lost productivity long enough to get some good changes in place and to conduct some good experiments. We did a few large-scale changes, which really were also experiments. A lot of the work paid off.
If your retrospectives are going stale, you might talk with your C-level supporters and bring the team a policy that clearly spells out their permission to try, change, and grow. Developers want to be productive (a fact worthy of a blog series if not a new book), and may need to be encouraged to look past the stories and tasks to work that might accelerate the whole team.
To resolve the problem, I talked with the CIO. Our discussion ended up with this set of triage rules for retrospective follow-ups:
- If it is free, just do it.
- There is no reason to delay implementing some changes, including (but not limited to):
- posting a graph,
- composing a "top-ten" list,
- swapping pairs more often,
- trying pomodoro technique,
- changing how stand-up meetings are performed,
- making better use of QA, tech writing, or Customer resources
- instituting changes to coding standard
- If it takes a couple of man days, just do it.
- The team was surprised that they could peel off a member or a pair to do technical work that would improve the team. This allowed the team to take on tasks like improving the build system, metrics gathering, checking out new mocking libraries, solving version control process problems, performing global clean-ups like duplication removal, writing instructions on the team wiki. We were, in fact, not permitted to not do these things. We happily devoted a few man days per iteration to accelerating the team.
- If it will take longer, we should talk about it
- There were architectural changes, large legacy code reworks, and grand experiments that came up in the retrospectives. Some people were afraid to even mention something that might take *weeks* of developer time to complete. People were surprised to hear that management was not against such things, but merely wanted to be measured and cautious with goals, measurement, and timing. We did some large things, and we failed some grand changes (as one might suspect) but we didn't fail for lack of permission.
This triage system worked, and for the next several months we had items in all three categories.
No retrospective technique I've found will be able to single-handedly keep retrospectives fresh and vibrant and productive in perpetuity, but this one was useful to shake off a fear of lost productivity long enough to get some good changes in place and to conduct some good experiments. We did a few large-scale changes, which really were also experiments. A lot of the work paid off.
If your retrospectives are going stale, you might talk with your C-level supporters and bring the team a policy that clearly spells out their permission to try, change, and grow. Developers want to be productive (a fact worthy of a blog series if not a new book), and may need to be encouraged to look past the stories and tasks to work that might accelerate the whole team.
Tuesday, March 15, 2011
Agile And Beyond Party
I attended only two talks, and spent the rest of the time hanging out with my peers and having fun. The two talks were Mary Poppendieck's talk about where she sees post-agile going (a nice talk, btw, well given) and Dr. Michael Norton (docondev's) talk about technical debt.
I was ill-rested, over-caffeinated, and a little eager. I had motormouth, but it was still a great time )for me). I hope that Mike Hill, Tracy and Angela Harms, Matthew Weitzel, Patrick Wilson-Welsh, Michael Norton, Zachary Spencer, Nayan Hajratwala, Matt Barcomb, Jon Stahl, Bill Tozier, and all the rest (drop me a note if I forgot to mention you) all had as much fun as I did.
Best wishes to my colleagues on the other side of the lake!
Wednesday, March 9, 2011
Stop hating on the command line
Let's begin with this simple assertion: command.com sucks. It has always sucked, and always will. Powershell might be nicer, but most people haven't learned how to use it, and it's only available in one operating system anyway.
If I say "command line" to a Windows-only person, they're thinking "command.com." Avoiding that command line is a huge part of making their lives pleasant. I am not slamming on hating the windows command line. All of us Unix/Linux geeks hate it too. I never feel much less productive than when I'm in command.com. I avoid it too.
I started back when CP/M was the killer operating system. Its command line was not so great either, but it had a strong free software community who shipped programs to each other on floppy disks. As a result, we had this language called "submit" (and later "supersub") which you could actually do stuff in. It was like a real language. The command line suddenly was pretty decent.
When the PC came out, it pretty much got rid of the CP/M market, and with it the community. DOS had batch files and command.com, and those were okay. You really had to use those tools, because there was not much else. Eventually GEM and DESQview came along, and multitasked your DOS text apps nicely. They were taking hold when Windows first came out and destroyed the market and community for those programs. But that's neither here nor there.
What happened in the 80s that turned me into a command-line fan was my defecting to Unix and learning to use a proper command line. Bash and Zsh are the popular, ubiquitous shells these days but in the days when I jumped in the world was divided into csh and ksh users. All of these shells are command-line interfaces to the whole freaking operating system, and the Unix designers (then and now) worked to make everything available to the shell. Instead of a crummy one-line window to slow-key commands into, these were full programming languages with proper variables, decent flow control, error reporting and handling, wildcarding, extensibility, event-handling, online help, and access to system innards. It went far beyond meager batch files.
It just got better with each generation of shell. You an launch subshells, and stack shells so that you can "pop" back to an earlier context. Each subshell has its own current directory, and any one shell can have a stack of directories (pushd/popd/rotd), each shell has history and history search. There is process control and the ability to pull processes into background and foreground. There are rich stream-oriented languages and tools for processing data. There is more functionality in the command line than you can take in at a glance.
The manual page for bash (arguably the most ubiquitous shell) is over 3000 lines long. I know because I did "man bash | wc -l" to find out. Considering that the documentation is terse, that represents a heck of a lot of functionality. Zsh is so feature-rich its manual has been broken into 17 chapters.
Of course, these are available via cygwin for you windows machines (if you really have to use windows) but will be slow because windows file systems are slow, and are a little crippled because windows has a different design philosophy than the Unixen do.
But the point is that "avoid the command line," however reasonable when the command line is command.com, is hardly a universal goal. Instead, mac and linux and unix people almost universally embrace the command line, often preferring it to gui tools to do the same jobs. It is explorable, scriptable, powerful, and useful.
So stop hating on 'the command line.' Next time, windows users, say "I hate my command line." Install cygwin (or better, Ubuntu) and give the manuals a little light read. You will be surprised what power lies just under the GUI.
For the record, GUI is kinda cool, too.
If I say "command line" to a Windows-only person, they're thinking "command.com." Avoiding that command line is a huge part of making their lives pleasant. I am not slamming on hating the windows command line. All of us Unix/Linux geeks hate it too. I never feel much less productive than when I'm in command.com. I avoid it too.
I started back when CP/M was the killer operating system. Its command line was not so great either, but it had a strong free software community who shipped programs to each other on floppy disks. As a result, we had this language called "submit" (and later "supersub") which you could actually do stuff in. It was like a real language. The command line suddenly was pretty decent.
When the PC came out, it pretty much got rid of the CP/M market, and with it the community. DOS had batch files and command.com, and those were okay. You really had to use those tools, because there was not much else. Eventually GEM and DESQview came along, and multitasked your DOS text apps nicely. They were taking hold when Windows first came out and destroyed the market and community for those programs. But that's neither here nor there.
What happened in the 80s that turned me into a command-line fan was my defecting to Unix and learning to use a proper command line. Bash and Zsh are the popular, ubiquitous shells these days but in the days when I jumped in the world was divided into csh and ksh users. All of these shells are command-line interfaces to the whole freaking operating system, and the Unix designers (then and now) worked to make everything available to the shell. Instead of a crummy one-line window to slow-key commands into, these were full programming languages with proper variables, decent flow control, error reporting and handling, wildcarding, extensibility, event-handling, online help, and access to system innards. It went far beyond meager batch files.
It just got better with each generation of shell. You an launch subshells, and stack shells so that you can "pop" back to an earlier context. Each subshell has its own current directory, and any one shell can have a stack of directories (pushd/popd/rotd), each shell has history and history search. There is process control and the ability to pull processes into background and foreground. There are rich stream-oriented languages and tools for processing data. There is more functionality in the command line than you can take in at a glance.
The manual page for bash (arguably the most ubiquitous shell) is over 3000 lines long. I know because I did "man bash | wc -l" to find out. Considering that the documentation is terse, that represents a heck of a lot of functionality. Zsh is so feature-rich its manual has been broken into 17 chapters.
Of course, these are available via cygwin for you windows machines (if you really have to use windows) but will be slow because windows file systems are slow, and are a little crippled because windows has a different design philosophy than the Unixen do.
But the point is that "avoid the command line," however reasonable when the command line is command.com, is hardly a universal goal. Instead, mac and linux and unix people almost universally embrace the command line, often preferring it to gui tools to do the same jobs. It is explorable, scriptable, powerful, and useful.
So stop hating on 'the command line.' Next time, windows users, say "I hate my command line." Install cygwin (or better, Ubuntu) and give the manuals a little light read. You will be surprised what power lies just under the GUI.
For the record, GUI is kinda cool, too.
Monday, March 7, 2011
Python for Everyone At My House
I started teaching my youngest son python years ago. I started him with the turtle package and he drew circles, lines, and squares. He had a great time doing things like creating variables that carry his brother's name and setting them equal to "llama butt." Now he's older, and wanting to do some more programming.
We decided to start with a simple guessing game, and picked "battleship." I also decided that he's old enough to get a handle on tests and classes.
Tonight we decided what the rules were, and wrote some tests for creating ships and blowing them up. We'll be revisiting the stuff we've done, but by watching me and copying the text I typed he was able to run the tests a few dozen times, create a class, and start dealing with syntax and logic errors.
It's just a start. We'll have to get into it more deeply before we'll know if he really likes it, but I'll keep you posted.
We decided to start with a simple guessing game, and picked "battleship." I also decided that he's old enough to get a handle on tests and classes.
Tonight we decided what the rules were, and wrote some tests for creating ships and blowing them up. We'll be revisiting the stuff we've done, but by watching me and copying the text I typed he was able to run the tests a few dozen times, create a class, and start dealing with syntax and logic errors.
It's just a start. We'll have to get into it more deeply before we'll know if he really likes it, but I'll keep you posted.
Friday, March 4, 2011
A Fun Teamwork Experiment
I want to take four teams of four people and arrange them in groups. Each group gets an identical book of crossword puzzles (or maybe a web printed book of a dozen puzzles of varying difficulty).
We would count finished puzzles once per minute per team. We would let the experiment continue until one of the teams finishes its set of puzzles.
Publish the findings, and publish notes on how each team *felt* about their work style, and what they think they would do differently.
That's it. I would like to see how it comes out. If you have the time and enough people to try this, please follow-up with a comment here to tell me how it went. Better yet, write it up on your blog and send me a link. This could be a load of fun!
- The first group divides the book in four pieces and each member does 1/4 of the book.
- The second group takes one page at a time. The first guy does as much as he can and passes it to the second, and so on.
- The third group divides the book in half parts and solves puzzles as pairs.
- The fourth group has no rules about how to divide and organize the work.
We would count finished puzzles once per minute per team. We would let the experiment continue until one of the teams finishes its set of puzzles.
Publish the findings, and publish notes on how each team *felt* about their work style, and what they think they would do differently.
That's it. I would like to see how it comes out. If you have the time and enough people to try this, please follow-up with a comment here to tell me how it went. Better yet, write it up on your blog and send me a link. This could be a load of fun!
Thursday, March 3, 2011
Stepping up Django Efforts
Today we stepped it up a bit. Jeff Langr and I worked on our little project (shhh! it's a secret) and spent much of the day in django learning to test things. It cured a number of my developers' diseases and we got a bit done.
We started out trying to use Lettuce, which is a good idea and worth improving. We got a couple of tests working, using the client to send get results from the server and BeautifulSoup to parse the returned html. It was mostly a good experience, but then we found out that our handlers weren't specific to the scenario or the feature or even the file or directory. If you register a 'before' it's 'before' everything (it seems). Still we got some experience with it, and I think it'a great idea. With some scoping rules attached it would be totally awesome for ATDD, and I dig that it's pure python so you don't have to have a bunch of different languages & tools to do the work. It's a good start.
We picked up with more standard unit tests after lunch, calling the view function and letting it do the work. We figure that we don't really have to do a lot of through-the-browser testing, since django works pretty well and we're going to demo features before calling them 'done.' Heck, we'll probably try a few more ATDD tools before we're done.
We made a little progress on another page, and started to refactor it into a decent shape. I'll probably go on with that on my own a while. I think I have a good handle on this now, but will still do a fair amount of experimenting before this is done.
For django, my feelings are mostly positive. It's simple enough, works, and is fairly logical. I have not come to terms with which libraries I have to import everything from, but otherwise am gaining fluency. I have much to learn. I really wish that the objects were mapped to the ORM instead of being instances and attributes of ORM classes. They've gone to some lengths to make it easy to work with ORM classes instead of easy separation, but they've done a good job.
More later.
We started out trying to use Lettuce, which is a good idea and worth improving. We got a couple of tests working, using the client to send get results from the server and BeautifulSoup to parse the returned html. It was mostly a good experience, but then we found out that our handlers weren't specific to the scenario or the feature or even the file or directory. If you register a 'before' it's 'before' everything (it seems). Still we got some experience with it, and I think it'a great idea. With some scoping rules attached it would be totally awesome for ATDD, and I dig that it's pure python so you don't have to have a bunch of different languages & tools to do the work. It's a good start.
We picked up with more standard unit tests after lunch, calling the view function and letting it do the work. We figure that we don't really have to do a lot of through-the-browser testing, since django works pretty well and we're going to demo features before calling them 'done.' Heck, we'll probably try a few more ATDD tools before we're done.
We made a little progress on another page, and started to refactor it into a decent shape. I'll probably go on with that on my own a while. I think I have a good handle on this now, but will still do a fair amount of experimenting before this is done.
For django, my feelings are mostly positive. It's simple enough, works, and is fairly logical. I have not come to terms with which libraries I have to import everything from, but otherwise am gaining fluency. I have much to learn. I really wish that the objects were mapped to the ORM instead of being instances and attributes of ORM classes. They've gone to some lengths to make it easy to work with ORM classes instead of easy separation, but they've done a good job.
More later.
Wednesday, March 2, 2011
Regaining Humility and Thereby Sanity
I got too big for my britches last week and was feeling kinda saucy. I figured that having read a tutorial some time ago should be enough for a smart guy like me, so I started up a web project and an app and slammed in some model work, splashed an url on, and was thinking I knew what i was doing. No tests, but heck it's only a few lines of code and some generated stuff.
Then the test thing got to me. I started searching to see some testing tools, and ended up reading three paragraphs of every tool tutorial I could find. I pulled down a few testing tools. I started writing a test, and before I could really evaluate whether I liked how it was going started to mix different test libraries together. Pull the html parsing from here, the basic test setup from there, the helper routines from another place and pretty soon...
Pretty soon I realized that I wasn't learning anymore. I was permuting and chasing error messages and flailing and feeling kind of frustrated and lost.
Today I deleted everything I was working on, started a new virtualenv with just the stuff I really think I want to use, and I'm going to do things as the authors intended instead of the way that seems right to me.
I learned a lot of little things while exploding in all directions, but I'd have learned more and probably been done if I had tried to maximize depth of learning and not surface-scraped too many things for my poor little brain.
A little while ago someone put up a tweet suggesting that when you are trying to learn a lot of stuff, you should remember to chew and swallow the information. I realized I'd stuffed my face. This time, I will respect that there is a rate of absorption, and see how much better I can get.
I had exceeded the WIP limits of my own brain. I can never pick on managers for that again, because we all sometimes are tempted to use the blender-funnel-and-plunger method of taking in too much too fast, whether information, work, or whatever.
Wish me and my newly regained humility some luck.
Then the test thing got to me. I started searching to see some testing tools, and ended up reading three paragraphs of every tool tutorial I could find. I pulled down a few testing tools. I started writing a test, and before I could really evaluate whether I liked how it was going started to mix different test libraries together. Pull the html parsing from here, the basic test setup from there, the helper routines from another place and pretty soon...
Pretty soon I realized that I wasn't learning anymore. I was permuting and chasing error messages and flailing and feeling kind of frustrated and lost.
Today I deleted everything I was working on, started a new virtualenv with just the stuff I really think I want to use, and I'm going to do things as the authors intended instead of the way that seems right to me.
I learned a lot of little things while exploding in all directions, but I'd have learned more and probably been done if I had tried to maximize depth of learning and not surface-scraped too many things for my poor little brain.
A little while ago someone put up a tweet suggesting that when you are trying to learn a lot of stuff, you should remember to chew and swallow the information. I realized I'd stuffed my face. This time, I will respect that there is a rate of absorption, and see how much better I can get.
I had exceeded the WIP limits of my own brain. I can never pick on managers for that again, because we all sometimes are tempted to use the blender-funnel-and-plunger method of taking in too much too fast, whether information, work, or whatever.
Wish me and my newly regained humility some luck.
Tuesday, March 1, 2011
COTW: Build Superior Systems With Simple Design
The original article is at the Agile In A Flash blog, and has slightly different wording. We adopted the phrasing from c2.com's page.
I was pretty jazzed about having this card in our project, because it really does capture almost all of the code values and most design principles all in four little rules. It has always been profound in its simplicity. I wish we were able to make all of our cards and articles as concise and deeply applicable.
My idea of a great teaching program would be to start with this card, a testing library, and a programming language. We would do some exercises following these rules. After doing some projects to get our testing and refactoring skills up to par, I would bring in the four big ideas one at a time, so we could see how to better focus our work. Then probably I would bring in the seven code virtues and SOLID. Then we would call it "a good start" and I would go home. The class could pick up books on continuous integration and refactoring, and probably be able to run on their own indefinitely.
Learning the language, frameworks, and operating system quirks would be the other side of the coin. Ideas and ideals sound simple until you get to some ugliness in the OS or the web server or browser oddities. That's when you go back to this card. With simple design, you can weather some pretty amazing technical crapstorms.
This card is one part checklist, one part process. The rules are in priority order (just like "make it run, make it right, make it fast, make it small"), and also in process order. Cool stuff, huh?
So, run all your tests. Write a new test. Make it pass. Look for duplication, and kill it. Do you and your current pair programming partner agree that it makes good sense as-written? If not, fix it. Now, do you have any leftover bits that you don't need, any architectural artifacts you can live without? Unnecessary round-trips? Extra "cool" technology you can do without? Run all your tests. Start over.
Subscribe to:
Posts (Atom)