Raven's Brain v1.0: Software & Web Development

Software Development: Embracing Criticism Is Good For Business

Sat, 24 May 2008 15:27:40 GMT

Christopher Hawkins has a great post on the benefits of defects and bug reports in software development: Embracing Criticism Is Good Business. If you've worked in software/IT for very long you know how some (a lot of) engineers react to defects in their code. Most dread bug reports, some fear them and others choose to simply ignore them. Read Christopher's post and perhaps print it out and/or share with your team. It's an insightful piece on developing "good" software, really caring about what you're building and striving for the very best while working though defects. It's about changing peoples thinking about bugs and (hopefully) getting development "excited" about rooting out defects until the last, defiant bug is killed. Here's an excerpt:

What more developers need to realize is that a bug report is not a personal referendum on your worth as a human being. In fact, I'll go a step further and say that a bug report is not even a comment on your worth as a software developer (although a dozen bug reports against the same piece of code just might be). Now listen carefully, ladies and gents, I'm about to get to the heart of the matter: a bug report is an opportunity. No more and no less. When that user presents a bug to you, it is a plea for help, even if it is phrased in a way that sounds damning. It is also a challenge. And most of all, it is a business opportunity.
Call me a freak, but I get excited about bug reports. Not little-kid-on-Christmas-morning excited, but excited. And no, I don't salt my code just so I can get the emotional payoff (and additional billable) of being the hero who fixes the crucial bug just in the nick of time. I know guys who do that, and I find it despicable. No, I get excited about bug reports for a few reasons:

The fix is often a chance to make something within the application faster/cleaner/easier to use, etc.
If the bug is due to a failure of spec, it is often a chance to learn something new about my client's business
The fix is often a good excuse to either learn a new technique or apply one recently learned
I know that fixing the bug will make the customer happy, thereby contributing to a good relationship and continued revenue

Read more here: http://www.christopherhawkins.com/10-21-2004.htm#47

More great thoughts await you - go read the post if you work in software!

posted by Raven at Raven's Brain under Software & Web Development
Tags: Software & Web Development, Defects, Bug Reports, Software Development, Software Project Management

Peer Code Reviews Yield More Than a Goodnight's Sleep

Tue, 18 Mar 2008 03:22:13 GMT

A post from Lisa's bad brain, guest voice inside Raven’s Brain.

I have been managing a product development team at msnbc.com for almost three years now and have always seen peer code reviews as an essential activity in the certification process of a feature—a check-point that helped me sleep better at night. The prospect of my team tripling in size in a four month timeframe got me thinking about how to maximize the benefit of the code reviews we were conducting, so I thought it fortuitous when Raven sent me the free book offer for Jason Cohen’s Best Kept Secrets of Peer Code Review and quickly signed up (btw, if you click the link, the offer still seems to be valid). Time was not on my side of course (is it ever?), and reading the book kept falling behind other priorities—we were already doing code reviews, after all, so I could sleep at night knowing our code was not going to bring down the site. What I started noticing, however, is that the dynamic of our peer code reviews was maturing into a team-building and socialization exercise as a natural result of this growth, so when I saw the copy of Jason’s book in the stack I have been meaning to read, I picked it up with more interest than ever.

Cohen’s book offers a number of practical, easy to implement, techniques for conducting efficient peer code-reviews--some I had already been exposed to, and some I plan to try out—but it was the chapter on the “Social Effects of Peer Review” that I found the most insightful, considering what I was witnessing within my own team. Cohen states that his experiences with peer code reviews have uncovered “several social issues that managers and team-leads should be aware of. Some are positive and should be encouraged in the group; others are negative and need to be addressed in a way that is both sensitive and effective.”

Unexpected positive social aspects

The “Ego Effect,” according to Cohen, is one aspect of the peer review process that leaders must be keenly aware of, as it can have positive or negative effects--it can either foster or harm team dynamics. Since we are all ego-driven individuals, we want to be known for our success and not our failures. When a developer is assigned to a project, he or she naturally wants the response to be positive, “oh yeah, his stuff is pretty tight. He’s a good developer,” and not something like “he’s pretty good but makes a lot of silly errors. When he says he’s done, he’s not.”

Cohen goes on to argue that “Old Habits Die Easy,” so peer code reviews can be as helpful to the reviewer(s) as the coder(s). He recounts an experience where he was reviewing a particular line of code that was correct, but written differently than he would have done it. Knowing this method would work, he could have moved on, but instead the author asked the developer why it was written this way. What he learned in the process was a new trick that he could easily incorporate into his code. “Normally you think of the review process as unidirectional—the reviewer points out problems for the author, and the author might learn something in the process. But here I was the reviewer, and yet I was the one who was learning!” Knowledge sharing between reviewer and author lead to collective insights that “were spread around correctly – far faster than any other technique we could have invented.”

Cohen promises that it gets even better and suggests an exercise that involves logging every error made in a week, including such things as spelling errors in emails was well as mistakes made in code while unit testing. According to Cohen, you will start to recognize patterns in the “mistakes” you make, and by the second or third day, the annoyance of the exercise itself will lead you to start thinking about it consciously, anticipate the mistake, and prevent yourself from making it. “Over time you become more productive, more efficient,” Cohen states. “You’re working faster and smarter….by observing yourself just a little more carefully and systematically.” This, he observes, is systematic personal growth—it begins with the recognition that one tends to make certain mistakes and our desire not to make the same mistakes again leads to self-correcting behavior.

Handling hurt feelings, and the “Big Brother” effect

If not managed proactively, however, the social effects of peer reviews can be more damaging that helpful. Hurt feelings and the “Big Brother” effect are two negative side-effects of the “Ego Effect” that must be properly mitigated by management in order to maximize the positive social effects and minimize the negative. Everyone responds to and/or perceives criticism differently, thus to foster the positive social effects, managers need to focus on the identification of defects as a positive. The “Big Brother” effect kicks in when developers feel that their defect ratio will be used against them--if someone is looking over our shoulder, we are more likely to mask defects rather than focus on the positive effects of finding one! In order to combat these factors, Cohen argues that managers need to understand that the quantity of defects found in a code review is subject to a variety of influences that do not represent the capability of the developer producing the code, and then instill this same understanding within the team. In order to accomplish the latter, the author suggests four key messages to convey:

Hard code has more defects
A peer review of complex code should surface more defects than a review of less-complex code—“if your reviewer didn’t find them, wouldn’t you worry about the quality of the review?”
More time yields more defects
Studies show the amount of time spent reviewing code has a direct correlation to the number of defects identified, so quantity of defects logged is not necessarily about how “good” the code was.
It’s all about the code
The goal of this process is to make the code as good as possible.
The more defects the better
Defects are learning experiences and opportunities for personal and team growth. To drive this point home, Cohen insists that managers must reassure the team that defects will NOT be used in performance evaluations. I found this particular argument interesting considering the interview Raven did recently with [Curt finch, who does advocates for just the opposite.

Ok, but really. The more defects the better? This is hard to swallow, especially for someone who used to sleep better when we found fewer defects during a code review, that when we found more, because I was satisfied this meant the code was solid to begin with.

Rest assured, says Cohen: “the more defects found, the better the team is working together. It doesn’t mean the author has a problem; it means they’re both successfully exploring all possibilities and getting rid of many mistakes. Authors and reviewers should be proud of any stretch of code were many defects were found and corrected.”

Ok, then, the more defects the better. If I can rally my team around that, I should be able to maximize the positive effects of the social experience I noticed our reviews becoming due to growth. And, knowing what to look out for, I should be able to mitigate the ego-damaging factors that could undermine the intent. And our peer code reviews might just become something much more valuable than a good night’s sleep!

Posted by Lisa Forsyth at Raven's Brain under Software & Web Development
Tags: Software & Web Development, Software Development, Code Reviews, Software Quality, Peer Code Reviews, Web Development, Programming, IT Management

Programming Humor: Simplicity and Software

Tue, 11 Mar 2008 17:52:11 GMT

Here's a great image for techies from Eric Burke over at StuffThatHappens.com. Anyone who's ever worked in software/web development will surely appreciate "simplicity"

Direct link ro original image: http://stuffthathappens.com/blog/2008/03/05/simplicity/

I *love* the "OKAY" button!! If you're a glutton for punishment there are some amusing comments following the image at the original post - especially the whole "apples V. oranges" commentary!

posted by Raven at Raven's Brain under Software & Web Development
Tags: Software & Web Development, Programming Humor, Software Cartoon, Tech Humor, Programming

Nine things you need to know about SaaS

Thu, 01 Nov 2007 01:50:29 GMT

The Journyx PM blog referred me to a great tech article: Nine things you need to know about SaaS. It's a timely article that discusses SaaS as it becomes more mainstream and also highlights potential issues, challenges and questions you should consider. The "9 things you need to know" are:

What is SaaS?
"Software as a service, sometimes known as on-demand software, is a new model for deploying business services ... that requires the provider ... to make access to the functionality available typically through a browser," West says...
What about security? If our data is sharing a database with other organizations, possibly including competitors, how can we be sure we are safe?
"The security solutions offered by SaaS vendors are quite excellent," West says, and the danger of corporate espionage is virtually nonexistent. In some cases, some SaaS providers can even keep critical data inside firewalls for those clients who may require it. However, SaaS clearly isn't the right solution for preserving the nation's nuclear secrets..."
How do SaaS providers charge?
"Typically, users pay as they consume the service on a subscription basis," West says. "Pricing per user per month is the most common model. Pricing by transaction is another. There are a variety of metrics..."
What kinds of services do SaaS vendors provide, and how do they deliver those services?
"...provide a wide variety of services spanning both end-user functionality and IT infrastructure, such as network security, e-mail and collaboration. The latest trend in service development is for SaaS vendors to provide entire sets of IT services -- "everything a business could need" -- on a unified platform, West says..."
Is SaaS mostly for SMBs, or does it have things to offer to large enterprises?
Recently, SaaS penetration in the small-to-midsize business (SMB) market has been growing quickly, but penetration is happening in waves, West says. He estimates that the SaaS market may actually have greater penetration in large companies today, if one includes 2007 plans to implement SaaS solutions.
How mature are SaaS services?
Saugatuck Technology identifies three waves of market development. In the first, stand-alone SaaS services penetrated organizations mostly by selling directly to business units, with little IT involvement or, in many cases, knowledge...

Image from the Formtek blog of SaaS adopters from 2005-06: The numbers from the survey do show a jump in interest in SaaS from 34% to 43%, but the number of SaaS users actually hasn’t changed between 2005 and 2006.
How mature is the SaaS market?
The market is in its early high-growth phase, having passed the inflection point in the typical high-tech market scenario, West says. It's characterized by large numbers of fairly small vendors, with more entering constantly...
Is SaaS more than a flash in the pan?
"We believe it is the future of software, or one of the important elements in the future of software," West says. "You can't discount the traditional license model entirely, but certainly there is a strong argument economicswise that favors SaaS in the marketplace."
What, if any, involvement should service users have with the provider once the contract is signed?
"I think the user also should be very, very involved in the functional evolution of the SaaS offering," West says. "In other words, the user should participate actively in the user community, in the user conferences, because the evolution of the software is driven more firmly than in any previous generation of software by the feedback from buying community..."

Read more here: http://computerworld.com/action/article.do?command=viewArticleBasic&articleId=9042620&pageNumber=1

Some related resources:

posted by Raven at Raven's Brain under Software & Web Development
Tags: Software & Web Development, SaaS, S+S, Software as a Service, Web 2.0

Web 2.0 begat Web 3.0 but confusion still abounds

Tue, 23 Oct 2007 00:48:43 GMT

David Herron has an interesting post on the future of the internet: Web 3.0??. With so much discussion over Web 2.0:

Some folks have moved on to Web 3.0:

A List Apart: Articles: Web 3.0, Semantic Web - Wikipedia, the free encyclopedia
Web 3.0 - Features by PC Magazine
What to expect from Web 3.0 | Software as Services | ZDNet.com, Web 3.0
Web 3.0: When Web Sites Become Web Services
Web 3.0: Web 3.0 - You Ain't Seen Nothing Yet!

The bullets are just a sample of the articles, posts, videos and more out there on Web 2.0 & 3.0. Back to Herron's post, here is the excerpt I liked discussing other definitions of Web 2.0 and how the details still vary:

The "Web 2.0" moniker is so vague that how can we adequately talk about it. WealthFly's blog posting is a case example in point. S/he defines Web 2.0 as "the ability to multi-thread and the ability to update browser HTML without refreshing the browser. It lets HTML apps act more like desktop apps and less like simple document viewers." That misses several game changing aspects of web2.0 such as user generated content, simplified read/write of web content, and the whole mashup, microformat, and API phenomenon.

Web 2.0: web services, social networking, client side refresh, etc. but are we moving too quickly in trying to define Web 3.0? I know there's even more discussion on that subject. As a PM working on technology, software and web development projects it's critical to stay abreast of current and future trends, it's just hard to keep up when you're not in the nitty gritty tech trenches and able to follow the debates and discussions on what IS or IS not 2.0 or 3.0 or...?

posted by Raven at Raven's Brain under Software & Web Development
Tags: Software & Web Development, Web 2.0, Internet, Web Development, Web 3.0

Tech Book: Best Kept Secrets of Peer Code Review

Thu, 27 Sep 2007 02:20:29 GMT

I received Best Kept Secrets of Peer Code Review from author Jason Cohen of SmartBear in August and just started it. So far so good and that ain't bad! I'll post more when I've actually finished the book, but wanted to commit to reading it in the next few weeks in writing, before something else catches my attention - Look--A shiny object!!

I previously posted about the free offer for the book and it appears to still be ongoing. My girlfriend received her copy this week, which she plans sharing with her team, and that reminded me to get to gettin the book read. From the few pages I've read I do think it's going to be interesting for folks involved with software and web development and other facets of the IT sector. Stay tuned..

posted by Raven at Raven's Brain under Software & Web Development
Tags: Software & Web Development, Software Development, Code Reviews, Software Quality, Peer Code Reviews, Web Development, Programming

Tech PMs: Software Requirements Specifications: The Right Way

Thu, 27 Sep 2007 02:04:12 GMT

Developer.com has an excellent, detailed article on specs and requirements in the software development world: Software Requirements Specifications: The Right Way. Author Aleksey Shevchenko discusses the importance of software requirements specifications (SRS) and provides eight guidelines that should help you "create a well-written SRS that is both complete and unambiguous". What I appreciated most about the three page article was the detail Shevchenko provides on Use-Cases, which happens to be the foundation for his eight specification tips. You'll read about:

Use-case realization
SRS structure
The importance of using an active voice
Why you should keep technology and business design out

And a lot more. It's a good read for Technology PMs - IT, Software and web-development, and others dealing with design/development/engineering/programming, etc. You'll gain a better understanding of the importance of use-cases and how they can be used to your benefit. Even if you don't write specs you'll still glean a few bits of insight.

Link: http://www.developer.com/mgmt/article.php/11085_3681171_1

Enjoy!

posted by Raven at Raven's Brain under Software & Web Development
Tags: Software & Web Development, Software Development, Software Requirements Specifications, Managing Requirements, Design Specifications, Web Development, Use Cases

Software Development and Quality: Best Kept Secrets of Peer Code Review

Wed, 22 Aug 2007 15:39:29 GMT

Last week I posted about a free technology book: Best Kept Secrets of Peer Code Review.

I received the book in th mail yesterday and was surprised how quickly it arrived with SmartBear's free shipping. I am currently reading and reviewing two other books (Curt Finch's Time Tracking Book and Bud Bilanich's 4 Secrets of High Performing Organizations) but plan on digging into Jason Cohen's Peer Code Review Book in the next week or so.

According to FreeTechBooks "This book is aimed for anyone inside the production department, from the software developers to the managers. Regardless of reader's specific situations, this book will no doubt give readers a new idea on how to deal with those pesky little bugs." As a Tech PM I'm definitely interested in reading it and my partner who works for MSNBC.com as a group manager on the technology team sent the free offer out to the entire dev team. Remember:

Smartbearsoftware.com prints and ships the book completely free. Some chapters available on-line as PDF.

FreeTechBooks Link: http://www.freetechbooks.com/about310.html

SmartBear Book Link: http://smartbearsoftware.com/codecollab-code-review-book.php

Web 2.0 And The Top 1,000 List

Fri, 17 Aug 2007 15:48:12 GMT

Tech Without Wires has an interesting post on Web 2.0: Web 2.0 Top 1,000 List. Some interesting info on Office 2.0, Web 2.0 expectations and a link to the top 1,000 web 2.0 list:

We talked about Office 2.0, the new expectation that I will never have to install software on my computer ever again. All software will be available on the web and offered as a service.

Office 2.0 is a subset of online services that provide productivity services to people on the go needing office type software. We need to consider the wider sphere of all those applications available as, in the wider context, Web 2.0. That is, there are a whole raft of services online to which I may turn for ordinary software/services to basically do whatever I want.

Web 2.0 is the expectation that I can obtain any application I need from the web - the web is an application platform that aids me in participating in writing/reading the web (as shown on the diagram above and obtained from the excellent explanation in "A Web 2.0 by any other name").

So just how many services/software applications are there that may be considered as being web 2.0 applications? Try this list of the top 1,000 web 2.0 list. This is the best list I have seen yet, over 1,000 of the top web 2.0 applications.

posted by Raven at Raven's Brain under Software & Web Development
Tags: Software & Web Development, Web 2.0, Internet, Web Development, Online Services

Totally FREE Technology Book: Best Kept Secrets of Peer Code Review

Tue, 14 Aug 2007 16:48:56 GMT

Thanks to Brad Appleton for the heads up regarding a FREE, interesting looking book for programmers/developers/engineers/testers and other tech workers: Best Kept Secrets of Peer Code Review.This is a real, actual paper book - not an e-book, and the offer includes FREE shipping with a no-strings-attached claim.Here's a nice write up from Brad's post:

The folks over at SmartBear software have written a nice little book entitled The Best Kept Secrets of Code Reviews. It's free if you go over to their webpage and ask for it (you have to fill out a registration form, and it takes a few weeks to arrive, but they havent spammed me at all since I registered with them a few months ago).

This is a pretty good book and it is VERY pragmatic! It is applicable to Agile development too! [You don't have to do Pair-Programming to be Agile! Pairing is part of XP, which is one particular agile method -- several other agile methods do not require it.]

Read more here: http://bradapp.blogspot.com/2007/03/best-kept-secrets-of-code-reviews.html

A free book, free shipping, good review and no spam? Sign me up! Here's a little more on the book from SmartBear:

Peer code review is happening behind the scenes at your competitor's shop. Are they wasting their time or gaining a competitive advantage? What type of review actually works?

We've compiled 10 practical essays from industry experts giving specific techniques for effective peer code review:

Cisco: The largest-ever case study of peer code review
Modern experiments: results of the past 15 years
Five types of review: Pro's and Con's
Managing social aspects of peer review
Code review in the SEI/CMMI/PSP/TSP context
Why many developers don't embrace code review
Questions to ask when implementing a peer review process
Why haven't you heard more about code review?
Metrics and measurements
Code Collaborator: Software for efficient, remote peer review

Read more about SmartBear, the free book offer, table of contents and sample chapters:
http://smartbearsoftware.com/codecollab-code-review-book.php

Brad's post lists other useful resources from SmartBear:
http://bradapp.blogspot.com/2007/03/best-kept-secrets-of-code-reviews.html

IT Humor: The greatest programming tip ever written

Tue, 14 Aug 2007 16:15:05 GMT

Amusing "tip of the Day" that most techies will appreciate. Found at techrepublic

Here’s an ingenious little tip to all programmers that will guarantee an improvement in the quality of the code you produce — one that somebody included as an advisory pop-up for MS Visual C++. Found via reddit.

posted by Raven at Raven's Brain under Software & Web Development
Tags: Software & Web Development, IT Humor, Technology Humor, Programming Humor

Software Development Post: All I Ever Need to Know about Testing I Learned in Kindergarten

Mon, 11 Jun 2007 16:57:20 GMT

StickyMinds has a great article regarding testing: All I Ever Need to Know about Testing I Learned in Kindergarten. Author Lee Copeland tweaks the lessons in Robert Fulghum's book "All I Really Need to Know I Learned in Kindergarten." into some interesting guidelines for testers. Here are a few of my favorites:

Don't hit people.
If you find a defect in someone's work, first tell him informally, personally, and discreetly.

Once a co-worker gave me a document he had written and asked for my review. I didn't get to it until the last minute. Rather than talk with him in private, I blasted his work publicly in a meeting. Later, he came to me and simply asked, "Why?" I still remember the look in his eyes, and I have never done that again.
As a tester, remember that we are paid to "hit" software, not the people who wrote it. It's the software that's buggy, full of holes, not worth the ink used to print it, and, as James Whittaker likes to quote Neil Young, "A piece of crap."
Rather, remember Norm Kerth's gentle words: "Regardless of what we discover, we understand and believe that everyone did the best job they could, given what they knew at the time, with their skills, abilities, and the resources available."
Don't take things that aren't yours.
One thing people take that isn't theirs is credit. Once my boss asked me to research something. Later, I wrote a memo, which began, "To: Boss, From: Lee." The next time I saw the memo it read "To: Big Boss, From: Boss." He took my work and didn't give me any credit. I learned something from that experience. From then on, I always took memos that my staff had prepared and put a sticky note on them that read, "My staff member wrote this . . . I think it's good work . . . I hope you concur."
Another thing people take that isn't theirs is guilt. You will not find every defect. Try hard, use your skills, do a good job; but remember, some will sneak by you and that's OK. As Boris Beizer says, "We need devious testers." But sometimes, as devious as we are, our developers and users exceed our capacity.
Say you're sorry when you hurt someone.
No matter how careful we are, at some place and time, we will hurt someone. Most of us will never intentionally hurt anyone physically, but we will hurt him emotionally. We'll say something or do something--perhaps intentional, perhaps in ignorance, or perhaps in jest--that will reach into his chest and rip out his heart.
As testers, we're in the error-discovery business. Our job is to find other people's mistakes. When we find them, we report them publicly. We know to always focus our reports on the errors, not the person who made the errors. But still, sometimes egos are bruised; sometimes feelings are hurt.
Say "I'm sorry." It is one of the most powerful, healing phrases in the human language.
Read more here: http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=10145&tth=DYN&tt=siteemail&iDyn=2

I believe the entire article contains 15 tips geared towards the testing community, but anyone involved in software development could benefit from reading it. Often we forget how difficult a job testers have, trying to catch all the bugs, dealing with egos, changing priorities and deadlines, frequent code updates, builds, environment issues, etc., and I believe that even the simple tips from the article provide insight into how complicated and stressful a testers job can be. You might also browse the comments at the end for some additional thoughts on the subject. Enjoy!

posted by Raven at Raven's Brain under Software & Web Development
Tags: Software & Web Development, Software Develoment, Testing Tips, Technology Management, Software Testing, Web Development, Programming

Tech post: Programming Promises & The Professional Programmer's Hippocratic Oath

Mon, 07 May 2007 16:22:15 GMT

As a technology PM I'm always looking for interesting software and web development content. I bookmarked a post from Ted Neward a while back that's worth sharing: Programming Promises (or, the Professional Programmer's Hippocratic Oath. I love working in product development on the technology side and enjoy working with engineers that are interested in developing high quality code and working as a team, rather than focusing on individual performance - So of course I loved this post! It covers Michael Letterle's list of Programming Promises and also discusses Neward's tech-tweaked version of the Hippocratic Oath, aptly renamed as The Profressional Programmer's Hippocratic Oath. Here are a few of my favorite Programming Promises:

I promise to get the job done.
I promise to use whatever tools I need to, regardless of politics.
I promise to engage with as many other programmers as possible, both in person and online, in order to learn from them; regardless of politics.
I promise to ask questions when I don't know the answer, and answer questions when I do.
I promise to listen to any idea, however crazy it may sound.

Great list, with more detail available on all 12 promises here: http://michaeldotnet.blogspot.com/2007/01/programming-promises.html. As for The Profressional Programmer's Hippocratic Oath, here are a few of my favorite points:

I will apply, for the benefit of the customer, all measures [that] are required, avoiding those twin traps of gold-plating and computing nihilism.
I will remember that there is humanity to programming as well as science, and that warmth, sympathy, and understanding will far outweigh the programmer's editor or the vendor's tool.
I will not be ashamed to say "I know not," nor will I fail to call in my colleagues when the skills of another are needed for a system's development, nor will I hold in lower estimation those colleagues who ask of my opinions or skills.

More great info, with additional detail available here: http://blogs.tedneward.com/PermaLink,guid,17a2b01b-f398-4033-b914-d10418fb0a53.aspx. Thanks to Michael and Ted for puting these texts together and sharing with with technology community. All roles on a software, web or technology project are vital - programmer, analyst, pm, tester, etc. - and the more responsibility you take in your own role affects the success of the entire project. We all need to be more accountable for our work and both of these lists provide great info on how to be more effective in your job as a programmer, but are also applicable to a majority of the technology team.

posted by Raven at Raven's Brain under Software & Web Development
Tags: Software & Web Development, Software Develoment, Programming Promises, Technology Management, The Profressional Programmer's Hippocratic Oath, Web Development, Programming

Women & Technology: NYT shows decline in women computer science majors

Sat, 21 Apr 2007 00:30:54 GMT

PMThink! references a recent article from New York Times regarding the growing decline in women graduating with computer science degrees. It's an interesting read, here's the intro:

For decades, undergraduate women have been moving in ever greater numbers into science and engineering departments at American universities. Yet even as they approach or exceed enrollment parity in mathematics, biology and other fields, there is one area in which their presence relative to men is static or even shrinking: computer science.

That's not to say that women aren't progressing in other fields, like math and biology noted in the above clip, but the drop in interest to computer science means there will be less women IT professionals to fill future positions. Yikes! Us female PMs need other women IT professionals in the industry! The article goes into more detail on what american colleges are doing to combat the trend and here are a few more interesting points:

They are concerned about this trend, they say, not just because they want to see young women share the field’s challenges and rewards, but also because they regard the relative absence of women as a troubling indicator for American computer science generally — and for the economic competitiveness that depends on it.
“Women are the canaries in the coal mine,” Lenore Blum, a computer scientist at Carnegie Mellon University, told an audience at Harvard University in March, in a talk on this “crisis” in computer science. Factors driving women away will eventually drive men away as well, she and others say.

Are we women canaries? Or is the IT field just not as interesting and seductively lucrative as it was in before the bubble popped and the money trees whithered? Maybe the horror stories of building software on death march projects, working all nighters - heck all weekenders - just to get a critical patch out - has deterred them some. Maybe they're just bored. Hopefully the industry can show future IT girls how important they are to new technology and innovation, and schools and colleges will learn to do more to peak their interest. We definitely need women in the workplace and that includes building software, working with code, developing new technologies, making adavancements and contributions to the IT field, architechting, technical documentation, tech management and so much more. My two cents with a side of ramble..

posted by Raven at Raven's Brain under Software & Web Development

Tags: Software & Web Development, Software Develoment, Tech Management, IT Management, Women & Technology

Good Insights On Managing Knowledge Workers

Tue, 17 Apr 2007 02:47:17 GMT

There's a good post on the challenges of managing knowledge workers at Thinking Faster: What's a manager to do? Here's the intro:

Let's start with a few suppositions. First, many of us work in either the information economy or the service economy. That means we deal with people or information, not machines. Second, most of us are "knowledge workers" - that is, we add value through our knowledge rather than through our muscles. So, a logical conclusion is that a knowledge worker should have the information to operate without a lot of oversight, since he or she knows the job, the effort required and has the information or knowledge to accomplish it.

So, what's a manager to do in this situation? If we were in a Tayloristic era, we'd say that a manager issued orders to people that the manager ensured were carried out, according to some guidelines about the amount of time necessary to complete the work. Taylor is the father of scientific management, but his methods seem a little heavy handed in a knowledge economy. If people know their responsibilities, understand their roles and have the knowledge necessary to add value to the product or process, what value does a manager add?

I think in the modern economy, a manager can add at least three valuable attributes: translation, clarity and resolution. Let's drill down into each just briefly...

Read more here: http://workingsmarter.typepad.com/my_weblog/2007/04/whats_a_manager.html

Good insights on managing in the tech sector!

posted by Raven at Raven's Brain under Software & Web Development

Tags: Software & Web Development, Software Develoment, Tech Management, Knowledge Workers, IT Management, Management

Peer Code Reviews: Are you a software pooper scooper?

Sun, 18 Mar 2007 01:54:44 GMT

Jared has two great posts on peer code reviews. The first is an insightful look at code reviews from a leadership perspective: Are you a software pooper scooper?. Good stuff:

During a discussion of software practices that Build Teams, Not Products in Boston an audience member said he didn't want to do things like Peer Code Reviews that were designed to teach other team members. He preferred to simply clean up their code after the junior members checked it in.

We were discussing peer code reviews, meaningful variable names, and the infamous Mister Hashy variable name (Mr Hashy was a hash table). The guy in the audience had someone just like that on his team, and he had made a concious decision to not interface with the person, but just clean up behind them.

While we were talking about it, I had an "Ah ha!" moment... I asked him if he realized he'd made a concious decision to be a career pooper scooper. By choosing to clean up behind a team member instead of trying to teach them, you've made a concious decision to follow them around and clean up their mess. They are dependant on you and you limit yourself to a clean up role.

I do things like test automation and peer code reviews so we all have more time for the fun stuff, like design and solving tough problems, not so I can clean up someone else's code.

Take the time to teach the junior team members that work with you. Tools like peer code reviews and daily meetings help them learn good habits. And then there's less cleanup for everyone.

Read more here: http://www.jaredrichardson.net/blog/2007/03/15#scoop_the_poop

Jared's Blog also has a great post titled The Peer Code Review that provides a great overview of what a code review is, how to coduct a useful session, things to avoid and some benefits of them:

Crosstraining (raising your Truck Number)
You catch your own bugs
Others catch your bugs
Mentoring "as you go"
A second set of eyes looks at every line of code
Lightweight
Fast
Read more here: http://www.jaredrichardson.net/blog/2007/03/14#peer_reviews

It's a good overview on code reviews and makes a good case for their benefit. As a tech PM, I'm all about delivering quality code, so anything we can do to increase QA in the project is a plus. Besides, code reviews helps to ensure that the test team is getting good code integrated into the system for more testing. Thanks to Jared for posting his experience and tips!

posted by Raven at Raven's Brain under Software & Web Development
Tags: Software & Web Development, Software Develoment, Code Reviews, Software Quality, Peer Code Reviews, Web Development, Programming

Interesting Software Development Post: Testivus - Testing For The Rest Of Us

Sat, 24 Feb 2007 19:46:53 GMT

I came across a great article by Alberto Savoia (CTO of Agitar Software): Testivus - Testing For The Rest Of Us. Here's the summary:

Developers need to take more responsibility for testing their code. But the majority of developers are not willing, nor ready, nor able to jump on the bandwagon of the more extreme and demanding developer testing movements such as Test Driven Development. Testivus is a proposed developer testing movement "for the rest of us".

If you're a fan of Seinfeld you'll recognize the nod to the mighty festivus in this article, but it goes deeper than that. I'm currently a PM but I used to be a web developer/hack, back when it was easy, and I've developed small components and mock-ups in VB and hacked my way through ASP, XML, scripting, etc., so I'm interested in improving quality through solid development and heaps of testing from a few angles. I understand what developers/prgrammers/engineers face with changing requirements, priorities and schedules, system silos (where a single individual owns a peice of the system), unclear specifications, etc. I also understand how the test/qa teams at most software development companies are the first to have time cut from a project, are under the most pressure during the most critical part of the project, and how help from developers with things like unit testing before integrating code into the build, testing during coding and keeping on top of defects, and thinking about integration with other parts of the system environmentsdev/test/uat/integration/staging/production/et. al), DBs, etc. all add to the quality of the deliverable. In the article Savoia proposes "The Testivus Manifestivus" and provides a first draft to address some of these common issues:

Less testing dogma, more testing karma
Any tests are better than no tests
Testing beats debugging
Test first, during, or after – whatever works best for you
If a method, technique, or tool, gives you more or better tests use it

Sound too simple? It's actually common sense when you read the detail on each of the above items. Here's detail on my favorite part of the Testivus Manifestivus:

Any tests are better than no tests
Self-explanatory and inspired by Martin Fowler, who once wrote “Imperfect tests, run frequently, are much better than perfect tests that are never written at all”.

And there is more detail on each of the other items in the Manifestivus, so check out the complete article for more detail and proper context: http://www.artima.com/weblogs/viewpost.jsp?thread=194506

posted by Raven at Raven's Brain under Software & Web Development

Tags: Software & Web Development, Software Develoment, Software Testing, Software Quality, Testing, Software Quality

Web 2.0 Video: "Web 2.0 ... The Machine is Us/ing Us"

Sun, 11 Feb 2007 02:04:32 GMT

Thanks to Jack Vinson for the great reference on Web 2.0:

We are the web
James Dellow at ChiefTech points to a great video that explains Web2.0: Web 2.0: The Movie:

This great little short video, titled "Web 2.0 ... The Machine is Us/ing Us", explains the difference between traditional content (including "Web 1.0") and Web 2.0. Thank you to Michael Wesch, an anthropologist at Kansas State University, for putting it together.

It doesn't get into all the nitty gritty - it does a flyover of what this all means, set to a nice soundtrack.

LINK to post: http://blog.jackvinson.com/archives/2007/02/05/we_are_the_web.html
LINK to Video: http://www.youtube.com/watch?v=6gmP4nk0EOE
LINK to Movie: http://chieftech.blogspot.com/2007/02/web-20-movie.html

posted by Raven at Raven's Brain under Software & Web Development

Tags: Software & Web Development, Web 2.0, Internet, Web 2.0 The Movie, Web 2.0 Video

Interesting list of the Stages of Software Development

Thu, 08 Feb 2007 17:47:10 GMT

Here is a great list of the Stages of Software Development that were written by Christopher Diggins:

I was taught (back in '94 by my software engineering professor) that the stages of software development were something like (my memory is hazy, so I am not probably giving her full justice):

gather requirements
design
implementation
debugging
testing
I believe that it is important to consider a more fine-grained and less linear view of the stages of software development. I consider the following to be important interleaved phases for the development of most non-trivial commercial software:

scheduling - Self explanatory.
research - Learning more about the problems the software attempts to solve, and what the competing software does.
technology selection - Choosing what tools, languages, and technologies to use to build and devleop the software.
reuse - Identifying code libraries and tools internally and externally that can be leveraged
prototyping - An important step which is often overlooked (often-times the first version is really a prototype).
code documentation
product documentation
refactoring - Change in the code to changes in implementation design.
extending - This refers to when more features are added during development, after prototyping, or after a release
revising - Related to refactoring, this refers to when the product requirement are significantly changed in some-way
internationalization - It is is usually the case the software will be released in different locales with different langauges and cultural conventions.
optimizing - It is rare that software doesn't have some areas where better performance could significantly improve the product.
static analysis - Static analysis tools are an important part of detecting defects
reviewing code - Code reviews are an important supplement to testing
releasing - Getting the internal versions to various teams, and external versions to customers in a smooth and timely manner
recycling code - The code in a successful project will almost invariable be reused in some other project.
porting - Porting software to new operating systems and platforms is almost always inevitable in a successful product
support - Customer support is easily overlooked, but when taken into consideration will affect design decisions, and profitability.
By being aware of, and giving proper consideration to, these stages of software development I believe software projects increase their chances of success.

Read more here: http://www.artima.com/weblogs/viewpost.jsp?thread=194223

For bonus reading, check out the comments for this post as they include more thoughts, opinions and insight on different stages needed to develop quality software.

From a PM perspective I found this list to be quite valuable. Our teams are often so rushed to push code out that we don't have the time to do all the steps mentioned, but imagine the quality software we'd turn out if we only had the time! The development world is growing more agile but that doesn't mean that all of these steps aren't needed or executed, and working from a list like the one above could be of great benefit to teams struggling with different methodologies. If you are including the most important steps in your process, no matter what it's called, you're definitely on the right track - keep it up! Thanks to Christopher Diggins for the great info!

posted by Raven at Raven's Brain under Software & Web Development

Tags: Software & Web Development, Software Develoment, Software Design, Software Quality, Stages of Software Development, Software Projects

The Power of the Internet: Web 2.0: The Internet, Refreshed

Sun, 04 Feb 2007 18:28:38 GMT

Baseline has an interesting article on the power of the web: Web 2.0: The Internet, Refreshed. It discusses Web 2.0, what it means and how to create a successful framework to increase productivity, cost savings and ROI:

Web 2.0: The Internet, Refreshed
By Brian P. Watson
Say goodbye to the Web you know and hello to the Web you've always wanted. A variety of frameworks for building rich Internet applications are helping companies save time and money.

Still doubting the power of the Web? Then pick up a copy of Time magazine's "Person of the Year" issue.

The newsweekly bestowed the past year's honor on participants of the "new digital democracy" and highlighted the impact of Web 2.0, the concept of the Internet as a platform for interaction and collaboration, with linchpins like YouTube, Wikipedia and MySpace.

To some, the heralded phrase alludes to user-driven content on the Internet, featuring innovations like wikis (Web sites that allow anyone to edit content) and blogs (journal-like Web entries)—and a departure from the static pages that embody the current state of the Web. Others argue that Web 2.0 simply implies a vision for a better Internet, with the precise definition still evolving.

Most of the hoopla around Web 2.0 comes from consumer circles, but the impact on business is unmistakable. Consider this: Jobs calling for Web 2.0 skills spiked 4,200% from June 2005 to June 2006, according to O'Reilly Media.

So, how do you "do" Web 2.0? First, you need a development framework for building rich Internet applications, Web-based programs that run like they're on a desktop, refreshing page views without resetting the page through the server.

These frameworks come in different flavors, including Flash, a multimedia development platform; and JavaScript, a Web-development language. And developers and managers say they're helping organizations build Web applications faster and cheaper than before.

Read more here: http://www.baselinemag.com/article2/0,1397,2087800,00.asp?kc=BARSS03129TX1K0000628

Related Raven's Brain posts:

posted by Raven at Raven's Brain under Software & Web Development

Tags: Software & Web Development, Web 2.0, Internet, Web 2.0 Framework, Technology and Business

Good Article: Wikis Are Alive and Kicking in the Enterprise

Sun, 26 Nov 2006 18:00:51 GMT

eWeek has a great, three page article on Wiki's: Wikis Are Alive and Kicking in the Enterprise. I developed and managed a Project Management intranet for a software development company I was working for back in 2003-04 and one of the engineers plugged in a wiki, to great success, so I've always been a fan. Wiki's are great for collaboration, information sharing - we used ours to provide more info on our products, the development process and anything else contributors (Engineers, Testers, PM- me, etc) thought other folks would be interested in. In any case, it looks like it's becoming a wiki, wiki world:

Look in the wiki!
If you haven't heard that cry already, chances are you will soon, as the use of wikis in enterprise environments spreads like wildfire.
Proliferating virally, wiki usage has grown exponentially in recent months, along with other consumer-centric technologies—including blogs, podcasts and RSS—that have made their way into the workplace thanks in part to the influx of the tech-savvy entry-level employees of so-called Generation Y.
A wiki, which means "quick" in Hawaiian, is a Web site that enables users to easily edit and update shared content. Computer programmer Ward Cunningham originated the wiki concept and gave it its name more than a decade ago.
After slow growth initially, wiki use has exploded in the past couple of years. Wiki technology, which has been popularized by the widely used Web encyclopedia Wikipedia, took a big leap in mind share when Google purchased wiki software maker JotSpot for an undisclosed amount on Oct. 31.
Wiki usage in enterprises could further proliferate when Microsoft ships a wiki feature in Office 2007 and SharePoint 2007 next year and IBM includes a wiki technology in a social computing product code-named Ventura, due in the first half of 2007.
Read more of the article here: http://www.eweek.com/article2/0,1895,2061135,00.asp

The piece also includes links to other interesting tidbits:

Enjoy!

posted by Raven at Raven's Brain under Software & Web Development

Tags: Software & Web Development, Wikis, Wiki