Software Engineering, Project Management, and Effectiveness
This post is a simple way to browse the bulk of my patterns & practices work on MSDN and CodePlex. After I walk customers through things, the next question is usually, "OK, so where do we find this?" This is the link I'll be sharing.
Books / Guides
Practices at a Glance
Threats and Countermeasures
Questions and Answers
ASP.NET Security How Tos
WCF Security How Tos
Visual Studio Team System
My Related Posts
What is a PM (Program Manager)? While the Program Manager role seems unique to Microsoft, in general, when you map it to other companies, it’s a product manager, or a project manager, or a combination of the two. At Microsoft, there are various flavors of PMs (“design” PM, “project” PM, “process” PM, etc.) and the PM discipline can be very different in different groups. I’ve also seen the PM title used as a general job title, in the absence of something more specific.
At Microsoft it’s a role that means many things to many people. In general though, when you meet a PM at Microsoft, you expect somebody who has vision, can drive a project to completion, can manage scope and resources, coordinate work across a team, bridge the customer, the business, and the technology, act as a customer champ, and influence without authority. From a metaphor standpoint, they are often the hub to the spokes, they drive ideas to done, they take the ball and run with it, or find out who should run with the ball. Some PMs are better at thought leadership, some are better at people leadership, and the best are great at both.
Here is a roundup of some of my favorite points that elaborate, clarify, and distill what a PM is, what a PM does, and how to be one.
Attributes and Qualities of a PM Here is a list of key attributes from Steven Sinofsky’s post -- PM at Microsoft:
Here is an example of PM qualities from Sean Lyndersay’s post -- Exchange team defines a Program Manager:
Microsoft Careers site on Program Manager Here is a description of a Program Manager from the Microsoft Careers site: “As a Program Manager, you’ll drive the technical vision, design, and implementation of next-generation software solutions. You’ll transform the product vision into elegant designs that will ultimately turn into products used by Microsoft customers. Managing feature sets throughout the product lifecycle, you’ll have the chance to see your design through to completion. You’ll also work directly with other key team members including Software Development Engineers and Software Development Engineers in Test. Program Managers are advocates for end-users, so your passion for anticipating customer needs and creating outside-the-box solutions for them will really help you shine in this role. As a Program Manager you will have the ability to lead within a product’s life cycle using evangelism, empathy, and negotiation to define and deliver results. You will also be responsible for authoring technical specifications, including envisaged usage cases, customer scenarios, and prioritized requirements lists.”
Chris Pratley on Program Manager Here are some points on Program Management from Chris Pratley’s post -- Program Manager:
Here are the stages of your first year as a PM, according to Pratley:
Joel Spolsky on Program Manager Here are points from Joel’s post on How To Be a Program Manager:
Ray Schraff on Program Manager Here are point from the comments on Chris Pratley’s post, Program Management:
Sean Lyndersay on Program Manager
Steven Sinofsky on Program Manager Here are points from Sinfoksy’s post on PM at Microsoft:
As part of our patterns & practices App Arch Guide 2.0 project, we're consolidating our information on our patterns & practices Performance Engineering. Our performance engineering approach is simply a collection of performance-focused techniques that we found to be effective for meeting your performance objectives. One of the keys to the effectiveness is our performance frame. Our performance frame is a collection of "hot spots" that organize principles, patterns, and practices, as well as anti-patterns. We use the frame to perform effective performance design and code inspections. Here's a preview of our cheat sheet so far. You'll notice a lot of similarity with our patterns & practices Security Engineering. It's by design so that you can use a consistent approach for handling both security and performance.
Performance Overlay This is our patterns & practices Performance Overlay:
Key Activities in the Life Cycle This Performance Engineering approach extends these proven core activities to create performance specific activities. These include:
Performance Frames Performance Frames define a set of patterns-based categories that can organize repeatable problems and solutions. You can use these categories to divide your application architecture for further analysis and to help identify application performance issues. The categories within the frame represent the critical areas where mistakes are most often made.
Architecture and Design Issues Use the diagram below to help you think about performance-related architecture and design issues in your application.
The key areas of concern for each application tier are:
Design Process Principles Consider the following principles to enhance your design process:
Design Guidelines This table represents a set of secure design guidelines for application architects. Use this as a starting point for performance design and to improve performance design inspections.
As part of creating an "information architecture" for developer guidance at Microsoft, one of the tasks means mapping out what we already have. That means mapping out out our Microsoft developer content assets across Channel9, MSDN Developer Centers, MSDN Library, Code Gallery, CodePlex, the All-in-One Code Framework, etc.
You can browse our Developer Guidance Maps at http://innovation.connect.microsoft.com/devguidancemaps
One of my favorite features is the one-click access that bubbles up high value code samples, how tos, and walkthroughs from the product documentation. Here is an example of showcasing the ASP.NET documentation team’s ASP.NET Product Documentation Map. Another of my favorite features is one-click access to consolidated training maps. Here is an example showcasing Microsoft Developer Platform Evangelism’s Windows Azure Training Map.
Content Types Here are direct jumps to pages that let you browse by content type:
Developer Guidance Maps Here are direct jumps to specific Developer Guidance maps:
The Approach Rather than boil the ocean, so we’ve used a systematic and repeatable model. We’ve focused on topics, features, and content types for key technologies. Here is how we prioritized our focus:
The Maps are Works in Progress Keep in mind these maps are works in progress and they help us pressure test our simple information architecture (“Simple IA”) for developer guidance at Microsoft. Creating the maps helps us test our models, create a catalog of developer guidance, and easily find the gaps and opportunities. While the maps are incomplete, they may help you find content and sources of content that you didn’t even know existed. For example, the All-In-One Code Framework has more than 450 code examples that cover 24 Microsoft development technologies such as Windows Azure, Windows 7, Silverlight, etc. … and the collection grows by six samples per week.
Here’s another powerful usage scenario. Use the maps as a template to create your own map for a particular technology. By creating a map or catalog of content for a specific technology, and organizing it by topic, feature, and content type, you can dramatically speed up your ability to map out a space and leverage existing knowledge. (… and you can share your maps with a friend ;)
patterns & practices Enterprise Library 5.0 is now available on MSDN. Microsoft Enterprise Library (EntLib) is a collection of application blocks (reusable software components) designed to address common cross-cutting concerns (data access, exception handling, logging, validation, ...etc.) EntLib provides source code, test cases, and docs that you can use "as is" or extend as you see fit. The goal of EntLib is to codify Microsoft recommended and proven practices for .NET application development.
What's New in 5.0 Enterprise Library 5.0 brings the following to the table:
Serena Yeoh just released her Layer Architecture Sample for .NET 4.0 (July 2010), which targets the .NET Framework 4.0. Serena is one of our MCS (Microsoft Consultant Services) consultants in the field working with customers on a regular basis, and she was a key contributor of our Microsoft patterns & practices Application Architecture Guide.
Here is a description of the project according to Serena: The Layered Architecture Sample is designed to demonstrate how to apply various .NET Technologies such as Windows Presentation Foundation (WPF), Windows Communication Foundation (WCF), Windows Workflow Foundation (WF), Windows Form, ASP.NET and ADO.NET Entity Framework to the Layered Architecture Design Pattern. It is aimed at illustrating how code of similar responsibilities can be factored into multiple logical layers which are applicable in most of today's enterprise applications. The primary objective of the sample is to focus on layering and therefore, certain cross-cutting functionalities have been omitted to maintain its simplicity.
What’s New for This Version of the Sample
I’ll be curious to hear three things you like about it and three things you would improve?
For this week's release in our patterns & practices WCF Security Guidance project, we released our first version of our WCF 3.5 Security Guidelines. Each guideline is a nugget of what to do, why, and how. The goal of the guideline format is to take a lot of information, compress it down, and turn insight into action.
The downside is that it's tough to create prescriptive guidelines that are generic enough to be reusable, but specific enough to be helpful. The upside is that customers find the guidelines help them cut through a lot of information and take action. We contextualize the guidelines as much as we can, but ultimately you're in the best position to do the pattern matching to find which guidelines are relevant for your scenarios, and how you need to tailor them.
Here's a snapshot of the guidelines, but you can see our security guidelines explained at our WCF Security Guidance project site.
CategoriesOur WCF Security guidelines are organized using the following buckets:
Auditing and Logging
Impersonation and Delegation
I was looking for examples of persona templates, and I came across Personas: Moving Beyond Role-Based Requirements Engineering by Randy Miller and Laurie Williams. I found it to be insightful and practical. I also like the fact they included a snapshot of a persona template example from MSF Agile ...
MSF Agile Persona Template
As part of our patterns & practices App Arch Guide 2.0 project, we're consolidating our information on our patterns & practices Security Engineering. Our security engineering approach is simply a collection of security-focused techniques that we found to be effective. One of the keys to the effectiveness is our security frame. Our security frame is a collection of "hot spots" that organize principles, patterns, and practices, as well as anti-patterns. We use the frame to perform security code and design inspections. Here's a preview of our cheat sheet so far.
Security OverlayThis is our patterns & practices Security Overlay:
It simply shows a common set of activities that customers already do, and then we overlay a set of security techniques.
Summary of Key Activities in the Life Cycle Our patterns & practices Security Engineering approach extends these proven core activities to create security specific activities. These activities include:
Security FrameSecurity frames define a set of patterns-based categories that can organize repeatable problems and solutions. You can use these categories to divide your application architecture for further analysis and to help identify application vulnerabilities. The categories within the frame represent the critical areas where mistakes are most often made.
When a method call in your application fails, what does your application do? How much do you reveal? Do you return friendly information to end users? Do you pass valuable exception information back to the caller? Does your application fail gracefully?
Architecture and Design IssuesUse the diagram below to help you think about architecture and design issues in your application.
Design GuidelinesThis table represents a set of secure design guidelines for application architects. Use this as a starting point for secure design and to improve security design inspections
PatternsDesign patterns in this context refer to generic solutions that address commonly occurring application design problems. Some of the patterns identified below are well known design patterns. Their use in certain scenarios enables better security as a secondary goal. Some of the main patterns that help improve security are summarized below:
Cloud computing is hot. As customers makes sense of what the Microsoft cloud story means to them, one of the first things they tend to do is look for case studies of the Microsoft cloud platform. They like to know what their peers, partners, and other peeps are doing.
Internally, I get to see a lot of what our customers are doing across various industries and how they are approaching the cloud behind the scenes. It’s amazing the kind of transformations that cloud computing brings to the table and makes possible. Cloud computing is truly blending and connecting business and IT (Information Technology), and it’s great to see the connection. In terms of patterns, customers are using the cloud to either reduce cost, create new business opportunities and agility, or compete in ways they haven’t been able to before. One of the most significant things cloud computing does is force people to truly understand what business they are in and what their strategy actually is.
Externally, luckily, we have a great collection of Microsoft cloud case studies available at Windows Azure Case Studies.
I find having case studies of the Microsoft cloud story makes it easy to see patterns and to get a sense of where some things are going. Here is a summary of some of the case studies available, and a few direct links to some of the studies.
Advertising Industry Examples of the Microsoft cloud case studies in advertising:
Air Transportation Services Examples of the Microsoft cloud case studies in air transportation services:
Capital Markets and Securities Industry Examples of the Microsoft cloud case studies in capital markets and securities:
Education Examples of the Microsoft cloud case studies in education:
Employment Placement Agencies Examples of the Microsoft cloud case studies in employment agencies:
Energy and Environmental Agencies Examples of the Microsoft cloud case studies in enery and environmental agencies:
Financial Services Industry Examples of the Microsoft cloud case studies in the financial services industry:
Food Service Industry Examples of the Microsoft cloud case studies in the food service industry:
Government Agencies Examples of the Microsoft cloud case studies in government agencies:
Healthcare Industry Examples of the Microsoft cloud case studies in healthcare:
High Tech and Electronics Manufacturing Examples of the Microsoft cloud case studies in high tech and electronics manufacturing:
Hosting Examples of the Microsoft cloud case studies in hosting:
Insurance Industry Examples of the Microsoft cloud case studies in the insurance industry:
IT Services Examples of the Microsoft cloud case studies in IT services:
Life Sciences Examples of the Microsoft cloud case studies in life sciences:
Manufacturing Examples of the Microsoft cloud case studies in manufacturing:
Media and Entertainment Industry Examples of the Microsoft cloud case studies in media and entertainment:
Metal Fabrication Industry Examples of the Microsoft cloud case studies in metal fabrication:
Nonprofit Organizations Examples of the Microsoft cloud case studies in non-profit organizations:
Oil and Gas Industry Examples of the Microsoft cloud case studies in oil and gas:
Professional Services Examples of the Microsoft cloud case studies in professional services:
Publishing Industry Examples of the Microsoft cloud case studies in publishing:
Retail Industry Examples of the Microsoft cloud case studies in retail:
Software Engineering Examples of the Microsoft cloud case studies in software:
Telecommunications Industry Examples of the Microsoft cloud case studies in telecommunications:
Training Industry Examples of the Microsoft cloud case studies in training:
Transportation and Logistics Industry Examples of the Microsoft cloud case studies in transportation:
Here is a quick map of the process groups, knowledge areas, and processes in the PMBOK (Project Management Body of Knowledge). Regardless of the PMI certification, I think it’s useful to know how the knowledge for project management is organized by experts and professionals. This will help you more effectively navigate the space, and learn project management at a faster pace, because you can better organize the information in your mind.
If you are a program manager or a project manager, the categories are especially helpful for checking your knowledge and for thinking of projects more holistically. You can also use the knowledge areas to grow your skills by exploring each area and building your catalog of principles, patterns, and practices.
Process Groups and Knowledge Areas Here is a quick map of the process groups and knowledge areas in the Project Management Body of Knowledge:
Knowledge Areas and Processes Here is a quick topology view of the Knowledge Areas and the processes:
Project Integration Management
Project Scope Management
Project Time Management
Project Cost Management
Project Quality Management
Project Human Resource Management
Project Communication Management
Project Risk Management
Project Procurement Management
We published an updated set of our WCF Security application scenarios yesterday, as part of our patterns & practices WCF Security guidance project. Application Scenarios are visual "blueprints" of skeletal solutions for end-to-end deployment scenarios. Each application scenario includes a before and after look at working solutions. While you still need to prototype and test for your scenario, this gives you potential solutions and paths at a glance, rather than starting from scratch. It's a catalog of applications scenarios that you can look through and potentially find your match.
IntranetCommon Intranet patterns:
Internet Common Internet patterns:
One Size Does Not Fit AllWe know that one size doesn't fit all, so we create a collection of application scenarios that you can quickly sort through and pattern match against your scenario. It's like a visual menu at a restaurant. The goal is to find a good fit against your parameters versus a perfect fit. It gives you a baseline to start from. They effectively let you preview solutions, before embarking on your journey.
How We Make Application ScenariosFirst, we start by gathering all the deployment scenarios we can find from customers with working solutions. We use our field, product support, product teams, subject matter experts, and customers. We also check with our internal line of business application solutions. While there's a lot of variations, we look for the common denominators. There's only so many ways to physically deploy servers, so we start there. We group potential solutions by big buckets.
In order to make the solutions meaningful, we pick a focus. For example, with WCF Security, key overarching decisions include authentication, authorization, and secure communication. These decisions span the layers and tiers. We also pay attention to factors that influence your decisions. For example, your role stores and user stores are a big factor. The tricky part is throwing out the details of customer specific solutions, while retaining the conceptual integrity that makes the solution useful.
Next, we create prototypes and we test the end-to-end scenarios in our lab. We do a lot of whiteboarding during this stage for candidate solutions. This is where we spend the bulk of our time, testing paths, finding surprises, and making things work. It's one thing to know what's supposed to work; it's another to make it work in practice.
From our working solution, we highlight the insights and actions within the Application Scenario so you can quickly prototype for your particular context. We then share our candidate guidance modules on CodePlex, while we continue reviews across our review loops including field, PSS, customers, product team members, and subject matter experts.
Cloud security has been a hot topic with the introduction of the Microsoft offering of the Windows Azure platform. One of the quickest ways to get your head around security is to cut to the chase and look at the threats, attacks, vulnerabilities and countermeasures. This post is a look at threats and countermeasures from a technical perspective.
The thing to keep in mind with security is that it’s a matter of people, process, and technology. However, focusing on a specific slice, in this case the technical slice, can help you get results. The thing to keep in mind about security from a technical side is that you also need to think holistically in terms of the application, network, and host, as well as how you plug it into your product or development life cycle. For information on plugging it into your life cycle, see the Security Development Lifecycle.
While many of the same security issues that apply to running applications on-premise also apply to the cloud, the context of running in the cloud does change some key things. For example, it might mean taking a deeper look at claims for identity management and access control. It might mean rethinking how you think about your storage. It can mean thinking more about how you access and manage virtualized computing resources. It can mean thinking about how you make calls to services or how you protect calls to your own services.
Here is a fast path through looking at security threats, attacks, vulnerabilities, and countermeasures for the cloud …
Overview It is important to think like an attacker when designing and implementing an application. Putting yourself in the attacker’s mindset will make you more effective at designing mitigations for vulnerabilities and coding defensively. Below is the cloud security frame. We use the cloud security frame to present threats, attacks, vulnerabilities and countermeasures to make them more actionable and meaningful.
You can also use the cloud security frame to effectively organize principles, practices, patterns, and anti-patterns in a more useful way.
Threats, Attacks, Vulnerabilities, and Countermeasures These terms are defined as follows:
Cloud Security Frame The following key security concepts provide a frame for thinking about security when designing applications to run on the cloud, such as Windows Azure. Understanding these concepts helps you put key security considerations such as authentication, authorization, auditing, confidentiality, integrity, and availability into action.
Threats and Attacks
SDL Considerations For more information on preferred encryption algorithms and key lengths, see the Security Development Lifecycle at http://www.microsoft.com/security/sdl/ .
As part of our patterns & practices Azure Security Guidance project, we’re putting together a series of Application Scenarios and Solutions. Our goal is to show the most common application scenarios on the Microsoft Azure platform. This is your chance to give us feedback on whether we have the right scenarios, and whether you agree with the baseline solution.
ASP.NET Security Scenarios on Windows Azure We’re taking a crawl, walk, run approach and starting with the basic scenarios first. This is our application scenario set for ASP.NET:
ASP.NET Forms Auth to Azure Storage
Solution Summary Table
ASP.NET Forms Authentication to SQL Azure
ASP.NET to AD with Claims
ASP.NET to AD with Claims (Federation)
As part of our patterns & practices Application Architecture Guide 2.0 project, we've been hunting and gathering our patterns from across our patterns & practices catalog. Here's an initial draft of our patterns & practices Patterns Catalog at a Glance:
Pattern Catalog To collect the patterns, we first identified the key projects that focused on patterns:
Next, we organized the patterns and summarized in tables. You can browse the tables below to see which patterns are associated with which project.
Composite Application Guidance for WPF
Enterprise Solution Patterns
Web Services Security Patterns
Pattern Summaries The following pattern summaries are brief descriptions of each pattern, along with a link to the relevant MSDN pages.
Data Movement Patterns
Enterprise Solution Patterns
Performance and Reliability
Web Presentation Patterns
Web Service Services Security Patterns
Message Replay Detection
One of the most common questions I get with Getting Results the Agile Way is, “What tools do I use to implement it?”
The answer is, it depends on how "lightweight" or "heavy" I need to be for a given scenario. The thing to keep in mind is that the system is stretch to fit because it's based on a simple set of principles, patterns, and practices. See Values, Principles, and Practices of Getting Results the Agile Way.
That said, I have a few key scenarios:
The Just Me Scenario In the "Just Me" scenario, I don't use any tools. I just take "mental notes." I use The Rule of Three to identify three outcomes for the day. I simply ask the question, "What are the three most important results for today?" Because it's three things, it's easy to remember, and it helps me stay on track. Because it's results or outcomes, not activities, I don't get lost in the minutia.
The Pen and Paper Scenario In the Pen and Paper scenario, I carry a little yellow sticky pad. I like yellow stickies because they are portable and help me free up my mind by writing things down. The act of writing it down, also forces me to get a bit more clarity. As a practice, I either write the three results I want for the day on the first note, or I write one outcome per note. The main reason I write one result per sticky note is so that I can either jot supporting notes, such as tasks, or so I can throw it away when I've achieve that particular result. It's a simple way to game my day and build a sense of progress.
I do find that writing things down, even as a simple reference, helps me stay on track way more than just having it in my head.
The Evernote Scenario The Evernote scenario is my high-end scenario. This is for when I'm dealing with multiple projects, leading teams, etc. It's still incredibly light-weight, but it helps me stay on top of my game, while juggling many things. It also helps me quickly see when I have too much open work, or when I'm splitting my time and energy across too many things. It also helps me see patterns by flipping back through my daily outcomes, weekly outcomes, etc.
It's hard to believe, but already I've been using Evernote with Getting Results the Agile Way for years. I just checked the dates of my daily outcomes, and I had switched to Evernote back in 2009. Time sure flies. It really does.
Anyway, I put together a simple step-by-step How To to walk you through setting up Getting Results the Agile Way in Evernote. Here it is:
OneNote If you’re a OneNote user, and you want to see how to use Getting Results the Agile Way with OneNote, check out Anu’s post on using Getting Results the Agile Way with OneNote.
If you’re a Silverlight developer or you want to learn Silverlight, this map is for you. Microsoft has an extensive collection of developer guidance available in the form of Code Samples, How Tos, Videos, and Training. The challenge is -- how do you find all of the various content collections? … and part of that challenge is knowing *exactly* where to look. This is where the map comes in. It helps you find your way around the online jungle and gives you short-cuts to the treasure troves of available content.
The Silverlight Developer Guidance Map helps you kill a few birds with one stone:
Download the Silverlight Developer Guidance Map
Contents at a Glance
Mental Model of the Map The map is a simple collection of content types from multiple sources, organized by common tasks, common topics, and Silverlight features:
Special Thanks … Special thanks to Jesse Liberty, Joe Stagner, Paul Enfield, Pete Brown, Sam Landstrom, and Scott Hanselman for helping me find and round up our various content collections.
Enjoy and share the map with a friend.
Extreme Programming (XP) is a lightweight software development methodology based on principles of simplicity, communication, feedback, and courage. I like to be able to scan methodologies to compare approaches. To do so, I create a skeleton of the activities, artifacts, principles, and practices. Here are my notes on XP:
12 Practices Here's the 12 XP practices:
For a visual of the XP practices, see a picture of the Practices and Main Cycles of XP.
5 Values (Extreme Programming Explained)
Phases The following are phases of an XP project life cycle.
For a visual overview, see Agile Modeling Throughout the XP Lifecycle.
These are the 12 Agile principles according to the Agile Manifesto:
These are the four Agile values according to the Agile Manifesto:
As part of our patterns & practices Application Architecture Guide 2.0 project, we've been hunting and gathering our patterns & practices solution assets. Here's our initial draft of our catalog at a glance:
You can use it to get a quick sense of the types and range of solution assets from blocks to guides.
Architecture Meta-Frame We used our Architecture Meta-Frame (AMF) as a lens to help slice and dice the catalog:
Here's some examples to illustrate:
The frame is easily extensible. For example, if we include our Engineering Practices Frame, we can group our process, activity, and artifact related guidance.
Catalog at a Glance Here's a quick list of key patterns & practices solution assets at a glance:
Application Types Guidance assets listed by application type.
My Related Posts
Building software involves a lot of communication. Behind this communication, lies perspectives. These perspectives often get lost somewhere between initial goals and final product, which can lead to failed software. I found that by using a simple Perspectives Frame, I improve my chances for success.
In PracticeI could easily over-engineer it, but in meetings and hallways, this quick, memorable frame of four categories helps. OK, so it looks simple enough, but how do I use it? Here's how I use it in practice:
This perspectives frame becomes even more powerful when you combine it with MUST vs. SHOULD vs. COULD and What Are You Optimizing.
Do you have to be great at everything? If this stops you from doing things you want to try, then it's a limiting belief. Scott Berkun spells this out in Why You Should Be Bad at Something.
Keys to Growing Your SkillsHere's a set of practices and mind-sets that I've found to be effective for getting in the game, or getting back in the game, or learning a new game versus just watching from the side-lines.
There's a lot more I could say, but I think this is bite-sized working set to chew on for now.
I mentor several folks on how to make money online, either because they are trying to supplement their income, or take their game to the next level, or simply trying to reduce the worry around losing their job.
An interesting pattern is that many of the folks that I know that make a second (3rd, 4th, 5th) income online, show up strong in many ways. Their second source of income is always a “passion business.” They find a way to monetize what they love in a way that’s sustainable and creates a ton of value for their tribe of raving fans.
They end up spending more time in their art, so they recharge and renew, and show up fresh at work because they found a way to spend more time doing what they love (it’s an interesting question when you ask the question, “What do you want to spend more time doing?”, and then actually do it
One of the most important success patterns I see is that people do what they would do for free, but pay attention to what people would pay them for. This does two things:
I see people succeed at making money online by doing lots of experimentation and continuous learning. The ones that do the best, learn from success AND failures. The ones that create truly outstanding success, learn the patterns of failure to avoid, and the patterns of success to do more of.
Lucky for me, I got to see several people right around me making $10,000, $20,000, etc. a month online, and they happily shared with me what they were doing, including what was working and what was not. The variety was pretty amazing, until I started to see the patterns. As I started to see the patterns, what surprised me the most is how so many people fail to make money online because “they try to make money online” – it’s like chasing happiness, and having it always evade your grasp.
There are so many ways NOT to make money online. In fact, they are worth enumerating because people still try them and get incredibly frustrated and give up.
Here are 50 Ways How NOT To Make Money Online.
It’s serious stuff.
I took a pattern-based approach, so that it’s easy to see the principle behind each recipe for failure.
You can actually apply many of the insights whether it’s an online or offline business, and whether you are a one-man band, or a business partnership, or working in a corporation.
It puts a distillation of many business basics, great business lessons, and business skills at your fingertips.
I’m hoping that more people can be entrepreneurs and create their financial freedom by doing more of what they love, in a business-smart way.
Also, I’m hoping this helps more people get their head around the idea that we’re in a new digital economy and the ways to make a living are changing under our feet.
The future is here and it belongs to those that create it and shape it.
Own your destiny.
I added a set of my favorite motivation quotes to Sources of Insight. You never know where you might find just the inspiration you need.
If it’s not broken, then don’t fix it ...
The problem is, you may have an approach that isn’t working, or it’s not as efficient as it could be, but you may not even know it. Let’s take a quick look at some broken approaches and get to the bottom of why they fail. If you understand why they fail, you can then take a look at your own approach and see what, if anything, you need to change. The more prevalent broken approaches include:
The Bolt on ApproachMake it work, and then make it right. This is probably the most common approach to security that I see, and it almost always results in failure or at least inefficiency. This approach results in a development process that ignores security until the end, usually the testing phase, and then tries to make up for mistakes made earlier in the development cycle. This is one way of addressing security. This is effectively the bolt on approach.
The assumption is that you can bolt on security at the end, just enough to get the job done. While the bolt on approach is a common practice, the prevalence of security issues you can find in Web applications that use this approach, is not a coincidence.
The real weakness in the bolt on approach is that some of the more important design decisions that impact the security of your application have a cascading impact on the rest of your application’s design. If you’ve made a poor decision early in design, later you will be faced with some unpleasant choices. You can either cut corners, further degrading security, or you can extend the development of your application missing project deadlines. If you make your most important security design decisions at the end, how can you be confident you’ve implemented and tested your application to meet your objectives?
The Do It All Up Front ApproachThe opposite of the bolt on approach is the do it all up front approach. In this case, you attempt to address all of your security design up front. There are two typical failure scenarios:
While considering security up front is a wise choice, you can’t expect to do it all at once. For one thing, you can’t expect to know everything up front. More importantly, this approach is not as capable of dealing with decisions throughout the application development that affect security, as an approach that integrates security consideration throughout the life cycle.
The Big Bang ApproachThis can be similar to the do it all up front approach. The big bang approach is where you depend on a single big effort, technique or activity to produce all of your security results. Depending on where you drop your hammer, you can certainly accomplish some security benefits, if some security effort is better than none. However, similar to the do it all up front approach, a small set of focused activities outshines the single big bang.
The typical scenario is a shop that ignores security (or pays it less than the optimal amount of attention) until the test phase. Then they spend a lot of time/money on a security test pass that tells them all the things that are wrong. They then make hard decisions on what to fix vs. what to leave and try to patch an architecture that wasn’t designed properly for security in the first place.
The Buckshot ApproachThe buckshot approach is where you try a bunch of security techniques on your application, hoping you somehow manage to hit the right ones. For example, it’s common to hear, “we’re secure, we have a firewall”, or “we’re secure, we’re using SSL”. The hallmark of this approach is that you don’t know what your target is and the effort expended is random and without clear benefit. Beware the security zealot who is quick to apply everything in their tool belt without knowing what the actual issue is they are defending against. More security doesn’t necessarily equate to good security. In fact, you may well be trading off usability or maintainability or performance, without improving security at all.
You can’t get the security you want without a specific target. Firing all over the place (with good weapons even) isn’t likely to get you a specific result. Sure you’ll kill stuff but who knows what.
The All or Nothing ApproachWith the all or nothing approach, you used to do nothing to address security and now you do it all. Over-reacting to a previous failure is one reason you might see a switch to “All”. Another is someone truly trying to do the best they can to solve a real problem and not realizing they are biting off more than they can chew.
While it can be a noble effort, it’s usually a path to disaster. There are multiple factors, aside from your own experience, that impact success, including maturity of your organization and buy in from team members. Injecting a dramatic change helps get initial momentum, but, if you take on too much at once, you may not create a lasting approach, and will eventually fall back to doing nothing.
Whether I'm dealing with software requirements, or I'm prioritizing my personal TO Dos, I think in terms of MUST, SHOULD, COULD. It's simpple but effective.
Here's an example of some scenarios and usage:
It's easy to get lost among SHOULDs and COULDs. I find factoring MUSTs from the SHOULDs and COULDs helps get clarity around immediate action.