"volatility per se, be it related to weather, timing of the morning newspaper, is simply a benign statistical probability factor that tells us nothing about risk until it is coupled with a consequence," - Robert H. Jeffrey, "A New Paradigm for Risk," Journal of Portfolio Management, Volume 11, Number 1 (Fall), pp. 33-40.

When we speak about capturing ranges of duration or cost, or speak about compliance with technical performance measures and do not speak about the consequences, then we're pretty much wasting our time with Risk Management.

Here's The Core Problem(s)

• When capturing the estimates using what every method you choose - I'd recommend NOT asking the estimator the Hi, Most Likely, and Lo for lots of reasons discussed else where - more information is needed than just the numbers.
• After eliciting the ranges of values, the probability distributions can then be used to drive a Monte Carlo simulator. This approach produces a Credible forecast of the probability of completing On or Before a Date or having the project cost A Value or Less.
• When static 3 point estimates are used, there can be up to a 27% unfavorable (under estimating) of the completion date. So don't use 3 points and don't use PERT.
• There is a whole cottage industry on why the PERT formulas are bogus and the problems with them. Here's a start "Why PERT Has Problems."

For places to look for PERT background start with:

[1] "Quantitative Risk Analysis for Project Management,: A Critical Review," Lionel Galway, Rand Working Paper, WR-112-RC, February 2004.
[2] "The Polaris System Development: Bureaucratic and Programmatic Success in Government," Harvey M. Sapolsky, Harvard University Press, 1972.
[3] "PERT Completion Times Revisited," Ted Williams, University of Michigan-Flint, School of Management, Working Paper 2005-02, September 2005.
[4] "Hidden Assumptions in Project Management Tools," Dr. Eva Reginier, DRMI Newsletter, January 10, 2006, Naval Postgraduate School, Monterey CA.
[5] "Activity Completion Times in PERT and Scheduling Network Simulation," Dr. Eva Reginier, DRMI Newsletter, April 8, 2005, Naval Postgraduate School, Monterrey CA.

RT @batimes Requirements Gathering in a Flat World | Articles http://ow.ly/1qMcRj Software requirements

I just got the following comment on my post about MVVM being overrated:

Sorry, but you’re just talking.

Where’s the code ?

I mean you seem to have all the time in the world to just say things on your blog , but no time to put together a simple sample up.

I seriously doubt you understand what you talk about.

As you can probably tell from my reaction, i got pretty pissed off. Normally, i don’t let comments like that get to me. But in this case, i have been spending quite a bit of my personal time working on a sample and preparing the blog posts. I’m actually planning to spend quite a bit of my weekend on this (as i did last weekend), not to mention that i’m also gonna spend a couple of hours working on it during my day off tomorrow.

I’m not getting paid for any of this. In fact, i’m only getting shit for doing this. The handful of people who are looking at this because they’re tired of the MSDN-way of developing things will appreciate it, but the vast majority of people who’re gonna read it are going to complain because “it’s too complicated!” or “i have to think too much!”. Well, you know what? You’re not the kind of developer i’m targeting anyway. If you stumble upon a post of mine about Silverlight or anything else that’s hot in MSDN-land, you probably got here through a link-blog or a link on twitter. And in those cases, odds are pretty high that the way i think about software development and the way you think about it don’t exactly match. And that’s ok. I’ll do what i wanna do in the way i feel it’s right to do so, and i suggest you do the same. But pressuring me into backing up the stuff i say with code is not really gonna get you anything sooner. I’m still gonna do whatever it is that i’m gonna do in a time frame that suits me, not you.

And to top it all off, i just got the following reply from the same guy:

“I’ll just say this.

When you make a public statement , you better have some code ready to prove it.”

Priceless, ain’t it?

Several years back, I did an exercise in mapping out families of application architectures and application types.  It was an extensive archeological expedition.

Key Goals / Outcomes
There were several goals of the exercise:

• Identify canonical application architectures and app types
• Figure out a useful way of sharing architectures
• Figure out whether it's better to focus on the business architectures or the technical architectures
• Find a simple way to overlay patterns work on top of technical architectures
• Find a simple way to share architectural styles
• Find a way to simplify and share visuals of end-to-end architectures

The exercise fed into a number of later works years later, including:

• Re-shaping the patterns & practices catalog to be organized using app types -- and this literally drove our product-line more formally toward app types (a pre-cursor to the patterns & practices "factories" effort in 2005)
• Identifying a canonical set of application types for the Microsoft platform as part of the Application Architecture Guide.
• Shaping the path of the home/hub pages on MSDN toward "deployment targets" and application types

Key Activities
Some of the key activities of this early exercise included:

• Creating an exhaustive catalog of application types grouped and sliced in various ways
• Interviewing many of our best application architects in the trenches
• Sanity checking with many of our top architects at head quarters, including Rico Mariani, Pat Helland, and Jim Gray
• Reverse engineering many available sample applications inside and outside of Microsoft
• Checking with industry experts on their lessons learned about the types and the shapes of all the applications they've seen and built over the years
• Creating an extensive inventory of application patterns from various sets of our  key customers that had a wide range of applications and platforms
• Evaluating competitive efforts to index and catalog application shapes and types, and making sense of various patterns efforts

Keep in mind, that going into this, I already had the benefit of doing more than 650 customer architecture and design reviews -- yet still, this was an overwhelming exercise.  It forced me to find new ways to deal with large bodies of data and information, and somehow turn them into  shared maps, browsable, reusable knowledge nuggets, and backdrops for deeper conversations and elaboration.

Lessons Learned from Architectural Exploration
Some of the surprises for me or things that I learned that I didn't expect include:

• Focusing on business architectures and verticals was less effective and less reusable than focusing on technical architectures as a baseline (from there, we could overlay business architectures)
• Knowing the deployment patterns was the fastest way to get a good sense of the application patterns (it's where the logical met the physical against the infrastructure)
• Looking through quality attributes as a lens made it easy to find and explore patterns for security, performance, reliability, manageability, etc.
• So many applications boiled down to simple CRUD (Create Read Update and Delete)
• The biggest variation among applications was the business logic and workflow
• IBMs simple model of user, process, and data was useful as one lens
• Views and viewpoints were a powerful way to change perspective and drill into another aspect of applications
• At a high-level, you could capture a customer's core system by capturing the data, workflows, and workloads (the workloads significantly shaped the design of the app)

In retrospect, the simplicity and common denominators of CRUD make a lot of sense.  It's all about interacting with information at a fundamental level.  People are just trying to get things done and there's only so many things you can do with information -- find it, browse, save it, share it, transform it, etc. as part of your workflow.

Early Map of App Types
I included one of the many early maps of the application types that helped us figure out what to throw out and what to keep as we moved forward.   One of the key distinctions that Ward Cunningham helped me figure out was to distinguish between the shape of the application architecture and design, and the actual “purpose” of the application.  Some purposes were more business-oriented, while some were more technically oriented, and this helped me find and distinguish different families of apps.

It's circa 2004, but the irony is how timeless the backdrop really has been.  It’s rough and raw, but like I said, it’s just one sampling of the many braindumps behind the scenes of mapping out app types.

 

Category Items Base Archetypes

• Rich Client
• Web Client
• Web Service
• Mobile / Phone
• Video Game

• Framework
• Component/Library
• Subsystem
• Service

Pool of Stuff

• OLAP
• Data Mining
• Data Warehouses
• Data Management
• Business Process Integration
• Business Intelligence
• BAM

• Server-side
• Desktop
• Peer-to-peer
• Mobile
• Web-centric
• Data-centric
• Middle-tier

• Transactions
• Read-Only data
• Workflow
• Batch

• Portal
• Community
• Commerce
• Task-Tracking

Business Applications

• Accounting and Finance
• Customer Service
• Distribution and Warehousing
• Education and Training
• Engineering, Design and Drafting
• Facilities Management
• General Office Automation
• Groupware and Collaboration
• Human Resources
• Knowledge Management
• Legacy Systems Analysis and Upgrade
• Logistics and Procurement
• Manufacturing and Process Management
• Other Business Application Tools
• Project Management
• Reporting, Analysis and Decision Support
• Sales and Marketing

Accounting and Finance

• Account Activity Analysis
• Accounts Payable
• Accounts Receivable
• Billing and Invoicing
• Budgeting, Financial Planning and Analysis
• Consolidation Statements and Performance Reporting (CS-PR, Aggregation)
• Currency and Foreign Exchange Management
• Electronic Funds Transfer (EFT)
• Fixed Asset Management
• General Ledger
• Integrated Accounting Solutions
• Integrated Financial Management Solutions
• Inventory Accounting
• Investment and Portfolio Management
• Job Costing
• Payment, Clearing and Settlement Systems
• Payroll and Personnel Accounting
• Purchasing
• Quotation, Order Entry and Order Processing
• Risk Management
• Small Business Accounting
• Tax Preparation and Reporting
• Time and Billing

Customer Service

• Automatic Page-Voice Notification
• Call Center Management
• Customer Service
• Help Desk and Call Management
• Interactive Voice Response Systems
• On-line Customer Support
• Scheduling

Distribution and Warehousing

• Distribution and Warehousing (Integrated)
• Freight Dispatch
• Freight Handling
• Other Distribution and Warehousing Industry Sectors
• Route Scheduling
• Truck-Fleet Management
• Wholesale Distribution and Warehousing

Education and Training

• Computer-Based Training
• Courseware Development
• Web-Based Training

Engineering Design and Drafting

• Cartography-Mapping-Geographic Information Systems (GIS)
• Computer-Aided Design (CAD)
• Computer-Aided Manufacturing (CAM)
• Electronics Design Automation (EDA)
• Materials Analysis
• Mechanical Computer-Aided Design (MCAD)
• Mechanical Computer-Aided Engineering (MCAE)
• Mechanical Computer-Aided Manufacturing (MCAM)
• Modeling
• Sampling and Testing
• Structural Analysis

Facilities and Management

• Building Security
• Communications Management
• Computer Maintenance Management (CMMS)
• Energy Analysis and Management
• Enterprise Asset Management (EAM)
• Equipment Maintenance and Field Service
• Facilities Maintenance
• Facilities Management (Integrated)
• Heating, Ventilation and Air Conditioning (HVAC)
• Lighting Analysis and Control
• Other Facilities Management Industry Sectors

General Office Automation

• Appointment Management
• Calculators
• Calendaring & Scheduling
• Data Entry
• Desktop Management
• Desktop Publishing
• Electronic Mail
• Fax Management
• Flowcharting
• Graphics (Raster)
• Graphics (Vector)
• Mailing List Management
• Multimedia and Animation
• Office Suites (Integrated)
• Presentation Applications
• Spreadsheets
• Time Management
• Time and Expense Reporting
• Voice Recognition Software
• Web Browsers
• Word Processors

Groupware and Collaboration

• Chat and Discussion Systems
• Collaborative Writing Systems
• E-mail Clients
• Group Calendars
• Integrated Groupware Solutions
• Newsgroup Management
• Resource Scheduling
• Video Conferencing and IP-TV
• Workflow Automation

Human Resources

• Benefits Administration
• Employee Self-Service Software
• Human Resource Management
• Integrated Human Resources Utilities
• Personnel Administration
• Professional Services Administration
• Recruiting
• Resume Tracking
• Time & Attendance
• Travel Management

Knowledge Management

• Computer Output to Laser Disc (COLD)
• Document Imaging Systems
• Document Management Systems
• Idea Management
• Knowledge Base Management
• Workflow

Legacy Systems Analysis and Upgrade - Logistics and Procurement

• Import and Export Management
• Partnership Relationship Management
• Requisitioning and Procurement
• Supply Chain Management
• Transportation Management
• Warehouse Management Systems

Manufacturing and Process Management - Capacity Requirements Planning (CRP)

• Data Reduction
• Distribution Management
• Enterprise Resource Planning (ERP)
• Equipment Maintenance and Management
• Factory Automation and CIM
• Factory Data Collection
• Inventory Management
• Machine Tools
• Machine Vision
• Maintenance, Repair and Operating Supplies (MRO)
• Manufacturing Automation Protocol
• Manufacturing Execution Systems (MES)
• Manufacturing Simulation
• Manufacturing Solutions (Integrated)
• Material Requirements Planning (MRP)
• Materials Manufacturing
• Metrology
• Numerical Control (NC)
• Operations Planning
• Plant Maintenance and Service
• Process Control (HMI-SCADA)
• Product Information Management (PIM)
• Product Service
• Production Planning
• Production Scheduling
• Quality Control
• Reliability Modeling and Analysis
• Robotics
• Shop Floor Control
• Test Development
• Test Information Integration
• Test Simulation
• Work Load Control

Project Management

• Project Accounting
• Project Estimating
• Project Management (General)
• Project Scheduling
• Purchasing
• Resource Planning

Reporting, Analysis, and Decision Support

• Business Planning
• Business Process Reengineering
• Competitive Analysis
• Data Mining and OLAP
• Decision Support Systems
• End-User Query and Reporting
• Executive Information Systems
• Expert Systems
• Mapping and Visualization
• Multi-Dimensional Analysis
• Needs Analysis Systems
• Neural Networks
• Statistics and Technical Data Analysis
• Trend Analysis

Sales and Marketing

• Contact Management
• Customer Relationship Management
• Demographics
• Enterprise Marketing Automation
• Lead Distribution Management
• Market Research
• Marketing Management
• Media Planning and Buying
• Mobile Field Sales
• Partnership Management
• Product Configurators
• Sales Analysis & Reporting
• Sales Force Automation (SFA)
• Sales Management
• Telemarketing

Industries

• Aerospace & Defense
• Automotive
• Chemicals
• Communications
• Consumer Products
• Education & Research
• Energy
• Engineering & Construction
• Financial Services
• Healthcare
• High Technology
• Industrial Manufacturing
• Life Sciences
• Professional Services
• Public Sector
• Retail
• Travel & Transportation
• Utilities

Business

• Contact Management
• Customer Management
• Accounting

Data

• Datawarehouse
• Data mining
• OLAP

Desktop

• Photo Editing
• Graphic Design
• Web Publishing

Desktop Business Software

• Email Client
• Spreadsheet
• Presentations
• Word Processing

Home and Hobbies

• Cooking and Health
• Fashion
• Gardening and Landscape
• Genealogy
• Hobbies
• Home Design
• Home Publishing
• Instrument Instruction
• Legal
• Mapping
• Movies and Television
• Music Appreciation
• Personal Improvement
• Script and Screenwriting

Personal Finance

• Investment Tools
• Money Management
• Tax Preparation

Utilities

• Virus Protection
• PC Maintenance

A

• Batch
• BPM (business process management)
• BIM (business intelligence management)
• EAI (enterprise architecture integration)
• Document Management

B

• Operating System
• Framework
• Component/Library
• Service
• Subsystem

C

• Portal
• Community
• Commerce
• Task-Tracking

D

• Transactions
• Read-Only data
• Workflow
• Batch

E

• Server-side
• Desktop
• Peer-to-peer
• Mobile
• Web-centric
• Data-centric
• Middle-tier

F

• Content Management

G

• Web Server
• Application Server
• Database Server

H

• Collaboration Suite

I

• OLAP
• Data Mining
• Data Warehouses
• Data Management
• Business Process Integration
• Business Intelligence
• BAM

RT @tweetmeme Technical Writing — System vs. Software Requirements Specifications (SRS) | Technic.. http://bit.ly/d84J2X

Earlier this week the Visual Studio team released updated VS 2010 Keyboard Shortcut Posters.  These posters are print-ready documents (that now support standard paper sizes), and provide nice “cheat sheet” tables that can help you quickly lookup (and eventually memorize) common keystroke commands within Visual Studio.

This week’s updated posters incorporate a number of improvements:

• Letter-sized (8.5”x11”) print ready versions are now available
• A4-sized (210x297mm) print ready versions are now available
• The goofy people pictures on them are gone (thank goodness)

The posters are in PDF format – enabling you to easily download and print them using whichever paper size is in your printer.

Download the Posters

You can download the VS 2010 Keybinding posters in PDF format here.

Posters are available for each language.  Simply look for the download that corresponds to your language preference (note: CSharp = C#, VB = VB, FSharp = F#, CPP = C++). 

Hope this helps,

Scott

P.S. In addition to blogging, I am also now using Twitter for quick updates and to share links. Follow me at: twitter.com/scottgu

A couple weeks ago, I took the plunge and switched to vim (MacVIM, to be precise). It wasn’t the first time I tried to make the switch, and I had pretty much written it off entirely.

Why? Because the past few times I tried switching to vim, I took the advice of a master vim user, and quickly sunk into the quicksand of trying to learn a new tool. In every prior attempt, I gave vim a few days before I gave up. And every time, I managed to get virtually no work done the entire time, spending about 90 percent of my day fighting with my editor (a more charitable way to put it would be “learning my editor”).

Invariably, the master vim users that were helping me make the switch would encourage me to stick it out. “If you just give it a few weeks, you’ll never want to switch back.”

The trouble was, I had work to do. I could only switch editors if the new editor did not significantly impede on my day-to-day work. I can already hear the responses: “That’s simply impossible. It’s a new editor designed for advanced users. You’ll just have to put up with the pain until you get used to it.”

Here’s the thing, though: I didn’t really have to put up with a huge amount of pain when switching to Textmate for the first time. In fact, it was downright pleasant.

The last few times someone tried to get me to switch to vim, I issued them a simple challenge. Can you tell me a way to switch that will not significantly reduce my productivity for the first few weeks. It wasn’t a challenge that was intended to fully shut down discussion. When I really thought about it, Textmate wasn’t doing all that much for me. It was a glorified Notepad which had working syntax highlighting and understand where to put the cursor when I hit enter (most of the time).

I don’t actually use “snippets” all that often, or all that many “commands”. I don’t mind the extensibility of Textmate, but I’m not a hardcore Textmate hacker myself, meaning that I’m ok with any editor that has the same level of extensibility that Textmate has (namely, all of them).

Despite what I considered a relatively reasonable request, my challenge was met with disdain and even anger by most of the people I talked to. “If you feel that way, Vim probably isn’t for you.” “You’re learning a new EDITOR for God’s sakes. Of COURSE there’s going to be a learning curve.”

I had written off the entire sorry affair.

A few weeks ago, Carl told me that he was playing with Vim. His explanation was that he had seen a number of people be really productive with it, and he was curious. Carl is definitely willing to put up with more pain to learn something new than I am, so I issued the same challenge to him.

Perhaps because he wasn’t steeped in hardcore vim hacker lore, he didn’t angrily dismiss the entire premise of my question. Thinking about it a bit more, I realized that most of the people who had tried to get me into vim had suggested that I dive in head first. “First thing: turn off the arrow keys.” “Don’t use the mouse. Force yourself to use the keyboard.”

Carl convinced me to use vim for the first couple of days pretty much exactly as I use Texmate (with the exception of having to switch between normal and insert modes). I installed NERDTree on MacVIM, grabbed the most common vim “packages”, and was off to the races. (I should note that I installed topfunky’s PeepOpen, which definitely helped with a very common workflow that I find it hard to live without).

For the first day, I clunked around by using my mouse’s scroll wheel, clicking and highlighting things, and spending most of my time in insert mode. It was slightly less productive than Textmate, but mostly in the range of what I’d expect switching to a new tool. In short, while I felt a bit out of sorts, I was able to get plenty of work done that first day.

As the days went on, I learned a few commands here and there. The first big one for me was ci as in ci " (it means: replace what’s inside the next set of " and go into insert mode). This singlehandedly made up for most of the productivity losses I was feeling from learning a new tool. Throw in o, O, A, :N and /search and I was already quite a bit more productive than I had been in Textmate.

Sure, I’m still plodding around in some cases, but only a handful of days later, using Textmate for anything feels clunky (most commonly, I try to use o or O to insert a new line above or below the one I’m currently on).

I was able to get here because I used my mouse wheel and button, arrow keys, apple-f to find text, apple-s to save files, and a whole slew of other common idioms, instead of grinding to a halt and trying to switch all of my practices at once.

To those who would say “that’s obvious; of course you learn vim incrementally”, I would simply say that having spoken to a number of vim users in the past, I never got that advice. Instead, I got a lot of advice about turning off my arrow keys, disallowing the use of the mouse, and learning the (MORE EFFICIENT!!!) vim ways to do everything, all at once. People just couldn’t stomach the idea of me continuing to use an outmoded practice (like apple-f) when vim had much better tools available just a (huge volume of) memorization away.

To those who are considering using vim, my recommendation is to use MacVIM, NERDTree, PeepOpen (or command-t), and use the mouse, arrow keys, and familiar OSX’isms all you want. Very quickly, it will become obvious that there’s a better way to do all kinds of things, and you can pile on the newly found efficiency once you’ve successfully made the switch without losing the ability to do work in the short-run.

addthis_url = 'http%3A%2F%2Fyehudakatz.com%2F2010%2F07%2F29%2Feveryone-who-tried-to-convince-me-to-use-vim-was-wrong%2F'; addthis_title = 'Everyone+Who+Tried+to+Convince+Me+to+use+Vim+was+Wrong'; addthis_pub = '';

Cloud computing is an emerging phenomenon that offers enormous advantages, such as shorter time to market, flexible computing capabilities and limitless power, but the cloud market, still in a very early stage, continues to grow and evolve.

But cloud computing is much more than technology, cutting costs or getting more agile. The cloud model is a new business model, a new way of thinking and doing IT as a business instead of a technology! The cloud business model. More modular, incremental, selective, collaborative and with a value proposition based on financial liquidity and operational flexibility [Forrester, 2010]. This has a lot of (side) effects, also on software testing…

New model for testing

The way we do business around testing will change also. Not the way we test, but how we deliver it. The market will be more focused on value driven, agile, modular and flexible solutions from test service providers. These providers need to create more ‘building blocks’ around how they deliver services: testing. Testing will also become a service, Software Testing as a Service (has a nice buzz ring to it).

Software Testing as a Service

Software Testing as a Service (STaaS) was coined by my colleague Leo van der Aalst in 2008, but his ideas didn’t go as far as I would think of today. In Leo’s proposal all testing was done by a service provider on demand at the scale as needed by the client. My idea goes further.

Software testing needs to be even more flexible, from the test manager to the test engineer, from the system test environment to the performance test environment, from the security scan to the full usability test and from audits to end-2-end tests. And everything can be done separate and fully integrated with one other. This creates a full cloud model for testing. With the possibility to be fully standardized, agile and elastic to help the client when needed; a full service consisting of several building blocks.

We’re very proud to tell you that we’ve just launched a new feature for the Google font directory. The new Google font previewer lets you test drive all the fonts in the directory so you can decide which web font in the Google Font API works best for your requirements.

Now, whenever you visit the font family page of any of the fonts, you will see a link saying “Preview this font” that will load your font selection into the font previewer.

Here you can edit the text, change its size and line height, and add decorations and spacing among other things. You can even apply text shadow to your text.

The previewer will generate the corresponding code for you so all you have to do to start using the font on your own website is to copy and paste the stylesheet link and the CSS into your pages. In the example above this would be:

<link  href="http://fonts.googleapis.com/css?family=Lobster:regular"
rel="stylesheet" type="text/css" >
<style> body {   
  font-family: 'Lobster', serif; 
  font-size: 28px;
   font-weight: 400;
   text-shadow: 4px 4px 4px #bbb;
  text-decoration: underline; 
  text-transform: lowercase;   line-height: 1.42em; } 
</style>

That’s really all you need to use the Google Font API.

If you want to see the font sample without any distractions from the font previewer controls, you can do that as well simply by clicking “Toggle controls” in the upper right corner. This will show you a nice clean example of what the font would look like in your design.

We think the previewer is a great way to try out web fonts and showcase what can be done with them. We’re looking forward to hearing what you think about the new font previewer.

By Marc Tobias Kunisch, Google Font API team

RT @batimes Assessing the Impact of Poor Requirements on Companies | Business Analyst White Papers http://ow.ly/1qLSwG Software requirements

There are unlimited opinions floating around about the role of management. Many come from voices that would have management be removed from the process - the extreme agile point of view.

For those looking to understand how management has and is evolving in the "post industrial" age, here's a nice article A NEW ROLE FOR MANAGEMENT IN TODAY’S POST-INDUSTRIAL ORGANIZATION

The Ivey Business Journal is free Business Journal from the Ivey School of Business, University of Western Ontario.

Most people in the software development industry will (hopefully) agree that estimates are important. You need estimates to predict the cost of development and how long it’s going to take. Without them, there is no way you could promise a delivery date to a customer or come up with a total cost estimate. Both of which are tremendously important when your core business is based on delivering software to clients. It is therefore very important to make sure your estimates are as good as they can be, and that you review your estimates with the final actual figures so you can figure out where you need to start improving (either your development process, or your estimation practices).

But there are some things you need to watch out for in any organization which takes estimates seriously. Most development shops have estimates at the task-level. These task-level estimates are often used during the planning of the next iteration, but were most likely also used in the initial total estimate of the project. I certainly don’t doubt the importance of those task-level estimates, but i do think they should be used cautiously.

If too much importance is placed on staying below the estimates, or at least not going over them, you run the risk of growing a culture where developers let the estimates have too much influence on the quality of the work they’re doing. Some developers will strive hard to routinely stay below the estimates. Some developers will work in fear of going over the estimate. In both cases, it leads to technical shortcuts that will be taken. Those shortcuts will consist of skipping some tests here and there, skipping a bunch of tests altogether, decreasing willingness to refactor code that could use it and worst of all, no longer keeping a clean design in mind. Granted, i’m painting a very bleak picture here but it does happen with some people and the negative results can not be underestimated.

Let’s consider the overall effect of these shortcuts. A shortcut here or there is not abnormal in some circumstances, but it should be exceptional. It should not become routine, it should be frowned upon and i’d even go as far as recommending a “no shortcuts allowed unless the team approves of it” policy. A shortcut here or there doesn’t take a lot of effort to fix and because of this, it can often be done as soon as the original reason of the existence of the shortcut (typically: a deadline) is no longer an issue. An accumulation of shortcuts however leads to not only an obviously bigger workload to fix all of the shortcuts, but it also impacts a lot of other code that shouldn’t have been impacted in the first place. Once this happens, you’ve got yourself an unhealthy code base and it’s only going to get worse until it eventually dies at a younger age than it could have reached.

Now, imagine a culture where estimates are given as much importance as quality. If you’re approaching the estimate and you’ve still got a lot of work left to fully complete the task (and with fully completed, i really don’t mean watching it work on your machine as you manually test it), then you consult with the rest of your team members. Estimate how much time it would take to fully complete the task, and see if the increased time over the original estimate is doable. If you’re already behind your overall schedule, it’s probably not doable unless there are many subsequent tasks that are dependent on this particular task. But if you’re ahead of schedule, you’re probably better off accepting the fact that you’re going to go over this task’s original estimate in order to do it right. If you do so, the extra hours you spent on this task should (in most cases at least) not lead to extra hours on future tasks. Conversely, if you’ve finished a task well below the estimate, it might actually be a good investment to refactor some ‘bad’ code that you’ve come across while working on your task. Or to add some missing tests here or there. That certainly doesn’t mean that you need to spend all the available remaining time you have but you shouldn’t run to start on a new task as soon as humanly possible either. Follow the boy scout rule here… you won’t spend that much extra time on it, but overall quality can improve greatly from this.

In fact, i’d even bet that the time it takes to do it right will in a large majority of cases still be less than the sum of the original time that was spent on a task hastily done and the time that will be spent on bugs that resulted from that hastily done task, not to mention the impact it could have on the development of future tasks simply because of the suboptimal implementation of the hastily done task.

Finally, it’s also important to think about why there was a need to go over an estimate. There can be a variety of reasons for this, and one of them is that the task was simply badly estimated. If that indeed turns out to be the case, make sure that you learn from it to prevent this from happening in the future. When we find bugs in our code, we try to prevent those bugs from ever occurring again. We should have a similar attitude to our estimating practices as well. If an estimate was simply too low, make sure that a similar task in the future won’t be estimated too low again or you will again introduce a possible problem in your (future) project.

And that, in my opinion, is also a good reason to decide to go over the estimate if you can. If you go over the estimate and all people involved learn from the bad estimate, then everyone basically benefits from it. Future estimates should become more accurate, and no code was harmed in the process. You might have lost some money on it, but at least you only lost it once instead of losing it over and over again in similar future circumstances.

After 3 years working in xsights as VP R&D, it is now time to move on.

I am looking for an interesting development management position preferably as VP R&D. Other interesting opportunities (e.g. a  chief architect position) will also be welcomed. The position should be in Israel (Hasharon, Tel-aviv or Haifa areas)

On a related note, I am also available for focused consulting engagements. By focused I mean deliverables oriented (not by the hour) engagements such as architecture evaluation, technical due diligence or architecture  workshop. You can see more details in this page. Currently I am available for consulting world-wide.

If you are interested you can grab a copy of my CV from here (English) or here (Hebrew)

Last but not least, since we are closing my team is also on the look for new jobs so if you need some great .NET people please ping me as well

For those of you scratching your head regarding last weeks “wanted ad” – yes this was a surprise for us (esp. considering that that the company was restarted with a new CEO just 4 months ago..oh well that’s life I guess :) )

You can contact me here

10 Characteristics of High-Quality SRS http://bit.ly/adOJLl

The approach some people have to the issue of social diversity is rather simplistic. Their idea of “adding diversity” to a software team is usually limited to attracting more women. It is an approach based on stereotypes about gender differences,... Jurgen Appelo

  This is the 5th  International Workshop on Requirements Engineering Education and Training (REET’10) Held in conjunction with the 18th International Requirements Engineering Conference (RE’10)   The workshop will be held in Sydney, Australia on Tuesday 28th September 2010. This workshop will address issues related to RE education, both as part of a formal university [...]

This is the tenth post in a series of blog posts discussing Lean Architecture principles. Each post discusses one principle. Applying these principles results in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The tenth principle we discuss is called "Architecture emerging from Projects". One of [...]

Following the recommendations of Corey Haines, Michael Guterl, James Martin and Michael Hunger I decided to get Kent Beck's screencasts on Test Driven Development which have been published by the Pragmatic Programmers.

I read Kent's 'Test Driven Development By Example' book a couple of years ago and remember enjoying that so I was intrigued as to what it would be like to see some of those ideas put into practice in real time.

As I expected a lot of Kent's approach wasn't that surprising to me but there were a few things which stood out:

• Kent wrote the code inside the first test and didn't pull that out into its own class until the first test case was working. I've only used this approach in coding dojos when we followed Keith Braithwaite's 'TDD as if you meant it' idea. Kent wasn't as stringent about writing all the code inside the test though – he only did this when he was getting started with the problem.

  The goal seemed to be to keep the feedback loop as tight as possible and this was approach was the easiest way to achieve that when starting out.

• He reminded me of the 'calling the shots' technique when test driving a piece of code. We should predict what's going to happen when we run the test rather than just blindly running it. Kent pointed out that this is a good way for us to learn something – if the test doesn't fail/pass the way that we expect it to then we have a gap in our understanding of how the code works. We can then do something about closing that gap.
• I was quite surprised that Kent copied and pasted part of an existing test almost every time he created a new one – I thought that was just something that we did because we're immensely lazy!

  I'm still unsure about this practice because although Ian Cartwright points out the dangers of doing this it does seem to make for better pairing sessions. The navigator doesn't have to wait twiddling their thumbs while their pair types out what is probably a fairly similar test to one of the others in the same file. Having said that it could be argued that if your tests are that similar then perhaps there's a better way to write them.

  For me the main benefit of not copy/pasting is that it puts us in a mindset where we have to think about the next test that we're going to write. I got the impression that Kent was doing that anyway so it's probably not such a big deal.

• Kent used the 'present tense' in his test names rather than prefixing each test with 'should'. This is an approach I came across when working with Raph at the end of last year.

  To use Esko Luontola's lingo I think the tests follow the specification style as each of them seems to describe a particular behaviour for part of the API.

  I found it interesting that he includes the method name as part of the test name. For some reason I've tried to avoid doing this and often end up with really verbose test names when a more concise name with the method name included would have been way more readable.

  A couple of examples are 'getRetrievesWhatWasPut' and 'getReturnsNullIfKeyNotFound' which both describe the intent of their test clearly and concisely. The code and tests are available to download from the Prag Prog website.

• One thing which I don't think I quite yet grasp is something Kent pointed out in his summary at the end of the 4th screencast. To paraphrase, he suggested that the order in which we write our tests/code can have quite a big impact on the way that the code evolves.

  He described the following algorithm to help find the best order:

  • Write some code
    • erase it
    • write it in a different order

  And repeat.

  I'm not sure if Kent intended for that cycle to be followed just when practicing or if it's something he'd do with real code too. An interesting idea either way and since I haven't ever used that technique I'm intrigued as to how it would impact the way code evolved.

• There were also a few good reminders across all the episodes:
  • Don't parameterise code until you actually need to.
  • Follow the Test – Code – Cleanup cycle.
  • Keep a list of tests to write and cross them off as you go.

Overall it was an interesting series of videos to watch and there were certainly some good reminders and ideas for doing TDD more effectively.

Knowing where you are most likely to fail can help set the stage for reducing the chances of failure.

- Bilal M. Ayyub, Peter G. Prassinos, and John Etherton

Mark Zuckerberg and David Kirkpatrick spoke at the Computer History Museum, and you'll find their dialog here.

Quote of the day:

The way of the world is meeting people through other people.
Robert Kerrigan