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

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:

1. 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?”
2. 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.
3. It’s all about the code

The goal of this process is to make the code as good as possible.
4. 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

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

1. 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...

2. 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..."

3. 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..."

4. 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..."

5. 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. 

6. 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.

7. 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...
   

8. 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."

9. 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:

• Software + Services (S+S, SaaS)
• SaaS Blogs - » What is SaaS? The Answer is Rooted in the End User
• What is SaaS? | Software as a Service (SaaS) Boom
• ABC: An Introduction to Software as a Service - CIO.com - Business ...
• SaaS: Growth, but not Problem Free
• IndustryWeek : What's The Buzz About SaaS?
• The Truth About Software as a Service (SaaS) - CIO.com - Business ...

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

• O'Reilly -- What Is Web 2.0, Web 2.0 - Wikipedia, the free encyclopedia
• Web 2.0, YouTube - What is Web 2.0?
• » What is Web 2.0 | Web 2.0 Explorer | ZDNet.com
• delicious blog » what is web 2.0?
• What is Web 2.0? by Andy Budd
• ClickZ: Web 2.0: What Is It Really?

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.

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

• 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

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. 

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

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.

Read more here: http://www.techwithoutwires.com/50226711/web_20_top_1000_list.php

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

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

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

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

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

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

• 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

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.

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.

Read more here: http://www.nytimes.com/2007/04/17/science/17comp.html?_r=3&ref=technology&oref=slogin&oref=slogin&oref=slogin

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..

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

 

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

 

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!

NOTE: Raven's Brain has MOVED!
To get the latest updates, visit the new site or subscribe to the new feed:

Raven's Brain new web site
http://www.ravensbrain.com/

Raven's Brain V2.0 FEED
http://feeds.feedburner.com/ravensbrain2

Subscribe to Raven's Brain V2.0 via email
http://www.feedburner.com/fb/a/emailverifySubmit?feedId=2263124&loc=en_US

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

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".

• 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

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

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.

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