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!
Software Development Blogs: Programming, Software Testing, Agile Project Management
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!
Proper Preparation Prevents Poor Performance
This simple phrase describes the core behavior of all project related work. For any platitude to survive contact with reality, it must be¬†true,¬†actionable, and¬†applicable¬†in your own domain.¬†
The notion that ‚Äúemergence‚ÄĚ is the driver for the participants in a project requires careful consideration. The technical or business requirements of the outcomes of the project are always ‚Äúemergent‚ÄĚ in some form. To be otherwise would require a preset group of activities, materials, technology, and personnel.
Failing to understand the subtleties of the continuous emergence of requirements, that enable the capabilities to be delivered, ¬†means failing to understand any project requires planning to deal with these emerging requirements. This emergence also pertains to the tools and processes used to manage and deliver the project. emergence is applicable to all elements.
Preparing for Emergence is a critical success factor in project work. Proper preparation is the foundation of programmatic and technical risk management. This means asking and answering the ‚Äúif ‚Äď than‚ÄĚ question, rather than the ‚Äúwhat ‚Äď if‚ÄĚ question.
Managing in the presence of emergence requires¬†directed decision making. Just letting things happen disconnects the outcomes of the project from the neeed capabilities produced by the project. These capabilities are the¬†immutable part of the business process. They can only change, when the strategy for the success of the business enabled by the project changes. To do otherwise, would be to disconnect between the investment in the project and the value produced by the project.
‚ÄúIf ‚Äď Than‚ÄĚ means knowing what can go wrong and how to respond to the following:
If¬†personal development never happens as planned, why bother?
There are many things wrong with performance appraisals, but one aspect that many authors and experts seem to overlook is the insane idea of ‚Äúmeasuring progress against a goal‚ÄĚ.
I‚Äôve been part of this nonsense myself.
We asked our employees (many years ago) to create Personal Development Plans, and craft personal goals that they would try to achieve before the end of the year
Requirements traceability has always been a special passion of mine.¬† The process saved my bacon at least once when I managed projects.¬† Agile methods have complicated how one approaches¬†the concept of traceability.¬† I do not¬†think it reduces the need but changes the¬†palette¬†of approaches.¬†¬†’Traceability:¬†¬†A Radical Approach Based on User Involvement’ ¬†is my approach to sorting out the ramifications of customer involvement, complexity and¬†criticality.¬† Your comments and thoughts are welcome as I try to sort this out.
Traceability is a core tenant of the requirements management process area in the CMMI.¬†¬†Why is the effort to ensure traceability worth the investment? While there are many uses and benefits, at its most fundamental, traceability allows projects to know that what was planned was installed and what was installed was planned.¬†¬†In one shape or another, the concept is hard to argue with; the problem is that ‚Äúdoing it‚ÄĚ is not very easy and construed to be expensive.¬†Many of the trappings of process discipline are viewed as overhead.¬†¬†Many of these items are concentrated on the side of controlling behavior.¬†¬†There is a need to create versions of tracking, planning and status reporting that meets the requirements of the model while facilitating work rather than slowing it down.¬†¬†When the CMMI is interjected into the process landscape traceability becomes a lightening rod for the overhead discussion.
Even when traceability meets the overall organizations needs, the perceived value of traceability depends on the individual groups involved.¬†¬†The burning question is whether (assuming a benefit really exists) that the benefits accrue to all groups involved equally?¬†¬†Is the effort equivalent to the value?¬†¬†Can the value proposition be scaled so that all projects all groups can derived more value than effort?¬†¬†Scalability has become even more a burning issue as IT groups have embraced Agile methodologies.¬†Traceability is a difficult concept to define for all types of projects and equally difficult concept to sell to all stakeholders in the world of projects.¬†¬†¬†‚ÄėTraceability:¬†¬†A Radical Approach Based on User Involvement‚Äô suggests an approach to scalability based on balancing user involvement, risk and control needs.¬†¬†This approach seeks to balance the effort required to trace requirements with the value of doing it.¬†¬†This approach makes traceability less of a lightening rod for process improvement and a salable concept.
A Proposed Model To Scale Traceability
The model scalability is driven by the evaluation of these common attributes:
The evaluation of customer involvement need to encompass not only quantity (how much they are available) as well as quality (are they correct kind, can they make decisions).
Questions I am posing include:
¬†Plans are nothing, Planning is Everything
The notion that plans are nothing but planning is everything is a common mis-applied quote. The clip art ¬†and content extracted from the current edition of Defense Acquisition Journal, November-December, 2013.
The ever-quotable Dwight D. Eisenhower, speaking to a group of industry executives who could be mobilized for war at a moment‚Äôs notice, was echoing an old adage¬†about warfare: ‚ÄúNo battle plan survives first contact with the enemy.‚ÄĚ
Eisenhower‚Äôs message, like the man himself, was straightforward: ‚ÄúThe reason it is so important to plan [is] to keep yourselves steeped in the character of the problem that you may one day be called upon to solve‚ÄĒor to help to solve.‚ÄĚ He was reminding them that warfare is inherently fluid, and that the only way to adjust to quickly changing circumstances is to have planned for such contingencies in advance.
For our project management domain, Plans are considered Strategies for the successful delievry of the project's capabilities. But this strategy is actually a hypothesis and this needs continual¬†testing. The best way of course if testing the hypothesis is working product at periodic points in the project. Some would say this test should be every few weeks. This of course - as always - is domain dependent. But at a minimum every month.
In our Earned Value Management domain, the montly Contract Performance Report (CPR), requires an assessment of physical percent complete to calculate the BCWP (Budgeted Cost of Work Performed). ¬†The planned cost of producing this value is BCWS (Budgeted Cost of Work Scheduled).
BCWP = BCWS x¬†Physical Percent Complete
On the planned day for the planned cost. Don't show up on the planned day for the planned cost and the planned physical percent complete? You can't be on schedule and on budget.
Now Add Technical Performance Measures and Quantified Backup Data
The determination of¬†Physical Percent Complete starts with Quantifiable Backup Data. Percent complete is never a¬†guess or an¬†opinion. Tangible evidence is needed. But tangible evidence against the planned percent complete, on the day we planned to be that percent complete. This is nearly identical to Agile's approach to delivering working software at the end of an iteration. Not quite, since agile allows you to drop planned deliverables without an penalty to the current performance measure. This¬†mortgaging the future by pushing undelivered features into the future would not be counted as complete in Earned Value.
My last Pluralsight course for this year is out!
I started out this year with the goal of creating 30 Pluralsight courses, this Beginning Lua course represents the completion of that goal.
It definitely feels great to accomplish what I had planned, even though the process may have been a bit painful at times. ¬†This is definitely the biggest single undertaking I’ve ever accomplished in my career.
Here is the official course description:
Lua is an extremely versatile and popular programming language that you‚Äôll find embedded in many other applications like Adobe‚Äôs Lightroom or even World of Warcraft. Many developers are surprised to find that even very popular games like Angry Birds are written in Lua.
In this course, you‚Äôll learn how to quickly get started writing programs and scripts with Lua. I‚Äôll take you through the basics of Lua, show you some tricks that demonstrate the Lua‚Äôs flexibility and even show you how to use Lua in an object oriented way.
We‚Äôll start off in this course by learning a bit about Lua itself and Lua‚Äôs history, as well as learn how to download Lua and use the popular SciTE IDE for creating and running Lua code.
After we are setup and ready to develop some Lua code, we‚Äôll learn the basics of Lua as we jump right in and build our first application. We‚Äôll go over Lua‚Äôs type system and learn how to assign variables, utilize operators, use conditional logic and create loops.
Once we‚Äôve got the basics covered, we‚Äôll explore two powerful concepts in Lua: functions and tables. We‚Äôll learn how functions work in Lua and what makes them so powerful, and we‚Äôll see how tables can be used for more than just storing simple data.
Even though Lua itself doesn‚Äôt have a class construct, we‚Äôll learn how to do object oriented programming in Lua using tables and metatables.
Finally, we‚Äôll wrap up the course by learning a little bit about the standard libraries that come with Lua. I‚Äôll show you some examples of using some of the most useful functions in the standard libraries and show you where you can get more information about them.
We hear all the time, pithy statements about teams, teaming, team building, enabling team that provide innovation, and most every¬†soft skill ever thought of, applied to managing projects. At the project below, where I was one of many program managers, we came to realize one fundamental truth about teams -¬†
If you have a team who is your opponent?
Having played team sports at the High School, College, and competitive adult level, our teams always played against an opposing team. Much of the team building platitudes seem to ignore that teams are formed to play ¬†other teams, score points, win games, overcome obstacles, and participate in competition.
Who is the¬†other team if we're on a project team?
See if the notions below resonant when you hear short, cleaver words about the role of teams on projects?
Making the impossible possible from Glen Alleman Related articles Agile Requires Discipline, In Fact Successful Projects Require Discipline Trust 5 Benefits Team-building Consultants Can Offer Your Business Competency Model For Project Managers
Four hours of driving seems like a colossal waste of time.
Last night I drove from Vienna (Austria) to Zagreb (Croatia). It wasn‚Äôt cheap. Apart from the cost of the rental car, the gas/petrol, the toll road, the Slovenian vignette (15 euros?! Geez, it‚Äôs a crime!), and the parking fee, it cost me 4 hours of driving
‚ÄúAll models¬†are wrong, but some are¬†useful.‚ÄĚ¬† This quote is attributed to George E. P. Box
Information Technology has many useful models for addressing the complexity of developing, delivering and running software.¬† Well known models include the Software Maturity Model Integrated (CMMI¬ģ), the Information Technology Infrastructure Library (ITIL¬ģ) and the Test Maturity Model Integration (TMMi¬ģ) to name a few.
Testing is a mechanism for affecting product quality.¬† The definition is of quality is varied ranging from precise (Crosby ‚Äď ‚ÄúConformance to requirements‚ÄĚ) to meta-physical (Juran ‚Äď ‚ÄúQuality is an attitude or state of mind‚ÄĚ).¬† Without a standard model of testing that codifies a definition, it is difficult to determine whether testing is affecting quality in a positive manner.¬† The TMMi is an independent test maturity model. It ¬†is a reference model representing an abstract framework of interlinked concepts based on the thoughts of experts and thought leaders. The Wikipedia definition suggests that reference model can be used as a communication vehicle for ideas and concepts among the members of the model‚Äôs community. The use of a model as a tool to define the boundaries of a community also amplifies its usefulness as a communication tool as it defines the language the community uses to describe itself. ¬†¬†The TMMi is a reference model of testing for the testing community defining the boundaries of testing, the language of testing and a path for process improvement and assessment.
Many developers (and development managers) think of testing as a group of activities that occur at the end of coding. This flies in the face of software engineering practice since the 1980s and the Agile tenant of integrating testing into the entire development process. The TMMi model explicitly details a framework in which testing is not an event or gate that has to be hurdled, but rather a set of activities that stretch across the development lifecycle (waterfall, iterative or Agile). A model provides a framework of the activities and processes that need to be addressed rather merely laying out a set of milestones or ¬†events that need to be followed explicitly. ¬†The TMMi model extends the boundary of testing to entire development process.
The TMMi model lays out a set five maturity levels and sixteen process areas ranging from test environment to defect prevention.¬† The model is has a similar feel to the classic CMMI model. Since the model provides a set of definitions and a language to talk about testing and how it integrates into development, the model provides the mechanism for members of the testing community to communicate more effectively.
The TMMi, through its framework of maturity levels, process areas, practices and sub-practices, lays out best practices for testing that should be considered when developing testing practices.¬† Like other reference models, the TMMi provides a framework but does not prescribe how any project or organization should ‚Äúdo‚ÄĚ any of the practices or sub-practices.¬† By not prescribing how practices are to be implemented, the TMMi can be used in any organization that includes testing.¬† A framework that is neutral to lean, Agile or waterfall practices that points that communicates best practices provides a tool to identify and pursue process improvement is a tool that can be molded by managers and practitioners to make testing more efficient
The first question is¬†who pays for people learning from their mistakes? Then the next question -¬†with these mistakes, did the project advance in ways it would not have before we made the mistake?¬†
And did the money we spent learning from our mistake "earn its value?"¬†Or put in another way¬†was there a better use of the money to advance our learning other than building something that we considered a mistake?
There are other questions as well.¬†Why didn't we know this was going to be a mistake before we started? Or¬†could we have known this before we discovered it failed? Or even better,¬†was the failure we just experienced knowable at all?
This knowability question is the key to all project planning processes. If something is not knowable, then we could not have known, so we only discover our mistake after the fact. If it was knowable and we choose not to address it - ignore the potential problem - then we'll overrun our plan for no good reason other than we choose to ignore the knowable facts.
We may have a knowable issue, but can't afford to¬†learn (pay money to learn), but that's different.
These questions and others need to be asked and answered before we can make any assessment if¬†learning from our mistakes is a good idea. The alternative to¬†learning from our mistakes is to¬†do the job right the first time.
This of course is overstating the solution and somewhat silly, but it brings out a critical concept that must be addressed in any credible management process of spending other peoples money...
Who pays for the development team to discover their mistakes, if these mistakes could be avoided?
Once we have the answer to that question, we now have some decisions to make.
This is all fancy words for¬†someone has to pay for us to learn what we don't currently know. And we need to make the cost of this learning visible as soon as possible if we're going to be good stweards of other peoples money.
So What's the Point?
The notion of¬†Hiring smart people is pointless if they aren't allowed to make any mistakes¬†ignores the managerial finance obligation to determine who pays for these mistakes, is the budget for making these mistakes in the baseline authorization, and if not, are we going to overrun our planned cost for the project and dilute the Return on Investment calculation¬†that we sold to the owner of the project?
We seem to forget that writing software for money, means spending other peoples money for the expected amount of money (within the variance bounds) and showing up on or before some expected time (within the varaince bounds), with more or less the expected capabilities.¬†
This is a¬†Prime Directive (to borrow a phrase) for all projects. It's very doubtful the owner of the money says to us¬†hey boys and girls, go out there and experiment around to figure out what will work and what won't work without actually budgeting for that¬†experimenting work.
When there is explicit budget to¬†experiment that's called¬†explicit work for discovering what we dont' know, that is needed before we can proceed. We'd find that budgeted work in our plan for the project. No problem, all part of the normal project management process.
But the notion of¬†Hiring smart people is pointless if they aren't allowed to make any mistakes¬†needs to address¬†Who, What, When, Where, Why, and¬†How this discovery process is going to get paid for FIRST, then we can start¬†failing on purpose to make the follow on work better.
Bazaarvoice is a company that people interact with on a regular basis but have probably never heard of. If you read customer reviews on sites like bestbuy.com, nike.com, or walmart.com, you are using Bazaarvoice services. These sites, along with thousands of others, rely on Bazaarvoice to supply the software and technology to collect and display user conversations about products and services. All of this means that Bazaarvoice processes a lot of sentiment data on most of the products we all use daily.Bazaarvoice helps our clients make better products by using a combination of machine learning and natural language processing to extract useful information and user sentiments from the millions of free-text reviews that go through our platform. This data gets boiled down into reports that clients can use to improve their products and services. We are also starting to look at how to show personalized sortings of reviews that speak to what we think customers care about the most. A mother browsing for cars, for example, may prefer to read reviews about safety features as compared to a 20-something male, who might want to know about the car’s performance. As more companies use Bazaarvoice technology, consumers become more informed and make better buying decisions.
Here's how it works...
I often get asked by beginner programmers what programming language they should learn.
This, of course, is a tough question to answer. There are so many different programming languages today that a new developer, or even a seasoned developer, wishing to retool his or her career, could learn.
I’ve actually tried to answer this question before in a YouTube video, but I want to revise and refine my answer a bit here, because some of my views have changed and I’d like to give a bit more detail as well.
The wrong question to begin with
It turns out that what programming language you choose to learn is not actually all that important
Things have changed quite a bit from back when I first started my career in software development. Back when I first started out, there were much fewer choices of programming languages and there were much fewer resources available for reference. As a result, the choice was much more important.
For example, I started out learning C and then C++. At that time, it took quite a bit of work to master the language itself and to understand all of the standard libraries that were available. A good C or C++ programmer back then had a very in-depth understanding of every nook and cranny of the language and they needed this knowledge, because of two main reasons.
Contrast that with the programming environment of today, where not only is information widely available and can be accessed with ease, but also there are a large number of programming languages that we effectively use to program at a much higher level due to the vast amount of libraries and reusable components available to us today.
In today’s programming environment, you tend to not need to dive as deeply into a language to be effective with it. Sure, you can still become an expert in a particular programming language, and it is good to have some amount of depth in at least one language, but you can literally learn a new language in less than a week and be effective with it almost immediately.
Now, before your alarm bells go off and you write me off as crazy, let me explain that last sentence in a bit more detail.What do you mean you can learn a programming language in a week?
What I mean by this is that once you understand the basic programming constructs available in just about all programming languages, things like conditionals, loops and how to use variables and methods, you can take that same knowledge to a different programming language and just learn how to do those same things in that language’s syntax. In fact, most IDEs today will even help you with the syntax part, making your job even easier.
If you are already fluent in multiple programming languages, you probably agree with what I am saying, but if you have only ever learned one programming language or none at all and are looking to learn your first programming language, you might be a little skeptical. But, take it from someone who has learned and taught programming languages which I have learned in a week, the basics are pretty much the same.
Check out this book which basically deals with this exact subject, Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programming Languages.
Now, if you are just starting out, it is pretty unlikely you’ll be able to learn a whole programming language in a week. This brings us to the question, you may be asking yourself‚Ä¶So, what programming language should I learn then?
Hold up. I’m still not quite going to answer that question. Because, it still isn’t quite the right question.
Instead of getting hung up on what programming language you want to learn, you should instead ponder what you want to do.
Learning by doing is the most effective way to learn, especially if you are doing something you have an interest in or is fun to you.
So, I always start new want-to-be developer out by asking them what they want to build.
Do you want to build an Android application? How about an iOS application? A web page? A game?
First, figure out the answer to this question and then let that answer guide you to choose the technology and programming language you will use to achieve that goal.
Don’t worry so much about which programming language or technology is most valuable. You can’t make a wrong decision and regret it later, because it won’t take you much time to retool later if you need to. Once you have the basics down and have actually used a programming language to build something, you’ll find that doing it again will be much easier.
I like to encourage new developers to write a mobile application‚ÄĒespecially an Android application.
Here are some reasons why:
No, not exactly.
I’m actually working on some products to help developers manage their careers and lives better which will cover topics like this one a bit more in-depth. If you are interested in receiving some updates when I publish an interesting article or video, or when I launch some of those products, feel free to sign up here. Don’t worry, I won’t spam you. J
But let's start with a fundamental principle of all business, not matter the domain. If we expect to generate revenue or produce some measurable value from our work efforts, we need to measure those beneficial outcomes in some agreed upon units.¬†
Dollars is one unit of measures common in the business world. If we work are a¬†for profit company, it is likely the managers of the business use that unit when they discuss project work. If we work for the government, budget is used many times in place of cost, but cost - in dollars - is still in the equation. If we work for a non-profit or a not-for-profit budget and cost are half the equation. Intangible benefits the other half.¬†
But it is unlikely any place we work, there is not some discussion of cost, budget, or expenses. So no matter what our personal opinion creating estimates of our work effort are, we can't escape the fundamentals of business.¬†
We need to know the cost of something before we can assign a value
Let's look at some deep¬†truths about estimating
So The Big Question?
These issues are not unique to software development. They are found in every project domain. Public works, bio-pharma, energy, government contracting.¬†
Estimating is hard, it's important, and needs to be addressed in much more detail, before being dismissed as simply something management wants.
I've been working with a number of teams recently, helping them to diagram their software systems using the C4 approach that is described in my Software Architecture for Developers book. To summarise, it's a way to visualise the static structure of a software system using a small number of simple diagrams as follows:
In the real-world, software systems never live in isolation and it's often useful to understand how all of the various software systems fit together within the bounds of an enterprise. To do this, I'll simply add another diagram that sits on top of the C4 diagrams, to show the enterprise context from an IT perspective. This usually includes:
Essentially this becomes a high-level map of the software systems at the enterprise level, with a C4 drill-down for each software system of interest. Caveat time. I do appreciate that enterprise architecture isn't simply about technology but, in my experience, many organisations don't have an enterprise architecture view of their IT landscape. In fact, it shocks me how often I come across organisations of all sizes that lack such a holistic view, especially considering IT is usually a key part of the way they implement business processes and service customers. Sketching out the enterprise context from a technology perspective at least provides a way to think outside of the typical silos that form around IT systems.