Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Feed aggregator

4 types of user

Mark Needham - 9 hours 3 min ago

I’ve been working with Neo4j full time for slightly more than a year now and from interacting with the community I’ve noticed that while using different features of the product people fall into 4 categories.

These are as follows:

4types

On one axis we have ‘loudness’ i.e. how vocal somebody is either on twitter, StackOverflow or by email and on the other we have ‘success’ which is how well a product feature is working for them.

The people in the top half of the diagram will get the most attention because they’re the most visible.

Of those people we’ll tend to spend more time on the people who are unhappy and vocal to try and help them solve the problems their having.

When working with the people in the top left it’s difficult to understand how representative they are for the whole user base.

It could be the case that they aren’t representative at all and actually there is a quiet majority who the product is working for and are just getting on with it with no fuss.

However, it could equally be the case that they are absolutely representative and there are a lot of users quietly suffering / giving up using the product.

I haven’t come up with a good way to come across the less vocal users but in my experience they’ll often be passive users of the user group or Stack Overflow i.e. they’ll read existing issues but not post anything themselves.

Given this uncertainty I think it makes sense to assume that the silent majority suffer the same problems as the more vocal minority.

Another interesting thing I’ve noticed about this quadrant is that the people in the top right are often the best people in the community to help those who are struggling.

It’d be interesting to know whether anyone has noticed a similar thing with the products they worked on, and if so what approach do you take to unveiling the silent majority?

Categories: Programming

2 minute models: A walk through the Feature Tree Model

Please join me for a quick walk through of our Feature Tree Model. This video only scratches the surface of how valuable this model really is, and how it can be used for a variety of projects. Please feel free to make suggestions and ask questions in the comments section, and I will address them […]
Categories: Requirements

Grow with Google Play: Scaled Publishing and New App Insights

Android Developers Blog - 10 hours 5 min ago

By Kobi Glick, Google Play team

If you're growing your business on Google Play, the Google Play Developer Console is one of the most important tools at your disposal. At Google I/O, we introduced a number of new changes that give you valuable insight into how your app is performing. Here's an overview of some of the improvements you can now take advantage of.

Publishing API for scaling your app operations

Today we're happy to announce that the Google Play Developer Publishing API is now available to all developers. The API will let you upload APKs to Beta testing, Staged rollout and Production, and integrate publishing operations with your release processes and toolchain. The Publishing API also makes it easier for you to manage your in-app products catalog, provide tablet-specific screenshots, and localize your store listing text and graphics. The Publishing API will help you focus on your core business, with less time managing your releases, even as your business grows to more apps and markets.

Actionable insights at the right time Email notifications for alerts

Recently, we added Alerts in the Developer Console to let you know when there are sudden changes in important stats like app installs, ratings, and crashes. You can now turn on email notifications for Alerts so that, even while you’re not in the Developer Console, you’ll be informed of relevant events before they can have a broader effect on your app. You can turn on email notifications for one or more of your apps under Email Preferences in the Developer Console settings.

New Optimization Tips

You’ll now see new Optimization Tips with instructions when we detect opportunities to improve your app. For example, we’ll let you know when updated versions of APIs you use are available — such as new Google Play in-app billing or Google Maps APIs. For games developers, we’ll also surface opportunities to use Google Play game services that can help improve users’ gaming experience and drive engagement. To see what tips we suggest for you, go to your app in the Developer Console and click on Optimization Tips.

Better data to inform your business decisions Enhanced revenue statistics

To help you better understand your commercial success, we’ve enhanced revenue statistics in the Finance section of the Developer Console. We now let you see the average revenue per paying user (ARPPU) and give you more ways to analyse buyer data, such as comparing returning buyers (i.e., those who also made purchases in the past) to new buyers.

Bulk export of reviews

You can already engage with your users by reading and replying to reviews in the Developer Console and we’ve now added bulk export of reviews so you can download and analyze your app’s reviews en masse. This is particularly useful if you receive a large volume of reviews and want to perform your own sentiment analysis.

Improved stats for beta releases and staged rollouts

Since last year’s launch, you’ve used beta testing to release alpha and beta versions of your app, and staged rollout to gradually launch your app to production. To help you make the most of this feature, we’re now improving the way alpha, beta and staged rollout specific stats are displayed. When viewing your app and crash statistics you can now filter the app version by alpha, beta, or staged rollout to better understand the impact of your testing.

Improved reporting of native crashes

If you develop in native code, we’ve improved the reporting and presentation specifically for native crashes, with better grouping of similar crashes and summarizing of relevant information.

Deep-linking to help drive engagement

Finally, we’ve also added website verification in the Developer Console, to enable deep-linking to your app from search results. Deep-linking helps remind users about the apps they already have. It is available through search for all apps that implement app indexing. For example, if a user with the Walmart Android app searches for “Chromecast where to buy”, they’ll go directly to the Chromecast page in the Walmart app. The new App Indexing API is now open to all Android developers, globally. Get started now.

We hope you find these features useful and take advantage of them so that you can continue to grow your user base and improve your users’ experience. If you're interested in some other great tools for distributing your apps, check out this blog post, or any of the sessions which have now been posted to the Google Developers Channel.
Join the discussion on
+Android Developers


Categories: Programming

Quote of the Day

Herding Cats - Glen Alleman - 11 hours 32 min ago

"Great minds discuss ideas; average minds discuss events; small minds discuss people."  - Eleanor Roosevelt 

Categories: Project Management

Ray Bradbury on the Benefits of Short Releases

Mike Cohn's Blog - 14 hours 10 min ago

In 2001, author Ray Bradbury gave a talk at the annual Writer’s Symposium by the Sea in San Diego. Fortunately for those of us who were not there, his speech was video recorded and is available.

Bradbury—the author of books such as Fahrenheit 451, The Martian Chronicles, Something Wicked This Way Comes—was offering advice to an audience mostly of aspiring writers. But I watched his speech recently and was struck by the appropriateness of Bradbury’s advice to those of us on agile project.

Early in his talk, Bradbury recommends that aspiring writers write short stories rather than novels. He says that writing a novel at the start of one’s career is a mistake because “you could spend a whole year writing one, and it might not turn out well because you haven’t learned to write yet.”

Bradbury advises instead writing “a hell of a lot of short stories,” suggesting writing one per week. He says “at the end of a year, you have 52 short stories, and I defy you to write 52 bad ones.”

It “can’t be done,” Bradbury jokes, saying that with that much practice, the aspiring writer will eventually come up with something good.

So I’ll go along with Bradbury, but instead of writing short stories, let’s put out new features. Let’s give our customers one release per week for the next year. And, like Bradbury, I defy you to put out 52 bad releases.

Sure, some of your releases will have things your users don’t want. You thought your users would want them, some minimal amount of research may have shown they would, but when you put that release out, you found out otherwise. What you can’t do, though, is put out 52 releases and fail to learn from them.

Like Bradbury’s aspiring writers, you’ll learn more about your customers, your product, and your team. And, like Ray Bradbury, that will help you find your bestseller.

Even if you don’t have time to listen to Bradbury’s full speech (it’s 54 minutes), listen to the first 6 minutes. He makes at least one other point very relevant to the short iterations of agile. If you listen, let me know in the comments below, what else you heard that’s relevant to agile.

How To Make Decisions

Herding Cats - Glen Alleman - Tue, 07/29/2014 - 04:22

Decisions are about making Trade Offs for the project. These decisions are about:

  • Evaluating alternatives.
  • Integrating and balancing all the considerations (cost, performance, Producibility, testability, supportability, etc.).
  • Developing and refining the requirements, concepts, capabilities of the product or services produced by the project or product development process.
  • Making trade studies and the resulting trade offs that enables the selection of the best or most balanced solution to fulfill the business need or accomplishment of the mission.

The purpose of this decision making process is to:

  • Identify the trade-offs – the decisions to be made – among requirements, design, schedule, and cost.
  • Establish the level of assessment commensurate with cost, schedule, performance, and risk impact based on the value at risk for the decision.
    • Low value at risk, low impact, simple decision making – possibly even gut feel.
    • High value at risk, high impact, the decision-making process must take into account these impacts.

Trade-offs are essential to strategy. They create the need for choice and purposefully limit what a company offers.

It is only by assessing the impacts of these tradeoffs can the products or solutions of the projects be guided. Otherwise, just producing the requiremenst has no real purpose - no strategic purpose connected to the needed capabilities. ‡

Making decisions about capabilities and resulting requirements is the starting point for discovering what DONE looks like, by:

  • Establishing alternatives for the needed performance and functional requirements.
  • Resolving conflicts between these requirements in terms of the product’s delivered capabilities.

Decisions about the functional behaviours and their options is next. These decisions:

  • Determine preferred set of requirements for the needed capabilities. This of course is an evolutionary process as requirements emerge, working products are put to use, and feedback is obtained.
  • Determine the customer assesses requirements for lower-level functions as each of the higher-level capabilities are assessed.
  • Evaluate alternatives to each requirement, each capability, and the assessed value of each capability – in units of measure meaningful to the decision makers.

Then comes the assessment the cost effectiveness of each decision:

  • Develop the Measures of Effectiveness (MOE) and Measures of Performance (MOP) for each decision.
  • Identify the critical Measures of Effectiveness of each decision in fulfilling the project’s business goal or mission. These Technical Performance Measures are used to assess the impact of each decision on the produced value of the project.

Each of these steps is reflected in the next diagram.

Screen Shot 2014-07-28 at 8.08.44 AM

Value of This Approach

When we hear that estimates are not needed to make decisions, we need to ask how the following questions can be answered:

  • How can we have a systematized thought process, where the decisions are based on measureable impacts?
  • How can we clarify our options, problem structure, and available trade-offs using units of measure meaningful to the decision makers?
  • How can we improve communication of ideas and professional judgment within our organization through a shared exchange of the impacts of our decisions?
  • How can we improve communication of rationale for each decision to others outside the organization?
  • How can we be assured of our confidence that all available information has been accounted for in a decision?

The decision making process is guided by the identification of alternatives

Decision-making is about deciding between alternatives. These alternatives need to be identified, assessed, and analyzed for their impact on the probability of success of the project.

These impacts include, but are not limited to:

  • Performance
  • Schedule
  • Cost
  • Risk
  • Affordability
  • Producibility
  • And all the other …ilities associated with the outcomes of the project

The effectiveness of our decision making follows the diagram below:

  Screen Shot 2014-07-28 at 8.05.58 AM

In the End - Have all the Alternatives Been Considered?

Until there is a replacement for the principles of Microeconomics, for each decision made on the project, we will need to know the impact on cost, schedule, technical parameters, and other attributes of that decision. To not know those impacts literally violates the principles of microeconomics and the governance framework of all business processes, where the value at risk is non-trivial.

As Shim says think about it

Screen Shot 2014-07-28 at 12.26.24 PM

When you hear planning ahead, by assessing our altenatives is overrated, think again.

‡ What is Strategy? , M. E. Porter, Harvard Business Review, Volume 74, Number 6, pp. 61-68.

Connecting IT and Business Strategy, Glen B. Alleman, 5/12/2007

† Derived from Module J: Trade Study Process, Systems Engineering, Boeing.

Related articles Agile Project Management Concept of Operations First, then Capabilities, then Requirements The Value of Information Critical Thinking Skills Needed for Any Change To Be Effective Why Project Management is a Control System
Categories: Project Management

Plans

A map is a plan.

A map is a plan.

All projects should have some sort of plan. Whether that plan is a classic project plan and schedule or a prioritized backlog and a release plan. A plan helps answer stakeholder questions and, perhaps more importantly, it reflects the philosophy of the project. In order for a plan of any type to be helpful, the plan and philosophy must be possible. Bob Ferguson (Listen to SPaMCAST 240) said that there were ways to detect a plan what was not possible. Several of the rules of thumb that Bob suggested (augmented with a few of my own) are:

  1. Difficult work is done late. This is on both of our lists. Teams that avoid addressing difficult or technically complex stories backload risk, which can impact a project’s ability to deliver value. Conceptually this problem should be harder in Agile, assuming stories or features are prioritized in value order and the inter-relationship between features is factored into the value discussion.
  2. Learning is not explicitly planned. Any project that is creating new features or a new product should have prototyping built into the process used to gather requirements and build a backlog. Experiments/prototypes also can and should be used to prove solutions that are complex or cutting edge (at least for the team). This item was on Bob’s list and not on mine; it is now.
  3. Rate of story completion is not feasible. If the plan can’t be completed given the team’s (or teams’) level of velocity or productivity, then it is a bad plan. Plans that specify the amounts of functionality to be delivered, the date of delivery and the budget to be spent have credibility problems, however when they are developed using wishful thinking productivity rates they enter into the impossible range. This one is on my list and not Bob’s (in your face Bob).
  4. Belief that the plan — is THE Plan. A plan, schedule or backlog that does not change for a project of any moderate or large size is wrong or if it actually works is  the reflection of sheer dumb luck (Harry Potter reference – reread Harry Potter and the Philosopher’s Stone.). Anyone that falls into the trap of absolute belief that any project deliverable can be created once and referenced forever will find delivering value difficult at best.
  5. Not involving the business. The real product owner(s) must be part of the product to act as an active conduit of business acumen into the team to minimize wait and search time. All too often business stakeholders have been taught treat the boundary between IT and the business as a demilitarized zone where information hand-offs occur on a periodic basis. This behavior makes planning and maintaining any sort of plan difficult at best which slows the project down. IT teams often elect proxy product owners from inside the IT boundary leading to the same result (I heard this termed all of the responsibility and none of the authority). Proxy product owners can’t provide the level of feedback on priorities and the plan that the business can.

Plans have value only if they are current and only if maintaining plans, schedules, backlogs and the release plans do not become the goal of the project. Planning helps teams to develop a strategy for delivering value, but they must be allowed to change. Change is inevitable because we are learning both personally and about our project everyday. Not using what we learn is silly!

 


Categories: Process Management

No Slack = No Innovation

"To accomplish great things we must dream as well as act." -- Anatole France

Innovation is the way to leap frog and create new ways to do things better, faster, and cheaper.

But it takes slack.

The problem is when you squeeze the goose, to get the golden egg, you lose the slack that creates the eggs in the first place.

In the book The Future of Management, Gary Hamel shares how when there is a lack of slack, there is no innovation.

The Most Important Source of Productivity is Creativity

Creativity unleashes productivity.  And it takes time to unleash creativity.  But the big bold bet is that the time you give to creativity and innovation, pays you back with new opportunities and new ways to do things better, faster, or cheaper.

Via The Future of Management:

“In the pursuit of efficiency, companies have wrung a lot of slack out of their operations.  That's a good thing.  No one can argue with the goal of cutting inventory levels, reducing working capital, and slashing over-head.  The problem, though, is that if you wring all the slack out of a company, you'll wring out all of the innovation as well.  Innovation takes time -- time to dream, time to reflect, time to learn, time to invent, and time to experiment.  And it takes uninterrupted time -- time when you can put your feet up and stare off into space.  As Pekka Himanen put it in his affectionate tribute to hackers, '... the information economy's most important source of productivity is creativity, and it is not possible to create interesting things in a constant hurry or in a regulated way from nine to five.'”

There is No “Thinking Time”

Without think time, creativity lives in a cave.

Via The Future of Management:

“While the folks in R&D and new product development are given time to innovate, most employees don't enjoy this luxury.  Every day brings a barrage of e-mails, voice mails, and back-to-back meetings.  In this world, where the need to be 'responsive' fragments human attention into a thousand tiny shards, there is no 'thinking time.'  And therein lies the problem.  However creative your colleagues may be, if they don't have the right to occasionally abandon their posts and work on something that's not mission critical, most of their creativity will remain dormant.”

Are People Encouraged to Quietly Dream Up the Future?

If you want more innovation, make space for it.

Via The Future of Management:

“OK, you already know that -- but how is that knowledge reflected in your company's management processes?  How hard is it for a frontline employee to get permission to spend 20 percent of her time working on a project that has nothing to do with her day job, nor your company's 'core businesses'?  And how often does this happen?  Does your company track the number of hours employees spend working on ideas that are incidental to their core responsibilities? Is 'slack' institutionalized in the same way that cost efficiency is?  Probably not.  There are plenty of incentives in your company for people to stay busy.  ('Maybe if I look like I'm working flat out, they won't send my job offshore.')  But where are the incentives that encourage people to spend time quietly dreaming up the future?”

Are you slacking your way to a better future?

You Might Also Like

Innovation Quotes

The Drag of Old Mental Models on Innovation and Change

The New Competitive Landscape

The New Realities that Call for New Organizational and Management Capabilities

Who’s Managing Your Company

Categories: Architecture, Programming

3 Challenges to Help You Set New Benchmarks in Innovation

If you want to change your game, you need to know what the key challenges are.

Innovation is a game that you can play much better, if you know where and how to debottleneck it.

In the book The Future of Management, Gary Hamel shares 3 challenges that he believes can help you unleash your organization’s capacity for innovation.

  1. How can you enroll every individual within your company in the work of innovation, and equip each one with creativity-boosting tools?
  2. How can you ensure that top management's hallowed beliefs don't straightjacket innovation, and that heretical ideas are given the chance to prove their worth?
  3. How can you create the time and space for grassroots innovation in an organization that is running flat to deliver today's results?

According to Hamel, "Make progress on these challenges and your company will set new benchmarks in innovation."

If I think back through the various teams I’ve been on at Microsoft, one team that I was on was especially good at helping innovation flourish, and we were constantly pushing the envelope to “be what’s next.”   Our innovation flourished the most when we directly addressed the challenges above.  People were challenged to share and test their ideas more freely and innovation was baked into how we planned our portfolio, programs, and projects.

Innovation was a first-class citizen – by design.

You Might Also Like

High-Leverage Strategies for Innovation

Innovation Life Cycle

Lessons Learned from the Most Successful Innovators

The Drag of Old Mental Models on Innovation and Change

The New Realities that Call for New Organizational and Management Capabilities

Categories: Architecture, Programming

Episode 207: Mitchell Hashimoto on the Vagrant Project

Charles Anderson talks to Mitchell Hashimoto about the Vagrant open source project, which can be used to create and configure lightweight, reproducible, and portable development environments. Vagrant aims to make new developers on a project productive within minutes of joining the project instead of spending hours or days setting up the developer’s workstation. The outline […]
Categories: Programming

The Great Microservices vs Monolithic Apps Twitter Melee

Once upon a time a great Twitter melee was fought for the coveted title of Consensus Best Way to Structure Systems. The competition was between Microservices and Monolithic Apps. 

Flying the the logo of Microservices, from a distant cloud covered land, is the Kingdom of Netflix, whose champion was Sir Adrian Cockcroft (who has pledged fealty to another). And for the Kingdom of ThoughtWorks we have Sir Sam Newman as champion.

Flying the logo of the Monolithic App is champion Sir John Allspaw, from the fair Kingdom of Etsy.

Knights from the Kingdom of Digital Ocean and several independent realms filled out the list.

To the winner goes a great prize: developer mindshare and the favor of that most fickle of ladies, Lady Luck.

May the best paradigm win.

The opening blow was wielded by the highly ranked Sir Cockcroft, a veteran of many tournaments:

Categories: Architecture

Certificates, Yes and No

NOOP.NL - Jurgen Appelo - Mon, 07/28/2014 - 15:30
certificate color

It seems that the debate around certificates will never end.

Some people and organizations ask me to provide official certificates for participants of Management 3.0 events. What we offer now is a simple “Certificate of Attendance”. It only says that we confirm that a person participated in the event, and that he or she was physically present in the room. That’s all. We cannot certify knowledge or understanding, because I don’t know of any “tests” to validate that a person understands and is able to apply Management 3.0 principles and practices.

The post Certificates, Yes and No appeared first on NOOP.NL.

Categories: Project Management

The Experience Paradox–How to Get a Job Without Experience

Making the Complex Simple - John Sonmez - Mon, 07/28/2014 - 15:00

One of the most difficult things about becoming a software developer, is the experience paradox of needing to have a job to get experience and needing to have experience in order to get a job. This problem is of course not relegated to the field of software development, but many new software developers often struggle […]

The post The Experience Paradox–How to Get a Job Without Experience appeared first on Simple Programmer.

Categories: Programming

Software Development Conferences Forecast July 2014

From the Editor of Methods & Tools - Mon, 07/28/2014 - 08:39
Here is a list of software development related conferences and events on Agile ( Scrum, Lean, Kanban) software testing and software quality, programming (Java, .NET, JavaScript, Ruby, Python, PHP) and databases (NoSQL, MySQL, etc.) that will take place in the coming weeks and that have media partnerships with the Methods & Tools software development magazine. Agile on the Beach, September 4-5 2014, Falmouth in Cornwall, UK SPTechCon, September 16-19 2014, Boston, USA Future of Web Apps, September 29-October 1 2014, London, UK STARWEST, October 12-17 2014, Anaheim, USA JAX London, October 13-15 2014, ...

SPaMCAST 300 – Vasco Duarte, #NoEstimates

www.spamcast.net

Listwww.spamcast.net

Listen to SPaMCAST 300

Show 300! Show Zero was published on January 7, 2007. 2,738 days later, we feature our interview with Vasco Duarte. We discussed #NoEstimates, which evokes a great deal of passion.  The interview will embraces that passion and we sort through the noise to get to the core of the idea which is highly useful despite all of the controversy. #NoEstimates asks teams, product owners and leaders to rethink how they predict project performance.  Change is hard but Vasco describes a less painful path to predicting delivery.

Vasco’s Bio:

Product manager, scrum master, project manager, director, and Agile coach are only some of the roles that Vasco has taken in software development organizations. That experience has been gained by having worked in the software industry since 1997, and being an Agile practitioner since 2004. Vasco has worked in small, medium and large software organizations as an Agile Coach or leader in Agile adoption. He was one of the leaders and catalysts of Agile methods and Agile culture adoption at Avira, Nokia and F-Secure.

Vasco’s blog can be found at http://SoftwareDevelopmentToday.com

Follow Vasco on Twitter @duarte_vasco

Next

Software Process and Measurement Cast number 301 will feature our essay on technical debt. Technical debt is the work not done or the shortcuts taken when delivering a product. We all take shortcuts, but at what cost?

Upcoming Events

I will be attending Agile 2014 in Orlando, July 28 through August 1, 2014.  It would be great to get together with SPaMCAST listeners, let me know if you are attending.

I will be presenting at the International Conference on Software Quality and Test Management in San Diego, CA on October 1.  I have a great discount code!!!! Contact me if you are interested!

I will be presenting at the North East Quality Council 60th Conference October 21st and 22nd in Springfield, MA.

More on all of these great events in the near future! I look forward to seeing all SPaMCAST readers and listeners that attend these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

 

 


Categories: Process Management

SPaMCAST 300 – Vasco Duarte, #NoEstimates

Software Process and Measurement Cast - Sun, 07/27/2014 - 22:00

Show 300! Show Zero was published on January 7, 2007. 2,738 days later, we feature our interview with Vasco Duarte. We discussed #NoEstimates, which evokes a great deal of passion.  The interview will embraces that passion and we sort through the noise to get to the core of the idea which is highly useful despite all of the controversy. #NoEstimates asks teams, product owners and leaders to rethink how they predict project performance.  Change is hard but Vasco describes a less painful path to predicting delivery.

Vasco’s Bio:

Product manager, scrum master, project manager, director, and Agile coach are only some of the roles that Vasco has taken in software development organizations. That experience has been gained by having worked in the software industry since 1997, and being an Agile practitioner since 2004. Vasco has worked in small, medium and large software organizations as an Agile Coach or leader in Agile adoption. He was one of the leaders and catalysts of Agile methods and Agile culture adoption at Avira, Nokia and F-Secure.

Vasco’s blog can be found at http://SoftwareDevelopmentToday.com

Follow Vasco on Twitter @duarte_vasco

 Next

Software Process and Measurement Cast number 301 will feature our essay on technical debt. Technical debt is the work not done or the shortcuts taken when delivering a product. We all take shortcuts, but at what cost?

Upcoming Events

I will be attending Agile 2014 in Orlando, July 28 through August 1, 2014.  It would be great to get together with SPaMCAST listeners, let me know if you are attending.

I will be presenting at the International Conference on Software Quality and Test Management in San Diego, CA on October 1.  I have a great discount code!!!! Contact me if you are interested!

I will be presenting at the North East Quality Council 60th Conference October 21st and 22nd in Springfield, MA.

More on all of these great events in the near future! I look forward to seeing all SPaMCAST readers and listeners that attend these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

Categories: Process Management

Quote of Day

Herding Cats - Glen Alleman - Sun, 07/27/2014 - 15:09

"in order to reason well ... it is absolutely necessary to possess ... such virtues as intellectual honesty and sincerity and a real love of the truth." — C. S. Pierce

Categories: Project Management

Building A Backlog: Technique Synthesis

 

Putting the parts together!

Putting the parts together!

Hand Drawn Chart Saturday

Techniques for building an initial backlog can be classified by how the conversation between stakeholders and the project team is initiated. Some techniques are focused on asking, other techniques focus on observing, while the third category is all about showing something and getting reactions. Most practitioners blend the best from each of the categories. Here are some examples of the hybrid techniques:

Role Playing Prototype: This technique blends paper prototypes (show) with role-playing (observe) to get users and stakeholders to consider how they might act in an environment that has not been fully designed.

Straw man/JAD: This synthesis seeds a JAD session (ask) with an loose outline of a solution or set of potential solutions that are used to guide the discussion which are at the core of JAD. However, the seeding tactic can inhibit creativity. The technique is less constraining when a set of competing solutions is used as the conversation seed, however developing the range of solutions before the JAD session  increases the cost of the JAD.

Embedding: This techniques puts team member(s) into a department to actually perform the work (observe) alongside actual users and stakeholders. This generally requires the embedded team member to be trained and mentored to intimately see how the work is done. I have seen debrief sessions added to this technique to ensure that participants get a chance to discuss the nuances in the workflow.   As I have noted before, with any observation technique everyone needs to understand what is going on and why. This is not an episode of Undercover Boss.

Combining tactics from different categories of techniques that teams use to develop an initial backlog can fundamentally change the dynamics of the requirements definition session. A group of stakeholders will generally have a diverse range of learning and interaction styles that they favor. Combining backlog building techniques gives the project team a better chance at making a connection. Combining techniques should not be done randomly or an ad-hoc basis. Selecting which techniques to combine has four prerequisites:

  1. Someone with experience and training (perhaps a business analyst).
  2. A knowledge of the user community (knowledge the product owner can provide).
  3. Planning (time and effort).
  4. Involved users and stakeholders (call on the product owner and project sponsor to help with this prerequisite).

Developing an initial backlog is a step to get projects going and moving in the right direction. It is, however, only a first step. Backlogs will evolve. Teams, product owners, users and other stakeholders will gain knowledge and experience as the project move forward that will continually shape and reshape the backlog.


Categories: Process Management

Fearless Speaking

“Do one thing every day that scares you.” ― Eleanor Roosevelt

I did a deep dive book review.

This time, I reviewed Fearless Speaking.

The book is more than meets the eye.

It’s actually a wealth of personal development skills at your fingertips and it’s a powerful way to grow your personal leadership skills.

In fact, there are almost fifty exercises throughout the book.

Here’s an example of one of the techniques …

Spotlight Technique #1

When you’re overly nervous and anxious as a public speaker, you place yourself in a ‘third degree’ spotlight.  That’s the name for the harsh bright light police detectives use in days gone by to ‘sweat’ a suspect and elicit a confession.  An interrogation room was always otherwise dimly lit, so the source of light trained on the person (who was usually forced to sit in a hard straight backed chair) was unrelenting.

This spotlight is always harsh, hot, and uncomfortable – and the truth is, you voluntarily train it on yourself by believing your audience is unforgiving.  The larger the audience, the more likely you believe that to be true.

So here’s a technique to get out from under this hot spotlight that you’re imagining so vividly turn it around! Visualize swiveling the spotlight so it’s aimed at your audience instead of you.  After all, aren’t you supposed to illuminate your listeners? You don’t want to leave them in the dark, do you?

There’s no doubt that it’s cooler and much more comfortable when you’re out under that harsh light.  The added benefit is that now the light is shining on your listeners – without question the most important people in the room or auditorium!

I like that there are so many exercises and techniques to choose from.   Many of them don’t fit my style, but there were several that exposed me to new ways of thinking and new ideas to try.

And what’s especially great is knowing that these exercise come from professional actors and speakers – it’s like an insider’s guide at your fingertips.

My book review on Fearless Speaking includes a list of all the exercises, the chapters at a glance, key features from the book, and a few of my favorite highlights from the book (sort of like a movie trailer for the book.)

You Might Also Like

7 Habits of Highly Effective People at a Glance

347 Personal Effectiveness Articles to Help You Change Your Game

Effectiveness Blog Post Roundup

Categories: Architecture, Programming

Transform the input before indexing in elasticsearch

Gridshore - Sat, 07/26/2014 - 07:51

Sometimes you are indexing data and want to have as little to do in the input, or maybe even no influence on the input. Still you need to make changes, you want other content, or other fields. Maybe even remove fields. In elasticsearch 1.3 a new feature is introduces called Transform. In this blogpost I am going to show some of the aspects of this new feature.

Insert the document with the problem

The input we get is coming from a system that puts the string null in a field if it is empty. We do not want null as a string in elasticsearch index. Therefore we want to remove this field completely when indexing a document like that. We start with the example and the proof that you can search on the field.

PUT /transform/simple/1
{
  "title":"This is a document with text",
  "description":"null"
}

Now search for the word null in the description.

For completeness I’ll show you the response as well.

Response:
{
   "took": 1,
   "timed_out": false,
   "_shards": {
      "total": 1,
      "successful": 1,
      "failed": 0
   },
   "hits": {
      "total": 1,
      "max_score": 0.30685282,
      "hits": [
         {
            "_index": "transform",
            "_type": "simple",
            "_id": "1",
            "_score": 0.30685282,
            "_source": {
               "title": "This is a document with text",
               "description": "null"
            }
         }
      ]
   }
}
Change mapping to contain transform

Next we are going to use the transform functionality to remove the field if it contains the string null. To do that we need to remove the index and create a mapping containing the transform functionality. We use the groovy language for the script. Beware that the script is only validated when the first document is inserted.

PUT /transform
{
  "mappings": {
    "simple": {
      "transform": {
        "lang":"groovy",
        "script":"if (ctx._source['description']?.equals('null')) ctx._source['description'] = null"
      },
      "properties": {
        "title": {
          "type": "string"
        },
        "description": {
          "type": "string"
        }
      }
    }
  }
}

When we insert the same document as before and execute the same query we do not get hits. The description field is no longer indexed. An important aspect is that the actual _source is not changed. When requesting the _source of the document you still get back the original document.

GET transform/simple/1/_source
Response:
{
   "title": "This is a document with text",
   "description": "null"
}
Add a field to the mapping

To add a bit more complexity, we add a field called nullField which will contain the name of the field that was null. Not very useful but it suits to show the possibilities.

PUT /transform
{
  "mappings": {
    "simple": {
      "transform": {
        "lang":"groovy",
        "script":"if (ctx._source['description']?.equals('null')) {ctx._source['description'] = null;ctx._source['nullField'] = 'description';}"
      },
      "properties": {
        "title": {
          "type": "string"
        },
        "description": {
          "type": "string"
        },
        "nullField": {
          "type": "string"
        }
      }
    }
  }
}

Notice that we script has changed, not only do we remove the description field, now we also add a new field called nullField. Check that the _source is still not changed. Now we do a search and only return the fields description and nullField. Before scrolling to the response think about the response that you would expect.

GET /transform/_search
{
  "query": {
    "match_all": {}
  },
  "fields": ["nullField","description"]
}

Did you really think about it? Try it out and notice that the nullField is not returned. That is because we did not store it in the index and it is not obtained from the source. So if we really need this value, we can store the nullField in the index and we are fine.

PUT /transform
{
  "mappings": {
    "simple": {
      "transform": {
        "lang":"groovy",
        "script":"if (ctx._source['description']?.equals('null')) {ctx._source['description'] = null;ctx._source['nullField'] = 'description';}"
      },
      "properties": {
        "title": {
          "type": "string"
        },
        "description": {
          "type": "string"
        },
        "nullField": {
          "type": "string",
          "store": "yes"
        }
      }
    }
  }
}

Than with the match all query for two fields we get the following response.

GET /transform/_search
{
  "query": {
    "match_all": {}
  },
  "fields": ["nullField","description"]
}
Response:
{
   "took": 2,
   "timed_out": false,
   "_shards": {
      "total": 1,
      "successful": 1,
      "failed": 0
   },
   "hits": {
      "total": 1,
      "max_score": 1,
      "hits": [
         {
            "_index": "transform",
            "_type": "simple",
            "_id": "1",
            "_score": 1,
            "fields": {
               "description": [
                  "null"
               ],
               "nullField": [
                  "description"
               ]
            }
         }
      ]
   }
}

Yes, now we do have the new field. That is it, but wait there is more you need to know. There is a way to check what is actually passed to the index for a certain document.

GET transform/simple/1?pretty&_source_transform
Result:
{
   "_index": "transform",
   "_type": "simple",
   "_id": "1",
   "_version": 1,
   "found": true,
   "_source": {
      "description": null,
      "nullField": "description",
      "title": "This is a document with text"
   }
}

Notice the null description and the nullField in the _source.

Final remark

You cannot update the transform part, think about what would happen to your index when some documents did pass the transform version 1 and others version 2.

I would be gentile with this feature, try to solve it before sending it to elasticsearch, but maybe you just have the usecase for this feature, now you know it exists.

In my next blogpost I dive a little bit deeper into the scripting module.

The post Transform the input before indexing in elasticsearch appeared first on Gridshore.

Categories: Architecture, Programming