Archive for the ‘Software Development Methodology’ Category

Ezra Schwartz, a friend of mine in the field of systems usability, asked me for some insights as to why there might be disconnects or methodological issues between traditional software and usability engineering activities.

Briefly my thoughts are along these lines – cognitive and cultural differences play a significant role in the successful recognition and adoption of usability precepts. For example, engineering is predominately a left brain activity, while usability is more right brain. Software engineers are looking to apply structure to realism as a means to systematically reaching the ends (need intellectual quotient – IQ- maturity for thinking). Usability engineers are looking to realism to structure in order add context to the content of the systems we use (need emotional quotient – EQ – maturity for feeling). In essence, Software Engineers are from Mars and Usability Engineers are from Venus.

In addition, there are cultural differences between a Western, Asian, Middle Eastern, Russian, and Indian perspective on usability. How we see the world and interact with its objects are highly dependent on how and where we where raised. Hofstede’s Cultural Dimensions (Dr. Geert Hofstede) recognizes that culture is more often a source of conflict than of synergy. Understanding how interactions between national cultures and organizational cultures are critical to being successful in multinational usability undertaking.

Here is a link to AxureWorld

Interesting. Yes?

Read Full Post »

This week, the top 30 US and international cyber security organizations (e.g., Red Hat, EMC, Apple, MSFT, NSA, etc.) jointly released the consensus list of the 25 most dangerous programming errors that lead to security bugs and that enable cyber espionage and cyber crime. What this joint team found was that most of these error were NOT well understood by programmers, across all types of organizations (big/small, insource/outsource, etc.). Equally important is that these errors are all appropriate for both SOA and SaaS developmental activities.

I think it important for use to share these findings with your development teams, assess our current developmental activities, and educate your teams on the principles found in this study. Also, we each have an have an opportunity to show some thought leadership and participate in a technical area that is not currently owned by too many organization. Below I have the link to SANS (information security authority) which not only contains the top 25 programming errors, but also an excellent set of resources (from Mitre) to help identify and address these issues.

Findings Ref: http://www.sans.org/top25errors/

Read Full Post »

If you have a chance, you should read the paper “Seven Deadly Sins of Software Project Management” by ExtremePlanner Software – it’s freely distributed as long as you don’t modify it in any way or charge for it. The paper covers several common pitfalls seem in most software development projects, but that isn’t the most insightful part of the paper.

What you really need to focus on is addressed on the summary page (pg. 2) and should be a wake-up call for all software developers:

1. “Two out of three software projects were delivered late, over budget or without all the
required features, according to a 2004 study by the Standish Group.”

– Studies have shown this to be more true than not. The question you should to ask is, “What is my success rate?” Chances are yours failure rate is higher, but you don’t know it. Why? Human psychology – we (human beings) tend to mostly remember only the good things that happen (successes) and suppress bad events (failures). This is why, for example, most “Las Vegas” gamblers think they are winners, when in fact it is the house that truly walks away victorious.

– Take a look at those projects that beat the 2 out of 3 odds. Has anybody actually studied them to identify those causal characteristics that put them into the 1 out of 3 category? Probably not. Should you? You bet! This few day exercise could save you time, money, and maybe even your job and/or company.

– Once you figure out which characteristics are casually resulting in success, how do you track them for all projects? While there are many approaches, one sure way is to move your organization up the maturity ladder to the point where all project are being managed vs. them managing you. One approach is to use the CMMI Capability Model to move to at least a Level 4 – managed level.

2. “Software projects are distinct from most other types of undertakings in that they often
involve creating something that has never been done before.”

– In addition to doing something that has never been done before, software is very “intangible.” That is, you never really see the assets that you are creating. You can’t touch software, it is very abstract. At the end the process we see what? The user interface – that 5% of code that we used to interact with the other 95% that is NEVER seen. Think about how abstract that actually is.

3. “Even mundane software solutions are faced with new technologies, increasingly demanding requirements for
uptime and scalability, a rapidly changing job market, and changing business needs.”

– Most projects are not about dealing with 1 or even 2 new concepts, it usually involves dealing with a lot of new moving parts. Projects fail because of the inherent uncertainty involved in complex systems. The more “new stuff” you add (e.g., new technology, new features, etc.), the more complex the system becomes; thus, increasing the overall chances for failure.

Again, the question becomes one of how to manage your way through this? I have some ideas about this and would like to hear from you, so please send me an email or post a reply.

Read Full Post »