I posted earlier that Barbara Nelson of Pragmatic Marketing will be one of the presenters at ProductCamp this Saturday. When a company I was working with six years ago hired Pragmatic Marketing to teach everyone their system, it was a definite game changer, and she was the one who taught the course. For my part, as a software engineer, I learned from her how to work much more closely and effectively with the marketeers. The insights we all gained from Pragmatic Marketing’s experience were invaluable. They are lessons that I continue to apply every day.
Best practices evolve. The best practices for writing software are no exception. Here are a number of conventions and practices that used to be considered good in the past, together with the new ways of doing things, and why. Continue reading That’s So Yesterday! (On Writing Better Software)→
Mary Poppendieck’s seminal work, Lean Software Development: An Agile Toolkit, lists the 7 wastes of manufacturing and maps them to software development, among other things. (In a recent webcast, Poppendieck added 3 more wastes to the list, and I’ll write about those in another post.) Of the original seven wastes, the one that I found most enlightening is that unfinished projects lying about is the equivalent of having excess inventory on hand. Continue reading Unfinished Projects = Costly Excess Inventory→
Product Managers and Project Managers will be gathering for an “unconference” at U.C. Irvine next Saturday. It’s free to sign up for anyone who’s interested. Go to http://www.productcampsocal.org to sign up to attend and also to vote on the sessions you’d like to see.
One of the proposed sessions is being led by Barbara Nelson of Pragmatic Marketing. She’s was my instructor when I took the Pragmatic Marketing course six years ago, and I’m very much looking forward to seeing her again. If her participation is any indication of the general caliber of this event, then we all stand to gain greatly. See you there.
One of the reasons that pair-programming works so well is the same reason that brainstorming is such a powerful technique in a group setting. Pairing basically amounts to an endless stream of mini-brainstorms between the two partners. I swear that whenever I pair with someone, we’ll write code that is easily three times tighter and cleaner that if I had written it alone, and I think the brainstorming aspect has a lot to do with why.
In formal brainstorming, you start with an initial pool of ideas and build it up by pushing the boundaries, piggy-backing on the previous ideas, and inverting or negating the previous ideas. It’s the job of everyone to be contrariwise with each other — to keep asking “What if?” and “Why not?” In pair programming, a similar thing happens. It’s the job of the person who’s riding shotgun to be looking at the bigger picture (while the one who’s driving is focused more on the task at hand), and this is what makes for the same kind of contrariwise/collaborative atmosphere as brainstorming.
The U.C. Institute for Software Research (ISR) hosts free monthly lectures by thought leaders in software development. The Winter/Spring schedule has been posted. It includes topics ranging from architectures for mobile computing to social intelligence.
There is no charge to attend Distinguished Speaker meetings, but RSVP required. Distinguished Speaker meetings are held on the U.C. Irvine campus, typically in the Donald Bren Hall, room 6011.
The famous Microsoft interview process (as described by William Poundstone in "How Would You Move Mount Fuji? Microsoft’s Cult of the Puzzle…") asks the candidate, among other things, to solve puzzles such as the quintessential question, “Why are manhole covers round?” It’s a question with multiple answers (see below), and the interviewer is looking for how the candidate approaches the question more than what answers are givens.
I started playing with pivotaltracker.com today, which is a free, hosted storyboard tool. It’s free, but not open source, so you do not have the option of hosting it yourself, which means you’ll have to trust Pivotal Labs with your data. This includes: trusting that the service will remain up, trusting that the service will remain free, trusting that Pivotal won’t use your data to compete with you, etc. Some of these issues can be mitigated (e.g. by performing frequent exports of your data.)
In a side conversation at the Orange County APLN meeting last week, we got to talking on the subject of role-based security, and I said that there should be a strict separation between permissions and roles, and between roles and users. That is, that the programmers should code their security checks only against permissions (never directly against roles or users), and, going the other way, that users should only be assigned roles (never assigned permissions directly). Continue reading Role-Based Security and Separation of Concerns→
I posted earlier that Barbara Nelson of Pragmatic Marketing will be one of the presenters at ProductCamp this Saturday. When a company I was working with six years ago hired Pragmatic Marketing to teach everyone their system, it was a definite game changer, and she was the one who taught the course. For my part, as a software engineer, I learned from her how to work much more closely and effectively with the marketeers. The insights we all gained from Pragmatic Marketing’s experience were invaluable. They are lessons that I continue to apply every day.
