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

Get Up And Code 048: Brian Lagunas: XAML and Oats

Making the Complex Simple - John Sonmez - Sat, 04/05/2014 - 15:00

In this episode, I got to talk to my hometown buddy, Brian Lagunas. Brian is a Program Manager for Infragistics and a former bodybuilder. In this episode, I talk to Brian about his new fitness goals and how he is gaining muscle by eating clean. Full transcript below: show John:               Hey everyone, welcome back to […]

The post Get Up And Code 048: Brian Lagunas: XAML and Oats appeared first on Simple Programmer.

Categories: Programming

Case for VB.Net vNext

Phil Trelford's Array - Sat, 04/05/2014 - 11:50

Following up on the last Roslyn preview way back in 2012, this week saw the availability of a new preview with a more complete compiler along with a few new language features for C# and VB. A lot of inspiration for these features seems to have come from the F# language.

The C# interactive shell from 2012 appears to be missing, perhaps ScriptCS is expected to fill this space, or you could just use F# interactive which already exists in Visual Studio.

On the language features side, C# 6 gets primary constructors for classes, heavily inspired by F#, and using static which brings parity with Java and VB.Net.

For me VB.Net gets the most interesting new feature in the form of Select Case TypeOf. which provides the first steps towards pattern matching.


Taking a hierarchy of shapes as an example:

Public MustInherit Class Shape
End Class

Public Class Rectangle
    Inherits Shape
    Public Property Width As Integer
    Public Property Height As Integer
End Class

Public Class Circle
    Inherits Shape
    Public Property Radius As Integer
End Class

Sub Main()
    Dim shape As Shape = New Rectangle With {.Width = 10, .Height = 10}
    Select Case shape
        Case r As Rectangle When r.Width = r.Height
            Console.WriteLine("Square of {0}", r.Width)
        Case r As Rectangle
            Console.WriteLine("Rectangle of {0},{1}", r.Width, r.Height)
        Case c As Circle
            Console.WriteLine("Circle of {0}", c.Radius)
    End Select
End Sub

The functionality is still quite limited and quite verbose in comparison to say F# or Scala, but I feel it’s definitely an interesting development for VB.Net.

For comparison here’s an equivalent F# version using discriminated unions:

type Shape =
    | Rectangle of width:int * height:int
    | Circle of radius:int

let shape = Rectangle(10,10)
match shape with
| Rectangle(w,h) when w=h -> printfn "Square %d" w
| Rectangle(w,h) -> printfn "Rectangle %d, %d" w h
| Circle(r) -> printfn "Circle %d" r


Pattern matching can be really useful when writing compilers, here’s a simple expression tree evaluator in F#:

type Expression =
   | Factor of value:int
   | Add of lhs:Expression * rhs:Expression

let rec eval e =
   match e with
   | Factor(x) -> x
   | Add(l,r) -> eval l + eval r

let onePlusOne = Add(Factor(1),Factor(1))

VB.Net vNext can approximate this, albeit in a rather more verbose way:

Public MustInherit Class Expression
End Class

Public Class Factor
    Inherits Expression
    Public Property Value As Integer
    Sub New(x As Integer)
        Value = x
    End Sub
End Class

Public Class Op
    Inherits Expression
    Public Property Lhs As Expression
    Public Property Rhs As Expression
End Class

Public Class Add
    Inherits Op
End Class

Function Eval(e As Expression) As Integer
    Select Case e
        Case x As Factor
            Return x.Value
        Case op As Add
            Return Eval(op.Lhs) + Eval(op.Rhs)
        Case Else
            Throw New InvalidOperationException
    End Select
End Function

Sub Main()
    Dim onePlusOne As Expression =
        New Add With {.Lhs = New Factor(1), .Rhs = New Factor(1)}
End Sub


It will be interesting to see how VB.Net vNext develops. I think first-class support for tuples could be an interesting next step for the language.

Categories: Programming

Testing First Really Is Different Than Testing Last

There really is a difference  . . .

There really is a difference . . .

Classic software development techniques follow a pattern of analysis, design, coding and testing. Regardless of whether the process is driven by a big upfront design or incremental design decisions, code is written and then tests are executed for the first time. Test plans, scenarios and cases may well be developed in parallel with code (generally only with a minimum of interaction), however execution only occurs as code is completed. In test-last models, the roles of developer and tester are typically filled by professionals with very different types of training and many times from separate management structures. The differences in training and management structure create structural communication problems. At best the developers and testers are viewed as separate but equal, although rarely do you see testers and developers sharing tables at lunch.

Testing last supports a sort of two tiered development environment apartheid in which testers and developers are kept apart. I have heard it argued that anyone that learned to write code in school has been taught how to test the work they have create, at least in a rudimentary manner, therefore they should be able to write the test cases needed to implement test-driven development (TDD). When the code is thrown over the wall to the testers, the test cases may or may not be reused to build regression suites. Testers have to interpret both the requirements and implementation approaches based on point in time reviews and documentation.

Test-first development techniques take a different approach, and therefore require a different culture. The common follow of a test first process is:

  • The developer accepts a unit of work and immediately writes a set of tests that will prove that the unit of work actually functions correctly.
  • Run the tests.  The tests should fail.
  • Write the code need to solve the problem.  Write just enough code to really solve the problem.
  • Run the test suite again.  The test should pass.

Most adherents of Agile development methods have heard of TDD which is the most common instantiation of the broader school of test-first development (TFD).  TDD extends TFD by adding a final refactoring step to the flow in which developers write the tests cases needed to prove that unit of work solves the business problem and is technically correct. Other variants, such as behavior-driven and acceptance test-driven development, are common.  In all cases the process follows the same cycle of writing tests, running the tests, writing the code, re-running the tests and then  refactoring the only difference being the focus tests.

TFD techniques intermingle coding and testing disciplines, creating a codependent chimera in which neither technique can exist without the other. For TFD to work most effectively coders and testers must understand each other and be able to work together. Pairing testers and developers together to write the test case either for component/unit testing (TDD), behavior-driven tests (BDD) or acceptance testing (ATDD) creates an environment of collaboration and communication.  Walls between the two groups will be weak, and over time, torn down.

Test-first development and test-last development techniques are different both in terms of the how work is performed and how teams are organized. TFD takes a collaborative approach to delivering value, while test-last approaches are far more adversarial in nature.

Categories: Process Management

Stuff The Internet Says On Scalability For April 4th, 2014

Hey, it's HighScalability time:

The world ends not with a bang, but with 1 exaFLOP of bitcoin whimpers.
  • Quotable Quotes:
    • @EtienneRoy: Algorithm:  you must encode and leverage your ignorance, not only your knowledge #hadoopsummit - enthralling
    • Chris Brenny: A material is nothing without a process. While the constituent formulation imbues the final product with fundamental properties, the bridge between material and function has a dramatic effect on its perception and use.
    • @gallifreyan: Using AWS c1, m1, m2? @adrianco says don't. c3, m3, r3 are now better and cheaper. #cloudconnect #ccevent
    • @christianhern: Mobile banking in the UK: 1,800 transactions per MINUTE. A "seismic shift" that banks were unprepared for

  • While we are waiting for that epic article deeply comparing Google's Cloud with AWS, we have Adrian Cockcroft's highly hopped slide comparing the two. Google: no enterprise customers, no reservation options, need more regions and zones, need lower inter-zone latency, no SSD options. AWS: no per minute billing, need simpler discount options, need more regions and zones, no real PaaS strategy, not instance migration.
  • Technology has change us from a demo or die culture to a deploy or die culture. We see this in software, but it's happening in hardware too says, Joi Ito (MIT Media Lab), in this interview.
  • The Curmudgeon of Truth declares I reckon your message broker might be a bad idea: Engineering in practice is not a series of easy choices, but a series of tradeoffs. Brokers aren’t bad, but the tradeoffs you’re making might not be in your favour." < Good discussion on Hacker News.
  • High phive this. Your application may already achieved a degree of consciousness. An information integration theory of consciousness: consciousness corresponds to the capacity of a system to integrate information.
  • People really really like to talk. Line, a messaging app that's big in Japansurpasses 400 Million Registered Users, 10 billion chat messages per day, 1.8 billion stickers per day, and over 12 million calls per day.

Don't miss all that the Internet has to say on Scalability, click below and become eventually consistent with all scalability knowledge...

Categories: Architecture

Enterprise WinRT Apps Build Roundup

DevHawk - Harry Pierson - Fri, 04/04/2014 - 16:40

Wow, it’s been a whirlwind couple of days down here in San Francisco @ Build 2014. It has certainly been a huge thrill for me, getting a chance to be a part of the day one keynote and getting 15 minutes of fame. However, as the conference winds down I wanted to pull together a summary of the stuff Microsoft announced that relates to enterprise app development and Windows 8.1 Update. I mean, it wasn’t all about my wardrobe choices…

The Windows for Business blog as a good summary post that hits the highlights. The stuff I wanted to specifically call out is:

  • We’ve changed the policy to allow side loaded apps to communicate with desktop apps. Literally every single enterprise customer, Microsoft dev consultant and enterprise technical sales rep I’ve spoken to in the last year has asked for this.
  • We’ve added a feature in Windows 8.1 Update to enable side loaded apps to run code outside of the App Container. This opens up side loaded apps to access the full power of Windows as well as all the existing code the enterprise may have in its portfolio
  • We’ve made it significantly easier to get side load rights. I’d go thru the specifics here, but Rocky Lhotka (who has been *very* vocal about the issues in this space) had a great summary: “For a maximum of around $100 virtually every organization (small to huge) can get a side loading unlock key for all their devices.”

If you want more information on how to take advantage of these new features for side loaded apps, here are some resources for you:

  • In addition to my 5 minutes in the keynote, I did a whole session where I drilled into more details on that demo. I also demos that used network loopback for interprocess communication.
  • John Vintzel and Cliff Strom had a session on deploying enterprise apps. As of this writing, the video isn’t online yet but it will be within a day or two at that URL.
  • We have published whitepapers on both Brokered WinRT Components and using network loopback in WinRT apps that go into more details on how to build solutions with this technology
  • Last but not least, we have a set of samples of sideloaded WinRT apps. This includes the keynote demo, another brokered component demo and the WCF & ASP.NET network loopback demos I did in my session. Note, the keynote demo sample is packaged oddly because of the way MSDN’s sample repo handles (or in this case doesn’t handle) VS solutions with multiple projects. When I get back to Redmond, I’m  going to see if there’s a better way to get this sample hosted.

I heard many times over the past two days from folks in person at the conference and via email, twitter, facebook, carrier pigeon, etc just how excited they are about these changes & features. As an engineer who spends most of his days in his office and or in meetings building this stuff, it is amazingly gratifying to hear directly from our users how much our work can help them.

Categories: Architecture, Programming

Do It Right or Do It Twice

Herding Cats - Glen Alleman - Fri, 04/04/2014 - 15:23

Screen Shot 2014-04-03 at 10.47.18 AMI heard this phrase in a conference call yesterday with a DOD client and thought, how clever I'll write a blog about this. Only to find out there is a Forbes article with same name and several other articles as well. 

The Forbes article had a case study about doing it right around a business process. It was the perfect framework (repeated here) for applying Performance-Based Project Management® 

In the Forbes article there are five steps:

  1. The Vision Meeting - develop a set of needed capabilities for the outcome of the project. These provide the ability for the business to do something of value. There is all this discussion around creating value, but rarely are the units of measure for value mentioned.
    • Value cannot exist if we don't know both the units of measure of the value itself and the cost to deliver those units of measure. This is where the naive and ill informed notion of #NoEstimates and the phrase we are exploring for ways to make decisions with "No Estimates" goes right in the ditch.
    • The analysis of alternatives is a starting point. Balanced Scorecard is a broader approach, but AoA will work for this post. If we have some idea about what capabilities we need to possess, then we can make decisions about them. What do they cost? How do they actually provide value to our business or mission.
    • What are the units of measure of that value. One good unit of measures is effectiveness. How effective will this new capability be in solving our problem?
  2. Build a strategy - what is the Plan to deliver the needed capabilities. The notion that we don't need to plan - we'll let the resulting capabilities and their technical and operational requirements emerge - is of course going to allow us to Do It Twice.
    • We need to know what DONE looks like in units of measure meaningful to the decision makers. The Plan is not the schedule. The Plan describes what will be delivered.
    • The schedule shows when it is needed to deliver the value. We need both. 
  3. Adapt if necessary - the needed capabilities should pretty much be fixed. If not we're wasting time and money exploring for what DONE looks like.
    • That's called Research. No problem, if we acknowledge we are on a research project. If the customer thinks - and has paid us - we're on a development and delivery project, there's going to be disappointment when we discover we've spent a bunch of money exploring when we should have been delivering.
    • When I here about projects where the customer doesn't know what they want yet, so let's get started and we'll discover along the way. Go back to the office and get a bigger check book.
  4. Execute in time boxes - time boxing, rolling waves, incremental, iterative execution and delivery are  common sense. No one knows enough about anything at the detail level to know how to build it far into the future.
    • The Capabilities shouldn't be changing, but the mechanism for delivering these capabilities must be flexible and adaptable. The key outcome from executing in time boxes, is the answer to the question - how long are you willing to wait before you find out you are late? The answer must be, short enough to take corrective action to NOT be late. This time interval is domain and project dependent. But answering this question will define your business rhythm.
  5. What are we working on now? What are we working on next? - make this visible. Have a plan of the month, a plan of the week, a plan for this quarter.
    • Have everyone on the project acknowledge they know what the outcomes of this plan are in units of performance, technical performance measures, and the quantifiable backup data showing physical percent complete.
    • We must measure progress in this manner. This is the notion in agile software of working software. But the agile community doesn't have a formal way of stating the units of measure of working. They leave that up to the customer, who may not know. The Systems Engineering paradigm does, through Measures of Effectiveness, Measures of Performance, and Technical Performance Measures.
    • Create a framework based on these, and only then insert your favorite agile development processes.

In the end project success is about knowing what done looks like, knowing how to get there, how to measure progress along the way. And of course knowing impediments to progress and handling them. These concepts are instantiated in two papers from a colleague Pat Barker, What is Your Estimate at Complete and Program Master Scehdule Can Improve Results, on page 20.

Not Sure Where We Are

Categories: Project Management

Business Analyst Tip: CIOs are People, Too

Software Requirements Blog - - Fri, 04/04/2014 - 12:38
Like most of us, I’m working in an environment where there is too much to do and not enough people to do it. We recently received a request for a new project which didn’t make sense to me—it would only be used short-term and the need met by the project was already satisfied. So, I […]

Business Analyst Tip: CIOs are People, Too is a post from:

Categories: Requirements

Doing The Right Thing Right


Being on time is one aspect of ethical behavior

Ethics are the moral principles that govern behavior.  The principles that underlie ethics help us judge what is right or wrong. Team members on a project team are presented with a nearly continuous stream of choices to test their principles. Over the years I have seen choices that were clearly unethical, some that might be in a gray area and the majority have been ethical or at least neutral. An example of a clearly unethical decision was when a project showed a project as having a green status when it was clear that it was in deep trouble. I was recently asked why not unit testing code when the organizations standard process called for it to be unit tested was an ethical issue rather than just a failure to follow best practices. Unit testing is an expected behavior for most coders. There are at least two reasons this behavior is an ethical issue. The first is when a developer does not unit test the code they have written they are making someone else responsible for finding their mistakes. The second reason is because unit testing is the expected behavior in their methodology (and 99.9% of the coding methods I am aware of).

Here are four general attributes of ethical behavior:

  1. Reliability: A person’s actions should match the behavior they have committed to follow. Many organizations spend substantial time and effort defining techniques and methods with policies to ensure they are followed.  Deciding not to follow the standard process is generally not ethical behavior. In our unit testing example, most methodologies specifically call for developers to unit test their code. When a coder doesn’t unit test they are damaging their reliability. They can no longer be trusted to behave as expected by others following the process.
  2. Responsibility:  Responsibility is about the duty to deal with your actions. In our unit testing example, not unit testing makes someone else responsible for finding and removing your mistakes.
  3. Respectfulness:  Team members must be aware and have regard for the feelings of those around them. Respectful does not mean avoiding tough decisions or conversations, but rather being aware of how deeds, actions and words affect those you and doing your best to help deal with those effects. Making someone else clean up your code is not respectful to the next developer or tester.
  4. Fairness: Actions and decisions need to be objective, evenhanded and consistent. Not following a mandated or agreed upon process does not represent  consistent  behavior.

Why do these four attributes matter when discussing ethics of project team members? It can be boiled down to reputation. In most Agile teams, being able to be counted on to do the right thing is essential for long-run influence.  Self-organizing and self-managing teams which are core feature of Agile need team members to perform within ethical boundaries and to be able to influence each other to do the right thing and to do the right thing right.

Categories: Process Management


Phil Trelford's Array - Thu, 04/03/2014 - 18:28

Microsoft’s Build 2014 conference is currently in full flow, one of the new products announced is Orleans, an Actor framework with a focus on Azure.

There’s an MSDN blog article with some details, apparently it was used on Halo 4.

Demis Bellot of ServiceStack fame, tweeted his reaction:

.NET's actor model uses static factories, RPC Interfaces and code-gen client proxies for comms, WCF all over again:

— Demis Bellot (@demisbellot) April 3, 2014

I retweeted, as it wasn’t far off my initial impression and the next thing I know my phone is going crazy with replies and opinions from the .Net community and Microsoft employees. From what I can make out the .Net peeps weren’t overly impressed, and the Microsoft peeps weren’t overly impressed that they weren’t overly impressed.

So what’s the deal.


Erlang has distributed actors via OTP, this is the technology behind WhatsApp, recently acquired for $19BN!

The JVM has the ever popular Akka which is based heavily on Erlang and OTP.

An industrial strength distributed actor model for .Net should be a good thing. In fact Microsoft are currently also working on another actor framework called ActorFX,

The .Net open source community have projects in the pipeline too including:

There’s also in-memory .Net actor implementations with F#’s MailboxProcessor and TPL Dataflow. Not to mention the departed Axum and Retlang projects.


From what I can tell, Orleans appears to be focused on Azure, making use of it’s proprietary APIs, so there's probably still a big space for the community's open source projects to fill.

Like Demis I’m not a huge fan of WCF XML configuration and code generation. From the Orleans MSDN post, XML and code-gen seem to be front and centre.

You write an interface, derive from an interface, add attributes and then implement methods, which must return Task<T>. Then you do some XML configuration and Orleans does some code generation magic for hydration/dehydration of your objects (called grains).

Smells like teen spirit WCF, that is methods are king, although clearly I could be reading it wrong.

From my limited experience with actors in F# and Erlang, messages and message passing are king, with pattern matching baked into the languages to make things seamless.

Initial impressions are that Orleans is a long way from Erlang Kansas…

The Good Parts

Building a fault-tolerant enterprise distributed actor model for .Net is significant, and could keep people on the platform where they may have turned with Erik Meijer to the JVM, Scala and Akka otherwise.

Putting async front and centre is also significant as it simplifies the programming model.

C# 5’s async is based on F#’s asynchronous workflows, which was originally developed to support actors via the MailBoxProcessor.


Underneath, Erlang’s processes, F#’s async workflows and C#’s async/await are simply implementations of coroutines.

Coroutines are subroutines that allow multiple entry points for suspending and resuming execution at certain locations. They’ve been used in video games for as long as I can remember (which only goes back as far as the 80s).

Coroutines help make light work of implementing state machines and workflows.


In Erlang messages are typically described as named tuples (an atom is used as the name), and in F# discriminated unions are typically employed.

Orleans appears to use methods as the message type, where the method name is analogous to an Erlang atom name, or an F# union case name and the parameters are analogous to a tuple. So far so good.

Where they differ is that return values are first-class for methods, and return values feel more like an RPC approach. In fact this is the example given in the article:

public class HelloGrain : Orleans.GrainBase, IHello
  Task<string> IHello.SayHelloAsync(string greeting)
    return Task.FromResult("You said: '" + greeting + "', I say: Hello!");

Also current wisdom for C# async is to avoid async void... which is why I guess they’ve plumped for Task as the convention for methods with no return value.


.Net’s built-in binary serialization is bottom of the league for size and performance, hopefully alternative serialization libraries like Google Protocol Buffers will be supported.

Judge for yourself

But these are just my initial impressions, try out the samples and judge for yourself.

Categories: Programming

Leslie Lamport to Programmers: You're Doing it Wrong

Famous computer scientist Leslie Lamport is definitely not a worse is better kind of guy. In Computation and State Machines he wants to make the case that to get better programs we need to teach programmers to think better. And programmers will think better when they learn to think in terms of concepts firmly grounded in the language of mathematics.

I was disappointed that there was so much English in the paper. Surely it would have been more convincing if it was written as a mathematical proof. Or would it?

This whole topic has been argued extensively throughout thousands of years of philosophy. Mathematics has always been a strange attractor for those trying to escape a flawed human rationality. In the end as alluring as the utopia of mathematics is, it lacks a coherent theory of meaning and programming is not about rearranging ungrounded symbols, it's about manipulating and shaping meaning.

For programmers I think Ludwig Wittgenstein has the right sense of things. Meaning is derived by use within a community. Programs built and maintained by programmers is at bottom a community of effort.


For quite a while, I’ve been disturbed by the emphasis on language in computer science. One result of that emphasis is programmers who are C++ experts but can’t write programs that do what they’re supposed to. The typical computer science response is that programmers need to use the right programming/specification/development language instead of/in addition to C++. The typical industrial response is to provide the programmer with better debugging tools, on the theory that we can obtain good programs by putting a monkey at a keyboard and automatically finding the errors in its code.

I believe that the best way to get better programs is to teach programmers how to think better. Thinking is not the ability to manipulate language; it’s the ability to manipulate concepts. Computer science should be about concepts, not languages. But how does one teach concepts without getting distracted by the language in which those concepts are expressed? My answer is to use the same language as every other branch of science and engineering—namely, mathematics. But how should that be done in practice? This note represents a small step towards an answer. It doesn’t discuss how to teach computer science; it simply addresses the preliminary question of what is computation. 

Related Articles
Categories: Architecture

Who Solves Which Problems?

Many years ago, I was part of a task force to “standardize” project management at an organization. I suggested we gather some data to see what kinds of projects the client had.

They had short projects, where it was clear what they had to do: 1-3 week projects where 2-4 people could run with the requirements and finish them. They had some of what they called “medium-risk, medium return” projects, where a team or two of people needed anywhere from 3-9 months to work on features that were pretty well defined. But they still needed product managers to keep working with the teams. And, they had the “oh-my-goodness, bet the company” projects and programs. Sometimes, they started with a small team of 2-5 people to do a proof-of-concept for these projects/programs. Then, they staffed those projects or programs with almost everyone. (BTW, this is one of the reasons I wrote Manage It! Your Guide to Modern, Pragmatic Project Management. Because one size approach to each project does not fit all!)

The management team wanted us, the task force, to standardize on one project management approach.

In the face of the data, they relented and agreed it didn’t make sense to standardize.

It made a little sense to have some guidelines for some project governance, although I didn’t buy that. I’ve always preferred deliverable-based milestones and iterative planning. When you do that, when you see project progress in the form of demos and deliverables, you don’t need as much governance.

There are some things that might make sense for a team to standardize on—those are often called team norms. I’m all in favor of team norms. They include what “done” means. I bet you’re in favor of them, too!

But, when someone else tells you what a standard for your work has to be? How does that feel to you?

I don’t mind constraints. Many of us live with schedule constraints. We live with budget constraints. We live with release criteria. In regulated industries, we have a whole set of regulatory constraints. No problem. But how to do the work? I’m in favor of the teams deciding how to do their own work.

That’s the topic of this month’s management myth, Management Myth 28: I Can Standardize How Other People Work.

If you think you should tell other people how to do their work, ask yourself why. What problem are you trying to solve? Is there another way you could solve that problem? What outcome do you desire?

In general, it’s a really good idea for the people who have the problem to solve the problem. As long as they know it’s a problem.

How about you tell the team the outcome you desire, and you let them decide how to do their work?

Categories: Project Management

How To Get Started Programming

Making the Complex Simple - John Sonmez - Thu, 04/03/2014 - 16:00

Breaking into the software development industry can be rather difficult. It is dfficult to get a job without experience and it is difficult to get experience without a job. In this video, I talk about how you can get started learning to program and then how you can actually land that first job. Full transcript: […]

The post How To Get Started Programming appeared first on Simple Programmer.

Categories: Programming

Agile as a Systems Engineering Paradigm

Herding Cats - Glen Alleman - Thu, 04/03/2014 - 15:41

In yesterday's post, the notion of Systems Engineering was suggested as one solutuion to project failure. Here's the next step. The Agile notion started with a manifesto that turned into many interpretations and practices. In the standard project management paradigm, there is a set of principles, practices, and processes described in a variety of ways through several organizations. ITIL, PMI, APM, DOD, DOE, and other owners of project management activities.

When we take the Systems Engineering approach, we can put a wrapper around ALL project management, technical development, and deployment processes, that can be use to assess each practice and process to assure it is providing value. Here's a short overview of this paradigm. 

Agile project management is systems management from Glen Alleman The frameworks for Systems Engineering starts with several guides
  • ISO 15288
  • INCOSE Systems Engineering Handbook
  • FAA Systems Engineering 
Categories: Project Management

Welcoming Changing Requirements

Software Requirements Blog - - Thu, 04/03/2014 - 12:35
The Agile Manifesto is based on twelve principles (I’ve highlighted a couple – 2 and 12 – that are of the most interest for this post): Customer satisfaction by rapid delivery of useful software Welcome changing requirements, even late in development Working software is delivered frequently (weeks rather than months) Working software is the principal […]

Welcoming Changing Requirements is a post from:

Categories: Requirements

Another Learning Style Model


Every team member has a different learning style that has to be synced.

Every team member has a different learning style that has to be synced.

Another learning style model is built on four dimensions of learning styles. The dimensions of the Index of Learning Styles developed by Dr Richard Felder and Barbara Soloman are each described as a continuum.  Each continuum is bounded by opposite attributes of a learning style. An individual could map him or herself on each of the continuum to generate rich understand of their learning style. They are summarized below:


Mature teams generally are comprised of mix of learning styles. A mixture of styles can be complementary. For example, many IT groups I have worked with have at least one big picture person and several more linear learners.  What I generally do not see are individuals that sit at the extremes of any of the dichotomies. Individuals that sit at an extreme tend to be more difficult to draw into the group which impacts the ability to communicate and the ability of team members to trust each other.

One use of this type of model is to map teams.  For example, if we use the example used in Learning Styles and Communication Problems in a mapping exercise, I would judge the three personalities Lawyer (L), Talker (T) and Diagrammer (D) to fall as below:


The mapping exercise can be used to flag extremes that might cause trouble for the team. As noted in the example, the overall team was having issues staying focused when the Lawyer was presenting due to the sequential style being used. Using a mapping approach early in formation of the team can provide the coach with the impetuous for training exercises to sensitize the team to the disparate learning styles.

I suggest doing this exercise as a team when generating the team charter. The process I follow is:

  1. Place each of the descriptors on separate sticky notes and then place them on the wall so that all four continuums are visible.
  2. Review and discuss the meaning of each attribute.
  3. Have each team member mark where they believe they fall on each of the attribute continuums
  4. Discuss how the team can use the information to more effectively communicate.

Opposites might attract in poetry and sitcoms, however rarely do opposite learning styles work together well in teams without empathy and a dash of coaching. Therefore coach and teams need to have an inventory of learning styles on the team. Models and active evaluation against a model are tools to generate knowledge about teams so they can tune how they work to maximize effectiveness.

Categories: Process Management

Blood Sweat & Code

DevHawk - Harry Pierson - Wed, 04/02/2014 - 20:17

CNNToday was a *HUGE* thrill as I got to present in the keynote at //build! I’ll have more on the specifics of Brokered WinRT Components later after my session, but apparently quite a big deal was made of my shirt. I ended up as an internet meme and on the CNN Live Blog!

A long, long time ago (back when I wrote Photoshop Plugins for Mac long before I joined Microsoft), I had a Metrowerks CodeWarrior t-shirt with the “Blood Sweat & Code” slogan on the back. I loved that slogan, but lost the shirt somewhere along the way. So a few months ago, I decided to make a new one – but this time with the purple and blue of Visual Studio’s brand instead of CodeWarrior yellow. When I got a chance to be a part of the //build keynote today, I figured it was a good wardrobe choice.

For those who want one of their own, I posted the design on Zazzle.

Categories: Architecture, Programming

The *Real* Test Driven Development

Google Testing Blog - Wed, 04/02/2014 - 16:49

Update: As noticed in the comments, the date of the post was not a mere coincidence :)

by Kaue Silveira

Here at Google, we invest heavily in development productivity research. In fact, our TDD research group now occupies nearly an entire building of the Googleplex. The group has been working hard to minimize the development cycle time, and we’d like to share some of the amazing progress they’ve made.

The Concept

In the ways of old, it used to be that people wrote tests for their existing code. This was changed by TDD (Test-driven Development), where one would write the test first and then write the code to satisfy it. The TDD research group didn’t think this was enough and wanted to elevate the humble test to the next level. We are pleased to announce the Real TDD, our latest innovation in the Program Synthesis field, where you write only the tests and have the computer write the code for you!

The following graph shows how the number of tests created by a small feature team grew since they started using this tool towards the end of 2013. Over the last 2 quarters, more than 89% of this team’s production code was written by the tool!

See it in action:

Test written by a Software Engineer:

class LinkGeneratorTest(googletest.TestCase):

def setUp(self):
self.generator = link_generator.LinkGenerator()

def testGetLinkFromIDs(self):
expected = (''
actual = self.generator.GetLinkFromIDs(set((1346270, 1310696, 1288585)))
self.assertEqual(expected, actual)

Code created by our tool:

import urllib

class LinkGenerator(object):

_URL = (

def GetLinkFromIDs(self, ids):
result = []
for id in sorted(ids):
result.append('%s ' % id)
return self._URL + urllib.quote_plus(''.join(result))

Note that the tool is smart enough to not generate the obvious implementation of returning a constant string, but instead it correctly abstracts and generalizes the relation between inputs and outputs. It becomes smarter at every use and it’s behaving more and more like a human programmer every day. We once saw a comment in the generated code that said "I need some coffee".

How does it work?

We’ve trained the Google Brain with billions of lines of open-source software to learn about coding patterns and how product code correlates with test code. Its accuracy is further improved by using Type Inference to infer types from code and the Girard-Reynolds Isomorphism to infer code from types.

The tool runs every time your unit test is saved, and it uses the learned model to guide a backtracking search for a code snippet that satisfies all assertions in the test. It provides sub-second responses for 99.5% of the cases (as shown in the following graph), thanks to millions of pre-computed assertion-snippet pairs stored in Spanner for global low-latency access.

How can I use it?

We will offer a free (rate-limited) service that everyone can use, once we have sorted out the legal issues regarding the possibility of mixing code snippets originating from open-source projects with different licenses (e.g., GPL-licensed tests will simply refuse to pass BSD-licensed code snippets). If you would like to try our alpha release before the public launch, leave us a comment!

Categories: Testing & QA

Management 3.0 Workout: One-Day Workshop (Part 1)

NOOP.NL - Jurgen Appelo - Wed, 04/02/2014 - 14:37
One-Day Workshop Part 1

While I am frantically working to finish my new book (with three copy editors and fifty proof readers) I’m also developing ideas for the new one-day workshop that is part of the global book tour.

The post Management 3.0 Workout: One-Day Workshop (Part 1) appeared first on NOOP.NL.

Categories: Project Management

Requirements for Business Analytics follow-on with more ideas

Software Requirements Blog - - Wed, 04/02/2014 - 12:28
I recently gave a webinar on Requirements for Analytics Projects and had a few interesting questions come up during it. I thought I’d share some of the Q&A here, since we didn’t get to cover them all in the webinar. You can listen to the webinar here. Here are some of the questions and answers. […]

Requirements for Business Analytics follow-on with more ideas is a post from:

Categories: Requirements

Learning Styles and Communication Problems

Include differences (learning styles, that is)

Include differences (learning styles, that is)

The team that completes a project will be different from the one that began the project. Each person on the team will have a range of individual experiences, and presumably, they will learn from these experiences. A mismatch of learning styles can result in communication problems. Communication problems act as a filter on what each individual learns by blocking or altering what the learner perceives.

Learning styles reflect an individual’s preference for how they will learn. In many cases individuals mirror their own learning style when share with others. Most, if not all, teams I have been associated with over my career have been comprised of individuals with different learning styles. This means that to effectively communicate and transmit knowledge, each team member must understand the learning styles of their team members (this is another reason why stable teams generally have higher levels of performance).

An example of the impact when team members do not understand each other’s learning style can be seen in a team I recently observed.  The team is a relatively new team and is distributed, with most interactions occurring via teleconference, which complicates bonding. Most team members have not had time to adjust to each other’s learning style; therefore members use their own learning patterns as a default when interacting. For example, one team member follows the logical/Lawyer learning style. When presenting information they build a case – fact by fact – in great detail. No one else on the team leverages this as their primary learning style. The great level of detail and the slow (but relentless) build to the conclusion leads to frustration and disengagement. On the same team, another member is verbal learner/Talker.  This person needs learns by hearing, and in many cases, by vocalizing each point.  This person presents information in the same manner as they learn, talking it through (with lots of Keynote slides … with no pictures). In both cases because the members are not aware of the learning styles of other team members communication is inefficient (and my observation is that it can be ineffective).

Teams that are centrally located generally recognize learning style mismatches based on visual and empathetic feedback and can self-correct (assuming that team members actually pay attention when they get together). Distributed teams generally need to take a more active approach to learning each other’s preferences. I recommend the following approach which can be used as a team building exercise or as a retrospective exercise:

  1. Before the exercise, create a couple of canned scenarios.  For example:
    1. Scenario One:  Pass status information about a trouble task, including a plea for help.
    2. Scenario Two:  Build consensus for a design decision.
  2. Have each team member identify their primary and secondary learning style.
  3. Share these styles with the team.
  4. Once all team members have shared their style, have each team member select a method that is not their primary or secondary style and have them convey the information needed in complete each scenario. (Allow 5 minutes for preparation).

The goal of exposing the team to other types of learning styles is to push each person outside their comfort zone.  This serves multiple purposes. First, the process helps to build empathy. The process also reinforces the awareness that, on a diverse team, all messages need to be shared in a variety of ways so that multiple learning styles can easily absorb the information.  Finally, by learning and becoming sensitive to other learning styles, individual team members will expand their ability to recognize nuances in communications that lay outside their normal learning style. This will ultimately increase the effectiveness and efficiency of the team.

Categories: Process Management