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

Software Development Conferences Forecast April 2014

From the Editor of Methods & Tools - Mon, 04/28/2014 - 11:11
Here is a list of software development related conferences and events on Agile ( Scrum, Lean, Kanban) software testing, 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: STAREAST, May 4–9 2014, Orlando, USA GOTO Amsterdam 2014, June 18-20, 2014, Amsterdam, The Netherlands The Reliable Software Developers Conferences, May 20 – June 5, UK The Android Developer Conference, May 27-30, Boston, USA Better Software & Agile Development ...

SPaMCAST 287 – Scrum The Face of Agile, Constraints, Tame the Flow

Listen to the Software Process and Measurement Cast 287.

SPaMCAST 287 features our essay on Scrum. Scrum is the nearly ubiquitous project management process that has become the face of Agile to many people.

The essay begins:

When most people think of Agile, they really mean Scrum.  Scrum is a fairly simple framework whose origin is attributed to Jeff Sutherland and Ken Schwaber. There are numerous overviews of the history and evolutions of the framework; those at Scrum.org and Scrumalliance.org (where my CSM certification comes from) are two good ones.  The framework is simple. In its basic form it is comprised of three roles, five events and four deliverables.

We also have the next installment of Steve Tendon’s column, Tame the Flow.  Steve revisits constraints and bottlenecks.

Get in touch with us anytime or leave a comment here on the blog. Help support the SPaMCAST by reviewing and rating it on iTunes. It helps people find the cast. Like us on Facebook while you’re at it.

Next week we will feature our interview with Susan Atkinson. We discussed Agile contracts, governance and trust.  Quite a set of topics and quite an interview!

Upcoming Events

StarEast

I will be speaking at the StarEast Conference May 4th – 9th in Orlando, Florida.  I will be presenting a talk titled, The Impact of Cognitive Biases on Test and Project Teams. Follow the link for more information on StarEast.

ITMPI Webinar!

On June 3 I will be presenting the webinar titled “Rescuing a Troubled Project With Agile.” The webinar will demonstrate how Agile can be used to rescue troubled projects.  Your will learn how to recognize that a project is in trouble and how the discipline, focus, and transparency of Agile can promote recovery. Register now!

Upcoming DCG Webinars:

May 22 11:30 EDT – Agile User Stories

June 19 11:30 EDT – How To Split User Stories

July 24 11:30 EDT – The Impact of Cognitive Bias On Teams

Register here!

I look forward to seeing or hearing all SPaMCAST readers and listeners at all of 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 287 – Scrum The Face of Agile, Constraints, Tame the Flow

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

Listen to the Software Process and Measurement Cast 287

SPaMCAST 287 features our essay on Scrum. Scrum is the nearly ubiquitous project management process that has become the face of Agile to many people.

The essay begins:

When most people think of Agile, they really mean Scrum.  Scrum is a fairly simple framework whose origin is attributed to Jeff Sutherland and Ken Schwaber. There are numerous overviews of the history and evolutions of the framework; those at Scrum.org and Scrumalliance.org (where my CSM certification comes from) are two good ones.  The framework is simple. In its basic form it is comprised of three rolesfive events and four deliverables.

We also have the next installment of Steve Tendon’s column, Tame the Flow.  Steve revisits constraints and bottlenecks.

Get in touch with us anytime or leave a comment here on the blog. Help support the SPaMCAST by reviewing and rating it on iTunes. It helps people find the cast. Like us on Facebook while you’re at it.

Next week we will feature our interview with Susan Atkinson. We discussed Agile contracts, governance and trust.  Quite a set of topics and quite an interview!

Upcoming Events

StarEast

I will be speaking at the StarEast Conference May 4th – 9th in Orlando, Florida.  I will be presenting a talk titled, The Impact of Cognitive Biases on Test and Project Teams. Follow the link for more information on StarEast.

ITMPI Webinar!

On June 3 I will be presenting the webinar titled “Rescuing a Troubled Project With Agile.” The webinar will demonstrate how Agile can be used to rescue troubled projects.  Your will learn how to recognize that a project is in trouble and how the discipline, focus, and transparency of Agile can promote recovery. Register now!

 

Upcoming DCG Webinars:

May 22 11:30 EDT – Agile User Stories

June 19 11:30 EDT – How To Split User Stories

July 24 11:30 EDT - The Impact of Cognitive Bias On Teams

Register here!

I look forward to seeing or hearing all SPaMCAST readers and listeners at all of 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

Texas AEA Summit Recap

Mike Walker's Blog - Sun, 04/27/2014 - 20:07

image

Wow, what a great event.  It’s been a month since the first the event and we are still getting  a great deal of feedback on the value of the event. Thank you to all of you that attended. 

With close to 125 attendees for this first time summit of the Texas Association of Enterprise Architects we couldn't of asked for a better turnout. We had attendees from multiple sectors, multiple Texas cities (Dallas, San Antonio and Houston) and from other architecture associations that decided to show up. As an example, we've had the San Antonio Enterprise Architecture Association come to our meetings along with IASA. At this event we had the good fortune of having the IASA Austin chapter president and an IASA marketing person so support for what we are doing at this summit. What I want people to take away from this is that the Texas AEA is open to all architecture professionals regardless of affiliation or level of experience. All are welcome.

 

IMG_1271   IMG_1291   IMG_1269

 

The theme for the summit was centered all around real world practitioner stories, Keeping EA Real. I think we did that with our excellent speakers in the real world stories from the trenches.

However, don’t just take my word for it. Check out all the great social media activity on the event at hashtag #TexasAEA

image

 

All of the presentations from the day are available on the Global Association of Enterprise Architects portal under the Texas Chapter. All you need to do is login and and the presentations freely available to you. We also recorded the sessions and looking to find a way of sharing those with you as well.

This summit may of been very different compared to traditional conferences that you may be used to. The day was split into two major sections. The day started out with a traditional conference format with keynote speakers and sessions lots for more of a one-way dialogue. We had Jeanne Ross and John Zachman as the headliners for the summit followed by 20 minute TED style customer case studies. These were rapid succession get to the point sessions without any of the fluff. I think this was extremely valuable.

After lunch and the second half of the summit was built to be more interactive similar to what you would find at in an conference. We kicked off the second half with a panel from the TD style presentations from earlier in the morning. This was built to be interactive serving the questions of the audience. From there we went into open space/uncomfortable style roundtables. At the beginning of the conference we had voting on which topics they wanted to discuss at the roundtables. Those that got the votes the highest were nominated as the roundtable that people want to. After the roundtables we recaps the entire day and went directly to the social event afterwards. Again to facilitate meaningful conversation amongst enterprise architecture peers.

Bellow is a further break down of the conference. I don't cover every point that was made but more the salient points that resonated with me that I would like to share with all of you.

Morning Sessions

Welcome address

The day started off with myself kicking off the day in the welcome address. I talked about our vision in charter for the Texas chapter. This included some things we'd already discussed in our first meeting but for the sake of the new attendees we wanted to go through the full vision of the Texas AEA.

There's also some highlights that we discussed as well. Namely the current state of the chapter. Month over month our chapter doubles in size.

image

The chapters only been around for three months. What this teams me is the there is an enormous amount of demand for what we're doing here for the EA profession at least here in Texas. With both potential and non-members of the AEA, the attendance has shown us an overwhelming amount of support for what we're doing. As an example we usually find of the typical audience one fourth of the audience is non-members with a month over month growth rate seeing that those very non-members transition into members.

 

image Another important announcement is around professional development. The AEA will be supporting the ability to issue credits for activities you do through the AEA. So if you go to a summit, present at a monthly meeting or collaborate through the portal these all generate credits for you to demonstrate all the great things you've been doing in the year profession. Keep in mind this only applies to Open CA and not skills-based certifications like TOGAF. This is taking certification to the next level of maturity that gives people the credit where credit is due.

 

Along with professional development credits, a related announcements is around actual certification. Here in the Texas AEA we have several Open CA certified enterprise architects. With that we are planning on creating a mentorship program to help those that want to achieve their open sea certification. Along with us we been granted the ability to hold certification boards as well. We will be the first AEA chapter to do this. Very exciting news!

 

Jeanne Ross: Enterprise Architecture State of the Union

image

Jeanne Ross opened up the conference with her keynote. Unfortunately she was in Paris this week but delivered the next best thing, a prerecorded message just for us!

Jeannie continue to describe the evolution of her research at MIT Sloan. The message that sticks out most of my mind is really centered around a change in mentality that enterprise architects need to adopt. Jeanie cover this, and I wholeheartedly agree, enterprise architects should stop trying to have their customers try to understand exactly what they do. Rather, we should be focused on what our customers want rather than having our customers understand exactly what and how we execute the end deliverable for the end customer.

I keep it as simple as this. If I hire a plumber 2 o'clock a drain at my home, I don't want to understand how to be a plumber I just want my drink the unclogged. But in this scenario, enterprise architects as the plumber, we're trying to give a schematic of the drain systems and discuss optimization in tolling over a set of blueprints that myself as a consumer doesn't fully understand and respect the S can't have any informed opinion on. It's just a waste of time and energy. I think EA is having a big opportunity here to change their mindset.

 

John Zachman: Enterprise physics 101

image

Next up was John Zachman. Just being in Zachman's presence is extremely humbling. After all, we wouldn't be here if it wasn't for him. And he seems to be the perfect EA. Not because he started this whole thing in I'm a bit starstruck but he has the ideal demeanor and personality traits of the ideal Enterprise Archtect. He has the ability to greatly influence a room while also checking the ego at the door. I was pleasantly surprised on how humble he really was.

John took us through his latest thinking on the Zachman framework. He discussed how the past couple years he has really learned a great deal about enterprise architecture. This was through a colleague of his based in India that was building a set of EA consultancy services around the Zachman framework. By exercising the framework broadly like this exposed quite a few things that were considered before.

He explained to the group the philosophy behind the Zachman framework. Essentially it's ensuring that you're asking all the right questions to make sure that you have a complete understanding of what is to be architected. So John borrowed from the 6 interrogative's that fully complete a story: who, what, when, where and why. With this, that and explained that his framework really wasn't an EA framework but rather an ontology. Personally, I couldn't agree more. You can see you post here on this topic.

imageAnother important point that John made was in a similar vein as Jeanne Ross. He chose just to think about EA profession and how we been conducting ourselves. Well Jeannie focus on the interpersonal or sauce skills Mr. Zachman looked at it from the perspective of what we do as enterprise architects. You know do that he used was comparing what we do to either a manufacturer or in engineer. John's point was that we call ourselves or contrast we do with engineers but reality we can Dr. sells more as manufacturers. Meaning that there isn't much that is truly engineered and thought through with great detail and rigor but rather we are more supply line manufacturers crunching out widgets.

This is a very interesting analogy and one I don't fully think is easily understandable however I get the incident and agree with it. If you've heard me talk you know that I talk about architecture versus implementation. This is essentially what Mr. Zachman is talking about here. Architecture is all about planning, designing and engineering. The things we do after Architecture are all about executing meaning we going bill or in John's terms manufacture.

After getting some fundamental framing on how are conducting ourselves in this profession in a bit of setting stage for what's next, John went through his ontology or what is commonly referred to as the Zachman framework. He referred to it as the periodic table of elements for enterprise architecture it has all of the fundamental elements of what we need to do in enterprise architecture. What how I refer to it, it's a measure of completeness. But it's up to you to figure out the right questions to ask and how to implement this tool. It's not predicated that every box gets checked off or all questions get answered that's where your judgment comes.

When John talks about the usage of the pure a table for enterprise architecture he talks a great deal about how to compose an implement it. It's so he draws analogies from the chemistry world. He challenges us to think about using those foundational elements versus what he refers to ask composite. Already prefabricated or combined foundational elements of the Zachman framework to make business decisions. His assertion and I agree is that when we do that mean heritage whole set of constraints or objectives that we know me know he's trying so for. So my take a step back and looking at all the foundational elements might be a really good thing. However keep in mind having composites isn't entirely a bad thing in my opinion, however you want to make sure that you understand all the characteristics of it.

The last and final messages that John sent was around misconceptions of the framework. Mr. Zachman made it very clear that his framework was never intended to operate on its own. It is merely an ontology.

Again, Thank you to the attendees

Categories: Architecture

Delivering Needed Capabilities

Herding Cats - Glen Alleman - Sun, 04/27/2014 - 04:39

The needed capabilities for business or mission success starts with the Concept of Operations. With the ConOps we can identify the needed capabilities. Below is an actual project, with increasing capabilities for an insurance firm. The order of these delivered capabilities are defined by the business strategy and the Balanced Scorecard. Both define needed capabilities, the value stream map for producing business value or mission fulfillment and the order in which these capabilities should arrive to sustain the needed business benefits from the project. The by the way the mechanism for prioritizing features, which are much lower in the hierarchy of project elements that are commonly referred to in agile community. Features fulfill requirements, requirements implement capabilities.

Customer didn't buy features or requirements, they buy the capability to do something to improve their business. 

A useful method of managing the project for delivering these capabilities is the Integrated Master Plan and Intetgrated Master Schedule. 

The integrated master plan and integrated master schedule from Glen Alleman Related articles The "Real" Root Cause of IT Project Failure Practices without Principles Does Not Scale Concept of Operations First, then Capabilities, then Requirements Process Improvement In A Complex World Performance-Based Project Management(sm) Released
Categories: Project Management

Monoidal Event Sourcing Examples

Think Before Coding - Jérémie Chassaing - Sun, 04/27/2014 - 01:16

Last time we tried to imagine how we could change usual event sourcing definition$ to get a monoidal approach.

 

Here are some examples to make it work in real life.

Monoids properties

We'll try to do it properly, and test that the proposed solutions are proper monoids.

 

Let's recap what defines a monoid:

  • closure of operation
  • associativity
  • neutral element
How to test it

the closure of operation is given by the signature of the operation. In F# it should have a signature like 'a -> 'a –> 'a which represents a function that takes to arguments of type 'a and return a result of the same type 'a.

 

For associativity, we'll use the following test function:

1: 
2: 
let isAssociative (*) x y z =
   ((x * y) * z) = (x * (y * z))

It take a function that will be called '' and three values x y z. It will then test the associativity of '' using FsCheck, a F# port of QuickCheck.

 

FsCheck test the given property for a wide range of values. We'll just have to provide the operator, and FsCheck will check it the associativity holds for a lot of values.

 

For the neutral element, will use the following test function:

1: 
2: 
let isNeutralElement (*) neutral x =
    x * neutral = neutral * x

 

Here we'll have to provide the the operator - called '*' inside the function - and the neutral element.

Trivial cases

There are some obvious trivial cases.

 

Let's try to follow the number of occurrences of a specific event in state. The number of time a user did

something.

 

The map function is simply:

1: 
2: 
3: 
let map = function
    | TheUserDidSomething -> 1
    | _ -> 0

 

The combine operation is then really simple:

1: 
let combine acc v = acc + v

and the neutral element is obviously 0.

 

No need to check it with FsCheck, (N, +, 0) is a monoid..

 

Another a bit less obvious is when an event sets a value while others don't.

 

For instance, let's keep track of the last user address when a user moves.

 

For combination, we'll use the 'right' function, which always takes it's rightmost argument:

1: 
let right x y = y

 

The adress should, of course, not change on other events, and for that, we'll use an option:

1: 
2: 
3: 
let map' = function
    | UserMoved (user, newAddress) -> Some newAddress
    | _ -> None

 

The right function can then be tweaked to take the right argument only when it has a value:

1: 
2: 
3: 
4: 
let right' x y =
    match x,y with
    | x, None -> x
    | _, y -> y

right' has a signature of 'a option -> 'a option -> 'a option, so it's closed on operation.

 

It's associative since, whatever x y z, (x right' y right' z) return the last defined term, however composed.

 

None is the neutral element. Added to the left, it keeps what's on the right, added to the right, it keeps what's on the left.

 

We can check it with FsCheck:

1: 
2: 
Check.Quick (isNeutralElement right' None)
Check.Quick (isAssociative right')
A less trivial case

But what about mixing both ? Some events change the value by increments, while some other set a specific value ? Like a stopwatch that increments with a button to reset it.

 

Can we model this kind of thing as a monoid ?

 

We have an increment or a reset value, let's model it as a discriminated union:

1: 
2: 
3: 
type ChangeReset<'T> =
    | Change of 'T
    | Reset of 'T

 

 

A map function, that map events to state change, would be something like:

1: 
2: 
3: 
4: 
let map'' = function
    | TimePassed duration -> Change duration
    | ButtonPushed -> Reset 0.
    | _ -> Change 0.

 

The first two cases are a direct mapping, for other events, we use the Change 0. values that actually use the neutral element of the underlying monoid. Adding 0 will not change the value.

 

We have here an underlying monoid, here, talking about duration, we use numbers, with addition and 0.

 

But imagine we want to add items to a list, but sometime, reset the list to a specific one like the empty list.

 

we can define a high order combine operation like this:

1: 
2: 
3: 
4: 
5: 
let combine' (*) x y =
    match x,y with
    | Change xi, Change yi -> Change (xi * yi)
    | Reset xv, Change yi -> Reset (xv * yi)
    | _ , Reset yv -> Reset yv

 

It combines to changes as a new change using the underlying monoid operation - called '*' here. It combines changes as a change.

 

The second line states, that a value (Reset) combined with a change will apply the change to the value.

 

But the third line says that when a Reset value is on the right of anything, it overrides what's on it's left.

This operation is by it's signature closed on the ChangeReset<'t> type.

 

It's associative, because while combining changes, it has the associativity of the underlying monoid, and when combining Reset values it has the associativity of the right operation.

 

The neutral element is a change with the value of the neutral element of the underlying monoid.

 

We can verify it with FsCheck:

1: 
2: 
Check.Quick (isNeutralElement (combine' (+)) (Change 0))
Check.Quick (isAssociative (combine' (+)))
General structure

I had some remarks that we needed it to be a group and not only a monoid. The right' and combine function clearly don't define a group because elements don't have a inverse/opposite.

 

What would be the opposite of Reset 5 ? It set the value 5 whatever is on its left.

 

The idea is to take the set of state values S.

 

Then take the set of changes from states in S to other states in S that are represented by the events.

 

Make the union of it. SC = S U C. SC will contain more that valid aggregate states. It will also contain things that are not state, like a value that indicate that the state did not change.

 

But we will ensure the following things: the function that convert to changes will return items of C:

1: 
map: Event -> C 

 

The combine operation will be closed on SC, so it can accept States from S and change from C, and it will be closed on SC: combine:

SC -> SC -> SC

 

But it will also ensure that when a state is given on the left, it will also return a state:

combine:  S -> SC -> S

 

The right' operation ensure this. The state need a value at its start, you can add as many None on the right, it'll still have it's value, and any new value will return this value.

 

For the ChangeReset type, the State is represented by the Reset values -that are actual values- it's S, while changes are represented by the Change values that define C.

 

As long as a Reset value is given at the outmost left, the result will be a Reset value that is part of S.

With this, we don't need a group, but we can do with something that is only slightly more restraint than a monoid, only to keep the semantic of state.

But we need more that a single value !

Of course aggregate state is usually composed of more than a single value.

 

Let's start small and consider a pair.

1: 
type State<'a,'b> = 'a * 'b

 

If 'a and 'b are monoids we can easily combine them :

1: 
let combine'' (+) (*) (xa,xb) (ya,yb) = (xa + ya, xb * yb)

where + is the operation on 'a and * the operation on 'b.

 

The neutral element is simply

1: 
let neutral neutrala neutralb = (neutrala, neutralb)

You can easily check that combine is closed on operation, associative, and that neutral is the neutral element.

 

recursively, you can build a triple as a pair of a pair with a single element (('a,'b), 'c), then a quadruple and any tuple.

 

Since a structure - a record - is just a tuple with names, any struct with monoidal members is also a monoid.

 

And since in Event Sourcing, all the tricky decisions are done before emitting an event, applying the event should just be setting values, incrementing / decrementing values, adding / removing items to sets or lists, all those operation are monoidal, hence almost all aggregates should be convertible to monoidal Event Sourcing.

 

Of course it doesn't mean you should do Event Sourcing this way, but it was rather funny to explore this !

 

Have fun !

Categories: Architecture, Requirements

Reviews and Inspections: Why?

Reviews and inspections focus on quality.

Reviews and inspections focus on quality.

Why are reviews and Inspections important?  Because they affect the quality a project’s deliverable. The quality of product is generally positively correlated with value. As the quality of a project’s deliverable increases, the higher that product is valued. Quality influences at least five major components of value:

  1. Usability: Higher quality products are by definition more usable than the same product with lower quality. For example, I am an avid Evernote user, however recently I discovered a latent bug that broke the app for over a month. The lack of usability negatively impacted my perception of quality (even thought their customer service resolved the situation).
  2. Reduced Maintenance: A product with a smaller number of latent defects will require fewer fixes (less maintenance) than the same product with more defects. Every dollar spent on fixing defects in production is a dollar that can’t be spent on new features. Improving quality increases the budget that can be spent on development and enhancements.
  3. More Output: Increasing development quality helps an IT organization deliver more value. As noted, reduced maintenance provides more time for development.  Secondly, it is a commonly held belief that a defect discovered earlier in the development cycle requires less effort to fix than one found later in the development cycle. The effort to fix a defect is typically called rework. The lower the amount of rework a project has to deliver, the more time that will be available to deliver value.
  4. Cost: Improving quality lowers rework and reduces maintenance, which translates directly to a lower cost per unit of work delivered. A simple metric is cost is cost per function point. Lower costs generally make everyone happy, specifically those people than have to manage the IT budget.
  5. Customer satisfaction: Quality and customer satisfaction are highly interrelated. Customer satisfaction is influenced by many different attributes. Product quality is a broader concept than just product quality, however without product quality few of the other project attributes (for example team professionalism and empathy for your customers needs) matter. Increased quality is generally linked to increased customer satisfaction. When a team’s customers are satisfied the team’s job satisfaction increases, which leads to improved performance and even higher quality.  A cycle of improving quality and customer satisfaction is a virtuous circle.

Reviews and inspections are a method for improving the quality of the products a team delivers. In a perfect world we would have a perfect engineering process that would allow a project team to gather requirements, design, build, and deliver a perfect solution. The perfect engineering process would not require the burden of management approvals, reviews, inspections, or even testing. Real world engineering processes will never be perfect. Therefore, every project team must work hard to balance the level of quality an organization needs (or can afford) with the cost of testing.  Reviews and inspections tend to be less costly than testing because they can be applied earlier in the development cycle. As a result, they help to tip the balance toward quality.


Categories: Process Management

Yet More Change for the Capitals

DevHawk - Harry Pierson - Sat, 04/26/2014 - 21:13

Six years ago, I was pretty excited about the future for the Washington Capitals. They had just lost their first round match up with the Flyers – which was a bummer – but they had made the playoffs for the first time in 3 seasons. I wrote at the time:

Furthermore, even though they lost, these playoffs are a promise of future success. I tell my kids all the time that the only way to get good at something is to work hard while you’re bad at it. Playoff hockey is no different. Most of the Caps had little or no playoff experience going into this series and it really showed thru the first three games. But they kept at it and played much better over the last four games of the series. They went 2-2 in those games, but the two losses went to overtime. A little more luck (or better officiating) and the Caps are headed to Pittsburgh instead of the golf course.

What a difference six seasons makes. Sure, they won the President’s Trophy in 2010. But the promise of future playoff success has been broken, badly. The Caps have been on a pretty steep decline after getting beat by the eighth seed Canadians in the first round of the playoffs in 2010. Since then, they’ve switched systems three times and head coaches twice. This year, they missed the playoffs entirely even with Alex Ovechkin racking up a league-leading 51 goals.

Today, the word came down that both the coach and general manager have been let go. As a Caps fan, I’m really torn about this. I mean, I totally agree that the coach and GM had to go – frankly, I was surprised it didn’t happen 7-10 days earlier. But now what do you do? The draft is two months and one day away, free agency starts two days after that. The search for a GM is going to have to be fast. Then the GM will have to make some really important decisions about players at the draft, free agency and compliance buyouts with limited knowledge of the players in our system. Plus, he’ll need to hire a new head coach – preferably before the draft as well.

The one positive note is that the salary cap for the Capitals looks pretty good for next year. The Capitals currently have the second largest amount of cap space / open roster slot in the league. (The Islanders are first with $14.5 million / open roster slot. The Caps have just over $7 million / open roster slot.) They have only a handful of unrestricted free agents to resign – with arguably only one “must sign” (Mikhail Grabovski) in the bunch. Of course, this could also be a bug rather than a feature – having that many players under contract may make it harder for the new GM to shape the team in his image.

Who every the Capitals hire to be GM and coach, I’m not expecting a promising start. It feels like the next season is already a wash, and we’re not even finished with the first round of this year’s playoffs yet.

I guess it could be worse.

I could be a Toronto Leafs fan.

Categories: Architecture, Programming

Date Types

Phil Trelford's Array - Sat, 04/26/2014 - 17:21

When you want to set a date literal in F# (or C#) you create a new DateTime instance:

let today = DateTime(2014,26,4)

If you’re rocking VB.Net you get date literals which are checked at design & compile time:

Dim d = #2014/04/26#

I thought it’d be nice to add design and compile time checked date literals to F#, & throw in code completion for good measure. Enter F# Type Providers. No need to open millions of lines of compiler code, instead simply implement a class to provide the types & voilà:

let today = Date.``2014``.``04``.``26``

As you type the date, you can only enter valid values:

today

Or you can for example use it to easily find the last Saturday of the month:

saturday

The code is up on BitBucket & there’s a Nuget package, it’s pretty simple, less than a 100 lines of code, and no compilers were harmed in the process. Being what it is, this is really just scratching the surface of the power of F# Type Providers, which can give you typed access to data from web services or databases all the way through to other languages.

Build your own Type Provider

Creating your own type providers is easier than you might think, Michael Newton has a great article to get you started: Type Providers From the Ground Up.

F#unctional LondonersCoincidentally the F#unctional Londoners will be hosting a Creating Type Providers Hands On Session with Michael next Thursday at Skills Matter.

Pop along, have fun, and see the kind of things you can build.

Categories: Programming

Get Up And Code 051: Richard Campbell Climbs Mountains

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

I was really excited to be able to talk to Richard Campbell from one of my favorite podcasts, Dot Net Rocks. Richard has a pretty interesting “hobby.” Full transcript below: show John:               Hey, everyone.  Welcome back to Get Up and CODE.  I’m John Sonmez.  Today, I’ve got a really special guest here.  I was really […]

The post Get Up And Code 051: Richard Campbell Climbs Mountains appeared first on Simple Programmer.

Categories: Programming

Clojure: clj-time – Formatting a date / timestamp with day suffixes e.g. 1st, 2nd, 3rd

Mark Needham - Sat, 04/26/2014 - 08:50

I’ve been using the clj-time library recently – a Clojure wrapper around Joda Time – and one thing I wanted to do is format a date with day suffixes e.g. 1st, 2nd, 3rd.

I started with the following timestamp:

1309368600000

The first step was to convert that into a DateTime object like so:

user> (require '[clj-time.coerce :as c])
user> (c/from-long 1309368600000)
#<DateTime 2011-06-29T17:30:00.000Z>

I wanted to output that date in the following format:

29th June 2011

We can get quite close by using a custom time formatter:

user> (require '[clj-time.format :as f])
nil
user> (f/unparse (f/formatter "d MMMM yyyy") (c/from-long 1309368600000))
"29 June 2011"

Unfortunately I couldn’t find anywhere in the documentation explaining how to get the elusive ‘th’ or ‘st’ to print. I was hoping for something similar to PHP date formatting:

2014 04 26 08 38 39

Eventually I came across a Stack Overflow post about Joda Time suggesting that you can’t actually format a day in the way I was hoping to.

So I now have the following function to do it for me:

(defn day-suffix [day]
  (let [stripped-day (if (< day 20) day (mod day 10))]
    (cond (= stripped-day 1) "st"
          (= stripped-day 2) "nd"
          (= stripped-day 3) "rd"
          :else "th")))

and the code to get the date in my favoured format looks like this:

user> (def my-time (c/from-long 1309368600000))
#'user/my-time
user> (def day (read-string (f/unparse (f/formatter "d") my-time)))
#'user/day
user> (str day (day-suffix day) " " (f/unparse (f/formatter "MMMM yyyy") my-time))
"29th June 2011"

I’m assuming there’s a better way but what is it?!

Categories: Programming

Reviews and Inspections: Anti-Patterns

Untitled2Reviews and inspections are powerful tools that can deliver a great deal of value, if they are done correctly. Like all powerful tools, if you use them incorrectly the results will not be as expected. There are several typical anti-patterns that can effect reviews and inspections. The top six are:

  1. Finding Fault: Reviews and inspections remove defects and provide the basis for teachable moments.  Finding fault or assigning blame for the defects found during or in a review will generate an adversarial environment that incents the person whose deliverable is being reviewed to hide defects or to strenuously debate whether anything is actually a defect.  Neither outcome promotes the goals of the review process. Note: not finding fault does not mean that leaders and managers should not correct problems or not to get people help when they need it.
  2. Lack of Preparation: Most reviews and inspections require preparation. Preparing ensures that the time spent doing a review or inspection is focused on removing defects rather than reading the deliverable in a group setting. When teams or organizations begin to forego preparing for reviews, they instead spend inordinate amounts of time in review meetings doing the preparation together and then doing the review. This approach is highly inefficient and because we all tend multitask, our attention span will tend to wander during long meetings which reduces effectiveness. I have also observed that as review duration increases, participation decreases.
  3. Combining Reviews and Approval Events: Combining reviews and inspections with approval events generally shifts the focus of the process from defect removal to getting approval to progress (sometimes called sign off). Making a good review or inspection into a hurdle for approval incents the author and his or her allies to hide, downplay or generally spin any potential defects so that the project can keep moving. Going down this path will insure less defects are found, not that less defects exist.
  4. Manager Involvement: It is a rare team in which the person that controls (or strongly influences) team member’s salary or promotion opportunities is truly a peer of those on the team doing the work. Involving managers in reviews and inspections will tend to increase the level of defect hiding, posturing and just plain brown-nosing. None of these behaviors are conductive to efficiently and effectively finding and removing defects. Reviews and inspections work best in an environment where sharing and accepting feedback is not dangerous to one’s career.
  5. Nothing To Compare With: Reviewing any deliverable against nothing or just reviewers experience is generally ineffective and tends to spin down into discussions or debates based on opinions. Reviews are most effective when the deliverable being reviews is compared to something everyone can reference.  Team, organizational and/or industrial standards, architectural frameworks or even previous deliverables are all useful to compare against in a review or inspection.
  6. Not Enough Time: The requirement to do a review or inspection without enough time to do it right defeats the reason for doing reviews. I can’t count the number of times I have heard teams rushing thought a review say, “well this is better than nothing.” Well, perhaps it really isn’t better than nothing.  At the very best, a rushed review will leave defects in deliverables that will need to be removed later or that your customers will get to find for you.  Even worse, short cutting the time needed to do reviews correctly sends a message that we only pretend to believe in the processes we use and the IT really doesn’t know what they are doing. The consequences in the long run are usually a change in management or outsourcing.

If you recognize any of these anti-patterns, fix the problem.  If you need help making the point get a coach or consultant to help you. Organizationally, if you can’t correct these anti-patterns, stop using reviews and inspections and do something else such as hiring lots of extra independent testers.  Doing reviews and inspections poorly is not doing you any favors.


Categories: Process Management

Dashboards are important!

Agile Testing - Grig Gheorghiu - Fri, 04/25/2014 - 22:21
In this case, they were a factor in my having a discussion with Eric Garcetti, the mayor of Los Angeles, who was visiting our office. He was intrigued by the Graphite dashboards we have on 8 monitors around the Ops area and I explained to him a little bit of what's going on in terms of what we're graphing. I'll let you guess who is the mayor in this photo:


Slides from my remote presentation on "Modern Web development and operations practices" at MSU

Agile Testing - Grig Gheorghiu - Fri, 04/25/2014 - 22:06
Titus Brown was kind enough to invite me to present to his students in the CSE 491 "Web development" class at MSU. I presented remotely, via Google Hangouts, on "Modern Web development and operations practices" and it was a lot of fun. Perhaps unsurprisingly, most of the questions at the end were on how to get a job in this field and be able to play with some of these cool technologies. My answer was to become active in Open Source, beef up your portfolio on GitHub, go to conferences and network (this was actually Titus's idea, but I wholeheartedly agree), and in general  be curious and passionate about your field, and success will follow. I posted my slides on Slideshare if you are curious to take a look. Thanks to Dr. Brown for inviting me! :-)

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

Hey, it's HighScalability time:


New World Record BASE jumping from World's Tallest Building. #crazy
  • 30 billion: total Pinterest pins; 500,000,000: What'sApp users (700 million photos and 100 million videos every single day); 1 billion: Facebook active users on phones and tablets.
  • Quotable Quotes:
    • @jimplush: Google spent 2.3 billion on infrastructure in Q1. Remember that when you say you want to be "the Google of something"
    • Clay Shirky: I think one of the things that happened to the P2P market for infrastructure is that users preference for predictable pricing vs resource-sensitive pricing is so overwhelming that they will overpay to anyone who can promise flat prices. And because the logic of centralization vs decentralization is so price sensitive, I don't think there is any logical reason to assume a broadly stable class of apps, separate from current pricing data for energy, cycles, and storage.
    • @chipchilders: Stop freaking making new projects just for the sake of loose coupling. Damn it people.
    • Benedict Evans (paraphrased): A startup 15 years ago raised 10 million dollars, had 100 people, and a million users. Now you raise a million dollars, have 10 people, and a 100 million users.
    • @francesc: "Go was created for the cloud infrastructure, when we used to call it servers" - @rob_pike at #gophercon
    • @postwait: distributed system: an arbitrarily large state machine w/ "unknown" & "f*cked" states wherein you can't observe the movement between states.
    • @enneff: "In Ruby regular expressions are actually very fast... compared to all the other things you can do." --@derekcollison LOL #gophercon
    • Steve Jobs: This needs to be like magic. Go back, this isn’t magical enough!
    • @jamesurquhart: The complexity isn’t in the tech, it is in the interconnected apps and comps in systems. Managing interconnectedness is managing complexity.
    • Alex Pentland: Put another way, social physics is about how human behavior is driven by the exchange of ideas—how people cooperate to discover, select, and learn strategies and coordinate their actions—rather than how markets are driven by the exchange of money.

  • Steve Jobs with the carrot: This is important, this needs to happen, and you do it. And now this stick: Guess what, you’re Margaret from now on. 

  • A fantastic look at Uplink Latency of WiFi and 4G Networks by Ilya Grigorik: WiFi can deliver low latency first hop if the network is mostly idle. By contrast, 4G networks require coordination between the device and the radio tower for each uplink transfer. First off, latency aside, and regardless of wireless technology, consider the energy costs of your network transfers! Periodic transfers incur high energy overhead due to the need to wake up the radio on each transmission. Second, same periodic transfers also incur high uplink coordination overhead - 4G in particular. In short, don't trickle data. Aggregate your network requests and fire them in one batch: you will reduce energy costs and reduce latency by amortizing scheduling overhead.

  • It's like Sherlock for programmers. How to detect bank loan fraud with graphs : part 2. A fun way to use graph databases, finding criminals by analyzing patterns using graph algorithms. Also, Building a Graph-based Analytics Platform: Part I

  • Cache Invalidation Strategies With Varnish Cache. Good explanation of different techniques: purging, bans, tagging, grace, TTL. It covers the issue of distributing cache invalidations to multiple caches, but it doesn't seem fault tolerant. 

  • To be smarter the brain had to get more social.  A general pattern for intelligence at different scales? Finding turns neuroanatomy on its head: Researchers present new view of myelin: The fact that it is the most evolved neurons, the ones that have expanded dramatically in humans, suggests that what we're seeing might be the "future." As neuronal diversity increases and the brain needs to process more and more complex information, neurons change the way they use myelin to "achieve" more.  It is possible that these profiles of myelination may be giving neurons an opportunity to branch out and 'talk' to neighboring neurons. These long myelin gaps may be needed to increase neuronal communication and synchronize responses across different neurons. < For more on the amazing ways human social networks improve problem solving take a look at Social Physics: How Good Ideas Spread-The Lessons from a New Science.

Don't miss all that the Internet has to say on Scalability, click below and become eventually consistent with all scalability knowledge (which means this post has many more items to read so keep on going)...

Categories: Architecture

Brokered WinRT Components Step Three

DevHawk - Harry Pierson - Fri, 04/25/2014 - 16:45

So far, we’ve created two projects, written all of about two lines of code and we have both our brokered component and its proxy/stub ready to go. Now it’s time to build the Windows Runtime app that uses the component. So far, things have been pretty easy – the only really tricky and/or manual step so far has been registering the proxy/stub, and that’s only tricky if you don’t want to run VS as admin. Unfortunately, tying this all together in the app requires a few more manual steps.

But before we get to the manual steps, let’s create the WinRT client app. Again, we’re going to create a new project but this time we’re going to select “Blank App (Windows)” from the Visual C# -> Store Apps -> Windows App node of the Add New Project dialog. Note, I’m not using “Blank App (Universal)” or “Blank App (Windows Phone)” because the brokered WinRT component feature is not support on Windows Phone. Call the client app project whatever you like, I’m calling mine “HelloWorldBRT.Client”.

Before we start writing code, we need to reference the brokered component. We can’t reference the brokered component directly or it will load in the sandboxed app process. Instead, the app need to reference a reference assembly version of the .winmd that gets generated automatically by the proxy/stub project. Remember in the last step when I said Kieran Mockford is an MSBuild wizard? The proxy/stub template project includes a custom target that automatically publishes the reference assembly winmd file used by the client app. When he showed me that, I was stunned – as I said, the man is a wizard. This means all you need to do is right click on the References node of the WinRT Client app project and select Add Reference. In the Reference Manager dialog, add a reference to the proxy/stub project you created in step two.

Now I can add the following code to the top of my App.OnLaunched function. Since this is a simple Hello World walkthru, I’m not going to bother to build any UI. I’m just going to inspect variables in the debugger. Believe me, the less UI I write, the better for everyone involved. Note, I’ve also added the P/Invoke signatures for GetCurrentProcess/ThreadID and to the client app like I did in the brokered component in step one. This way, I can get the process and thread IDs for both the app and broker process and compare them.

var pid = GetCurrentProcessId();
var tid = GetCurrentThreadId();

var c = new HelloWorldBRT.Class();
var bpid = c.CurrentProcessId;
var btid = c.CurrentThreadId;

At this point the app will compile, but if I run it the app will throw a TypeLoadException when it tries to create an instance of HelloWorldBRT.Class. The type can’t be loaded because the we’re using the reference assembly .winmd published by the proxy/stub project – it has no implementation details, so it can’t load. In order to be able to load the type, we need to declare the HelloWorldBRT.Class as a brokered component in the app’s pacakge.appxmanifest file. For non-brokered components, Visual Studio does this for you automatically. For brokered components we have to do it manually unfortunately. Every activatable class (i.e. class you can construct via “new”) needs to be registered in the appx manifest this way.

To register HelloWorldBRT.Class, right click the Package.appxmanifest file in the client project, select “Open With” from the context menu and then select “XML (Text) editor” from the Open With dialog. Then you need to insert inProcessServer extension that includes an ActivatableClass element for each class you can activate (aka has a public constructor). Each ActivatableClass element contains an ActivatableClassAttribute element that contains a pointer to the folder where the brokered component is installed. Here’s what I added to Package.appxmainfest of my HelloWorldBRT.Client app.

<Extensions>
  <Extension Category="windows.activatableClass.inProcessServer">
    <InProcessServer>
      <Path>clrhost.dll</Path>
      <ActivatableClass ActivatableClassId="HelloWorldBRT.Class" 
                        ThreadingModel="both">
        <ActivatableClassAttribute 
             Name="DesktopApplicationPath" 
             Type="string" 
             Value="D:\dev\HelloWorldBRT\Debug\HelloWorldBRT.PS"/>
      </ActivatableClass>
    </InProcessServer>
  </Extension>
</Extensions>

The key thing here is the addition of the DesktopApplicationPath ActivatableClassAttribute. This tells the WinRT activation logic that HelloWorldBRT.Class is a brokered component and where the managed .winmd file with the implementation details is located on the device. Note, you can use multiple brokered components in your side loaded app, but they all have the same DesktopApplicationPath.

Speaking of DesktopApplicationPath, the path I’m using here is path the final location of the proxy/stub components generated by the compiler. Frankly, this isn’t an good choice to use in a production deployment. But for the purposes of this walk thru, it’ll be fine.

ClientWatchWindow

Now when we run the app, we can load a HelloWorldBRT.Class instance and access the properties. re definitely seeing a different app process IDs when comparing the result of calling GetCurrentProcessId directly in App.OnLoaded vs. the result of calling GetCurrentProcessId in the brokered component. Of course, each run of the app will have different ID values, but this proves that we are loading our brokered component into a different process from where our app code is running.

Now you’re ready to go build your own brokered components! Here’s hoping you’ll find more interesting uses for them than comparing the process IDs of the app and broker processes in the debugger! :)

Categories: Architecture, Programming

Brokered WinRT Components Step Two

DevHawk - Harry Pierson - Fri, 04/25/2014 - 16:43

Now that we have built the brokered component , we have to build a proxy/stub for it. Proxies and stubs are how WinRT method calls are marshalled across process boundaries. If you want to know more – or you have insomnia – feel free to read all the gory details up on MSDN.

Proxies and stubs look like they might be scary, but they’re actually trivial (at least in the brokered component scenario) because 100% of the code is generated for you. It couldn’t be much easier.

Right click the solution node and select Add -> New Project. Alternatively, you can select File -> New -> Project in the Visual Studio main menu, but if you do that make sure you change the default solution from “Create new Solution” to “Add to Solution”. Regardless of how you launch the new project wizard, search for “broker” again, but this time select the “Brokered Windows Runtime ProxyStub” template. Give the project a name – I chose “HelloWorldBRT.PS”.

ProxyStubAddReferenceOnce you’ve created the proxy/stub project, you need to set a reference to the brokered component you created in step 1. Since proxies and stubs are native, this is a VC++ project. Adding a reference in a VC++ is not as straightforward as it is in C# projects. Right click the proxy/stub project, select “Properties” and then select Common Properties -> References from the tree on the left. Press the “Add New Reference…” button to bring up the same Add Reference dialog you’ve seen in managed code projects. Select the brokered component project and press OK.

Remember when I said that 100% of the code for the proxy/stub is generated? I wasn’t kidding – creating the template and setting referencing the brokered component project is literally all you need to do. Want proof? Go ahead and build now. If you watch the output windows, you’ll see a bunch of output go by referencing IDL files and MIDLRT among other stuff. This proxy/stub template has some custom MSBuild tasks that generates the proxy/stub code using winmdidl and midlrt. The process is similar to what is described here. BTW, if you get a chance, check out the proxy/stub project file – it is a work of art. Major props to Kieran Mockford for his msbuild wizardry.

ProxyStubRegisterOutputUnfortunately, it’s not enough just to build the proxy/stub – you also have to register it. The brokered component proxy/stub needs to be registered globally on the machine, which means you have to be running as an admin to do it. VS can register the proxy/stub for you automatically, but that means you have to run VS as an administrator. That always makes me nervous, but if you’re OK with running as admin you can enable proxy/stub registration by right clicking the proxy/stub project file, selecting Properties, navigating to Configuration properties -> Linker -> General in the tree of the project properties page, and then changing Register Output to “Yes”.

If you don’t like running VS as admin, you can manually register the proxy/stub by running “regsvr32 <proxystub dll>” from an elevated command prompt. Note, you do have to re-register every time the public surface area of your brokered component changes so letting VS handle registration admin is definitely the easier route to go.

In the third and final step, we’ll build a client app that accesses our brokered component.

Categories: Architecture, Programming

Brokered WinRT Components Step One

DevHawk - Harry Pierson - Fri, 04/25/2014 - 16:41

In this step, we’ll build the brokered component itself. Frankly, the only thing that makes a brokered component different than a normal WinRT component is some small tweaks to the project file to enable access to the full .NET Runtime and Base Class Library. The brokered component whitepaper describes the these tweaks in detail, but the new brokered component template takes care of these small tweaks for you.

BRT_NewProjectStart by selecting File -> New -> Project in Visual Studio. With the sheer number of templates to choose from these days, I find it’s easier to just search for the one I want. Type “broker” in the search box in the upper left, you’ll end up with two choices – the brokered WinRT component and the brokered WinRT proxy/stub. For now, choose the brokered component. We’ll be adding a brokered proxy/stub in step two. Name the project whatever you want. I named mine “HelloWorldBRT”.

This is probably the easiest step of the three as there’s nothing really special you have to do – just write managed code like you always do. In my keynote demo, this is where I wrote the code that wrapped the existing ADO.NET based data access library. For the purposes of this walkthrough, let’s do something simpler. We’ll use P/Invoke to retrieve the current process and thread IDs. These Win32 APIs are supported for developing WinRT apps and will make it obvious that the component is running in a separate process than the app. Here’s the simple code to retrieve those IDs (hat tip to pinvoke.net for the interop signatures):

public sealed class Class
{
    [DllImport("kernel32.dll")]
    static extern uint GetCurrentThreadId();

    [DllImport("kernel32.dll")]
    static extern uint GetCurrentProcessId();

    public uint CurrentThreadId
    {
        get { return GetCurrentThreadId(); }
    }

    public uint CurrentProcessId
    {
        get { return GetCurrentProcessId(); }
    }
}

That’s it! I didn’t even bother to change the class name for this simple sample.

Now, to be clear, there’s no reason why this code needs to run in a broker process. As I pointed out, the Win32 functions I’m wrapping here are supported for use in Windows Store apps. For this walkthrough, I’m trying to keep the code simple in order to focus on the specifics of building brokered components. If you want to see an example that actually leverages the fact that it’s running outside of the App Container, check out the NorthwindRT sample.

In the next step, we’ll add the proxy/stub that enables this component to communicate across a process boundary.

Categories: Architecture, Programming

Brokered WinRT Components Step-by-Step

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

Based on the feedback I’ve gotten since my keynote appearance @ Build – both in person and via email & twitter – there are a lot of folks who are excited about the Brokered WinRT Component feature. However, I’ve been advising folks to hold off a bit until the new VS templates were ready. Frankly, the developer experience for this feature is a bit rough and the VS template makes the experience much better. Well, hold off no longer! My old team has published the Brokered WinRT Component Project Templates up on the Visual Studio Gallery!

Now that the template is available, I’ve written a step-by-step guide demonstrating how to build a “Hello World” style brokered component. Hopefully, this will help folks in the community take advantage of this cool new feature in Windows 8.1 Update.

To keep it readable, I’ve broken it into three separate posts:

Note, this walkthrough assumes you’re running Windows 8.1 Update, Visual Studio 2013 with Update 2 RC (or later) and the Brokered WinRT Component Project Templates installed.

I hope this series helps you take advantage of brokered WinRT components. If you have any further questions, feel free to drop me an email or hit me up on Twitter.

Categories: Architecture, Programming

What Can Men Do?

Coding Horror - Jeff Atwood - Fri, 04/25/2014 - 09:06

(The title references Shanley Kane's post by the same name. This post represents my views on what men can do.)

It's no secret that programming is an incredibly male dominated field.

  • Figures vary, but somewhere from 20% to 29% of currently working programmers are female.

  • Less than 12% of Computer Science bachelor's degrees were awarded to women at US PhD-granting institutions in 2010.

So, on average, only about 1 out of every 5 working programmers you'll encounter will be female. You could say technology has a man problem.

In an earlier post I noted that many software developers I've known have traits of Aspergers. Aspergers is a spectrum disorder; the more severe the symptoms, the closer it is to autism. And did you know that autism skews heavily towards males at a 4:1 ratio?

Interesting. I might even go so far as to say some of those traits are what makes one good at programming.

That's the way it currently is. But is that the way it should be? I remember noticing that the workforce of the maternity ward at the hospital where our children were born was incredibly female dominated. Is there something inherently wrong with professions that naturally skew heavily male or female?

Consider this list of the most male and female dominated occupations in the Netherlands from 2004. It notes that:

In higher and academic level positions, men and women are more often represented equally. This pattern of employment has hardly changed over the last years.

Is programming a higher and academic level occupation? I'm not so sure, given that I've compared programmers to auto mechanics and plumbers in the past. And you'll notice squarely where those occupations are on the above graphs. There's nothing wrong with being an auto mechanic or a plumber (or a programmer, for that matter), but is there anything about those particular professions that demands, in the name of social justice, that there must be 50% male plumbers and 50% female plumbers?

For a counterpoint, here's a blog post from Sara J. Chipps. When I've e-mailed her in the past with my stupid questions on topics like this, she tries her best to educate me with empathy and compassion. That's why I love her.

This is an excerpt from a blog post she wrote in 2012 which answered my question:

Many people I meet ask me a variant of the question “I understand we want more women in technology, but why?” It’s a great question, and not at all something we should be offended by. Often men are afraid to ask questions like this for fear there will be backlash, and I think that fear can lead to stifling an important conversation.

Frankly, the Internet is thriving without women building it, why should that change? Three reasons:

1) Diversity leads to better products and results

As illustrated in this Cornell study along with many others, diversity improves performance, morale, and end product. More women engineers means building a better internet, and improving software that can service society as a whole. Building a better Internet is why I started doing software development in the first place. I think we can all agree this is of utmost importance.

2) The Internet is the largest recording of human history ever built

Right now the architecture for that platform is being built disproportionally by white and asian males. You’ve heard the phrase “he who writes history makes history”? We don’t yet know how this will affect future generations.

How can architecture be decidedly male? I like to refer to the anecdotal story of the Apple Store glass stairs. While visually appealing, there was one unforeseen consequence to their design: the large groups of strange men that spend hours each day standing under them looking up. As a woman, the first time I saw them I thought “thank god I’m not wearing a skirt today.” Such considerations were not taken in designing these stairs. I think it’s probable, if not easily predictable, that in a few years we will see such holes in the design of the web.

3) Women in 10 years need to be able to provide for themselves, and their families

Now, this reason is purely selfish on the part of women, but we all have mothers, and sisters, so I hope we can relate.

This year there are 6 million information technology jobs in the US, up from 628,600 in 1987 and 1.34 million in 1997. Right now jobs in technology have half the unemployment rate of the rest of the workforce. There is no sign this will change anytime soon. If growth continues at the current rate, it will not be long until women will not be able to sustain themselves if not involved in a technical field.

We have to start educating young girls about this now, or they may ultimately become the poorest demographic among us.

These are good reasons. I'm particularly fond of #1. Diversity in social perspectives is hugely valuable when building social software intended for, y'know, human beings of all genders, like Discourse and Stack Exchange. Also, I get really, really tired of all the aggressive mansplaining in software development. Yes, even my own. Sometimes it would be good to get some ladysplaining all mixed up in there for variety.

I suppose any effort to encourage more women to become software engineers should ideally start in childhood.

boy toys vs girl toys

Dolls? Pshaw. In our household, every child, male or female, is issued a regulation iPad at birth. You know, the best, most complex toy there is: a computer. And, shocker, I'm kind of weird about it – I religiously refer to it as a computer, never as an iPad. Never. Not once. Not gonna happen in my house. Branding is for marketing weasels. So the twin girls will run around, frantically calling out for their so-called "'puter". It puts a grin on my face every time. And when anything isn't here, Maisie has gotten in the habit of saying "dada chargin'". Where's the milk, Maisie? "dada chargin'".

But not everyone has the luxury of spawning their own processes and starting from boot. (You really should, though. It will kick your ass.)

What can you do?

If you're reading this, there's about an 80% chance that you're a man. So after you give me the secret man club handshake, let's talk about what we men can do, right now, today, to make programming a more welcoming profession for women.

  1. Abide by the Hacker School Rules

    Let's start with the freaking brilliant Hacker School rules. This cuts directly to the unfortunate but oh-so-common Aspergers tendencies in programmers I mentioned earlier:

    • No feigning surprise. "I can't believe you don't know what the stack is!"
    • No well-actuallys. "Well, actually, you can do that without a regular expression."
    • No back seat driving. Don't intermittently lob advice across the room.
    • No subtle sexism via public debate.

    Does any of this sound familiar? Because it should. Oh God does this sound familar. Just read the whole set of Hacker School guidelines and recognize your natural tendencies, and try to rein them in. That's all I'm proposing.

    Well, actually, I'll be proposing a few more things.

  2. Really listen. What? I SAID LISTEN.

    Remember this scene in Fight Club?

    This is why I loved the support groups so much, if people thought you were dying, they gave you their full attention. If this might be the last time they saw you, they really saw you. Everything else about their checkbook balance and radio songs and messy hair went out the window. You had their full attention. People listened instead of just waiting for their turn to speak. And when they spoke, they weren't just telling you a story. When the two of you talked, you were building something, and afterward you were both different than before.

    Guilty as charged.

    My wife is a scientist, and she complains about this happening a lot at her work. I don't even think this one is about sexism, it's about basic respect. What does respect mean? Well, a bunch of things, but let's start with openly listening to people and giving them our full attention when they talk to us – rather than just waiting for our turn to speak.

    Let's shut up and listen quietly with the same thoughtfulness that we wish others would listen to us. We'll get our turn. We always do, don't we?

  3. If you see bad behavior from other men, speak up.

    It's not other people's job to make sure that everyone enjoys a safe, respectful, civil environment at work and online.

    It's my job. It's your job. It is our job.

    There is no mythical men's club where it is OK to be a jerk to women. If you see any behavior that gives you pause, behavior that makes you wonder "is that OK?", behavior that you'd be uncomfortable with directed toward your sister, your wife, your daughter – speak up. Honestly, as one man to another. And if that doesn't work for whatever reason, escalate.

  4. Don't attempt romantic relationships at work.

    Do you run a company? Institute a no-dating rule as policy. Yeah, I know, you can't truly enforce it, but it should still be the official company policy. And whether the place where you work has this policy or not, you should have it on a personal level.

    I'm sorry I have to be that guy who dumps on true love, but let's be honest: the odds of any random office romance working out are pretty slim. And when it doesn't, how will you handle showing up to work every day and seeing this person? Will there be Capulet vs Montague drama? The women usually get the rough end of this deal, too, because men aren't good at handling the inevitable rejection.

    Just don't do it. Have all the romantic relationships you want outside work, but do not bring it to work.

  5. No drinking at work events.

    I think it is very, very unwise for companies to have a culture associated with drinking and the lowered inhibitions that come with drinking. I've heard some terrifyingly awful stories that I don't even want to link to here. Men, plus women, plus alcohol is a great recipe for college. That's about all I remember from college, in fact. But as a safe work environment for women? Not so much.

    If you want to drink, be my guest. Drink. You're a grown up. I'm not the boss of you. But don't drink in a situation or event that is officially connected with work in any way. That should absolutely be your personal and company policy – no exceptions.

There you have it. Five relatively simple things you, I, and all other working male programmers can do to help encourage a better environment for men and women in software plumbing. I mean engineering.

So let's get to it.

(I haven't listed anything here about mentoring. That's because I am an awful mentor. But please do feel free to mention good resources, like Girl Develop It, that encourage mentoring of female software engineers by people that are actually good at it, in the comments.)

[advertisement] How are you showing off your awesome? Create a Stack Overflow Careers profile and show off all of your hard work from Stack Overflow, Github, and virtually every other coding site. Who knows, you might even get recruited for a great new position!
Categories: Programming