Software Engineering, Project Management, and Effectiveness
While I've been quiet on my blog, we've been busy behind the scenes. Here's a rundown on key things:
I'll have more to say soon.
Inspections are among my favorite tools for improving security. I like them because they’re so effective and efficient. Here’s why:
Bottom line -- you can identify, catalog and share security criteria faster than new security issues come along.
Security FrameOur Security Frame is simply a set of categories we use to “frame” out, organize, and chunk up security threats, attacks, vulnerabilities and countermeasures, as well as principles, practices and patterns. The categories make it easy to distill and share the information in a repeatable way.
Security Design InspectionsPerforming a Security Design Inspection involves evaluating your application’s architecture and design in relation to its target deployment environment from a security perspective. You can use the Security Frame to help guide your analysis. For example, you can walk the categories (authentication, authorization, … etc.) for the application. You can also use the categories to do a layer-by-layer analysis. Design inspections are a great place to checkpoint your core strategies, as well as identify what sort of end-to-end tests you need to verify your approach.
Here's the approach in a nutshell:
For more information, see our patterns & practices Security Design Inspection Index.
Security Code InspectionsThis is truly a place where inspections shine. While static analysis will catch a lot of the low hanging fruit, manual inspection will find a lot of the important security issues that are context dependent. Because it’s a manual exercise, it’s important to set objectives, and to prioritize based on what you’re looking for. Whether you do your inspections in pairs or in groups or individually, checklists in the form of criteria or inspection questions are helpful.
For more information on Security Code Inspections, see our patterns & practices Security Code Inspection Index. For examples of “Inspection Questions”, see Security Question List: Managed Code (.NET Framework 2.0) and Security Question List: ASP.NET 2.0.” (Security Question List: ASP.NET 2.0).
Security Deployment InspectionsDeployment Inspections are particularly effective for security because this is where the rubber meets the road. In a deployment inspection, you walk the various knobs and switches that impact the security profile of your solution. This is where you check things such as accounts, shares, protocols, … etc.
The following server security categories are key when performing a security deployment inspection:
For more information, see our patterns & practices Security Deployment Inspection Index.
My Related Posts
In this post, I'll focus on design, code, and deployment inspections for performance. Inspections are a white-box technique to proactively check against specific criteria. You can integrate inspections at key stages in your life cycle, such as design, implementation and deployment.
Keys to Effective Inspections
Performance FrameThe Performance Frame is a set of categories that helps you organize and focus on performance issues. You can use the frame to organize principles, practices, patterns and anti-patterns. The categories are also effective for organizing sets of questions to use during inspections. By using the categories in the frame, you can chunk up your inspections. The frame is also good for finding low-hanging fruit.
Performance Design InspectionsPerformance design inspections focus on the key engineering decisions and strategies. Basically, these are the decisions that have cascading impact and that you don't want to make up on the fly. For example, your candidate strategies for caching per user and application-wide data, paging records, and exception management would be good to inspect. Effective performance design inspections include analyzing the deployment and infrastructure, walking the performance frame, and doing a layer-by-layer analysis. Question-driven inspections are good because they help surface key risks and they encourage curiosity.
While there are underlying principles and patterns that you can consider, you need to temper your choices with prototypes, tests and feedback. Performance decisions are usually trade-offs with other quality attributes, such as security, extensibility, or maintainability. Performance Modeling helps you make trade-off decisions by focusing on scenarios, goals and constraints.
For more information, see Architecture and Design Review of a .NET Application for Performance and Scalability and Performance Modeling.
Performance Code InspectionsPerformance code inspections focus on evaluating coding techniques and design choices. The goal is to identify potential performance and scalability issues before the code is in production. The key to effective performance code inspections is to use a profiler to localize and find the hot spots. The anti-pattern is blindly trying to optimize the code. Again, a question-driven technique used in conjunction with measuring is key.
For more information, see Performance Code Inspection.
Performance Deployment InspectionsPerformance deployment inspections focus on tuning the configuration for your deployment scenario. To do this, you need to have measurements and runtime data to know where to look. This includes simulating your deployment environment and workload. You also need to know the knobs and switches that influence the runtime behavior. You also need to be bounded by your quality of service requirements so you know when you're done. Scenarios help you prioritize.
Inspections are a white-box technique to proactively check against specific criteria. You can integrate inspections as part of your testing process at key stages, such as design, implementation and deployment.
Design InspectionsIn a design inspection, you evaluate the key engineering decisions. This helps avoid expensive do-overs. Think of inspections as a dry-run of the design assumptions. Here’s some practices I’ve found to be effective for design inspections:
Code InspectionsIn a code inspection, you focus on the implementation. Code inspections are particularly effective for finding lower-level issues, as well as balancing trade-offs. For example, a lot of security issues are implementation level, and they require trade-off decisions. Here’s some practices I’ve found to be effective for code inspections:
Deployment InspectionsDeployment is where application meets infrastructure. Deployment inspections are particularly helpful for quality attributes such as performance, security, reliability and manageability concerns. Here’s some practices I’ve found to be effective for deployment inspections:
In the future, I'll post some more specific techniques for security and performance.
When I review an approach, I find it helpful to distill it to a simple frame so I can get a bird's-eye view. For MSF Agile, I found the most useful frame to be the workstreams and key activities. According to MSF, workstreams are simply groups of activities that flow logically together and are usually associated with a particular role. I couldn't find this view in MSF Agile, so I created one:
I'm a fan of sharing lessons learned along the way. One light-weight technique I do with a distributed team is a simple mail of Do's and Dont's. At the end of the week or as needed, I start the mail with a list of dos and dont's I learned and then ask the team to reply all with their lessons learned.
Example of a Lessons Learned Mail
Guidelines Help Carry Lessons ForwardWhile this approach isn't perfect, I found it makes it easier to carry lessons forward, since each lesson is a simple guideline. I prefer this technique to approaches where there's a lot of dialogue but no results. I also like it because it's a simple enough forum for everybody to share their ideas and focus on objective learnings versus finger point and dwelling. I also find it easy to go back through my projects and quickly thumb through the lessons learned.
Do's and Don'ts Make Great Wiki Pages TooNote that this approach actually works really well in Wikis too. That's where I actually started it. On one project, my team created a lot of lessons learned in a Wiki, where each page was dedicated to something we found useful. The problem was, it was hard to browse the lessons in a useful way. It was part rant, part diatribe, with some ideas on improvements scattered here or there. We then decided to name each page as a Do or Don't and suddenly we had a Wiki of valuable lessons we could act on.
If you're backlogged and you want to get out, here's a quick, low tech, brute force approach. On your whiteboard, first write your key backlog items. Next to it, write down To Do. Under To Do, write the three most valuable things you'll complete today. Not tomorrow or in the future, but what you'll actually get done today. Don't bite off more than you can chew. Bite off enough to feel good about what you accomplished when the day is done.
If you don't have a whiteboard, substitute a sheet of paper. The point is keep it visible and simple. Each day for this week, grab a new set of three. When you nail the three, grab more. Again, only bite off as much as you can chew for the day. At the end of the week, you'll feel good about what you got done.
This is a technique I've seen work for many colleagues and it's stood the test of time. There's a few reasons behind why this tends to work:
Here's a quick rundown of our patterns & practices VSTS related Guidance projects. It's a combination of online knowledge bases, guides, video-based guidance and a community Wiki for public participation. We're using CodePlex for agile release, before baking into MSDN for longer term.
Note that we're busy wrapping up the guides. Once the guides are complete, we'll do a refresh of the online knowledge bases. We'll also push some updated modules to Guidance Explorer.
If you want to tune your software engineering, take a look at Lean. Lean is a great discipline with a rich history and proven practices to draw from. James has a good post on applying Lean principles to software engineering. I think he summarizes a key concept very well:
"You let quality drive your speed by building in quality up front and with increased speed and quality comes lower cost and easier maintenance of the product moving forward."
7 Key Principles in LeanJames writes about 7 key principles in Lean:
Example of Deferring CommitmentI think the trick with any principles is knowing when to use them and how to apply them in context. James gives an example of how Toyota defers commitment until the last possible moment:
"Another key idea in Toyota's Product Development System is set-based design. If a new brake system is needed for a car, for example, three teams may design solutions to the same problem. Each team learns about the problem space and designs a potential solution. As a solution is deemed unreasonable, it is cut. At the end of a period, the surviving designs are compared and one is chosen, perhaps with some modifications based on learning from the others - a great example of deferring commitment until the last possible moment. Software decisions could also benefit from this practice to minimize the risk brought on by big up-front design."
Examples in Software EngineeringFrom a software perspective, what I've seen teams do is prototype multiple solutions to a problem and then pick the best fit. The anti-pattern that I've seen is committing to one path too early without putting other options on the table.
A Lean Way of LifeHow can you use Lean principles in your software development effort? ... your organization? ... your life?
Today I helped a colleague clear their inbox. I've kept a zero mail inbox for a few years. I forgot this wasn't common practice until a colleague said to me, "wow, your inbox doesn't scroll."
I didn't learn the zen of the zero mail inbox over night. As pathetic as this sounds, I've actually compared email practices over the years with several people to find some of the best practices that work over time. The last thing I wanted to do was waste time in email, if there were better ways. Some of my early managers also instilled in me that to be effective, I needed to master the basics. Put it another way, don't let administration get in the way of results.
Key Steps for a Clear InboxMy overall approach is to turn actions into next steps, and keep stuff I've seen, out of the way of my incoming mail. Here's the key steps:
Part of the key is acting on mail versus shuffling it. For a given mail, if I can act on it immediately, I do. If now's not the time, I add it to my list of actions. If it will take a bit of time, then I drag it to my calendar and schedule the time.
Anti-PatternsI think it's important to note the anti-patterns:
Here's my short-list of techniques I use for improving efficiency on a given task:
While each technique is useful, I find I improve faster when I'm using them together. It's synergy in action, where the sum is better than the parts.
Grigori Melnik joined our team recently. He's new to Microsoft so I shared some tips for effectiveness. Potentially, the most important advice I gave him was to timebox his day. If you keep time a constant (by ending your day at a certain time), it helps with a lot of things:
To start, I think it helps to carve up your day into big buckets (e.g. administration, work time, think time, connect time), and then figure out how much time you're willing to give them. If you're not getting the throughput you want, you can ask yourself:
To make the point hit home, I pointed out that without a timebox, you can easily spend all day reading mails, blogs, aliases, doing self-training, ... etc. and then wonder where your day went. Microsoft is a technical playground with lots of potential distractions for curious minds that want to grow. Using timeboxes helps strike balance. Timeboxes also help with pacing. If I only have so many hours to produce results, I'm very careful to spend my high energy hours on the right things.
Building guidance takes a lot of research. Over the years, I've learned how to do this faster and easier. One of the most important things I do is setup my folders (whether file system or Groove)
I use this approach whether I'm doing personal learning or building 1200+ page guides. This approach helps me spend more time researching and less time figuring out where to put the information.
Today we released our Beta 1 of Performance Testing Guidance for Web Applications Guide. It shows you an end-to-end approach for implementing performance testing, based on lessons learned from applied use in customer scenarios. Whether you're new to performance testing or looking for ways to improve your current approach, you'll find insights you can use.
Contents at a Glance
About Our Team
Today we released our Beta 1 of Team Development with Visual Studio Team Foundation Server Guide. It's our Microsoft playbook for TFS. This is our guide to help show you how to make the most of Team Foundation Server. It's a distillation of many lessons learned. It's a collaborative effort among product team members, field, industry experts, MVPs, and customers.
About Our Team
Contributors and ReviewersHere's our contributors and reviewers so far:
I'm a fan of using different techniques for improving thinking. Here's a write-up on Six Thinking Hats. This book presents a simple and effective thinking framework. What I like about the approach is that it's both effective for individuals as well as a team. What I also like about the approach is that rather than focus on trying to change personalities, it creates a way for different personalities to play well together. Imagine the time you'll save in meetings!
Because Six Thinking Hats uses the hats as a metaphor, nobody gets a label. Instead, the entire team can put on the relevant hat for the task at hand: white, red, black, yellow, green, or blue. Imagine the surprises you get when the dominantly data-driven put on their green hats and get creative. Better yet, imagine what happens when the overly optimistic put on their black hats and play the "devil's advocate"?
What's interesting is this type of mode switching already happens. For example, in security we use white hats and black hats. On my team, I often ask, "what's your gut say" to tap into intuition and emotions. If I see the team too optimisitic, I ask "why won't this work?".
I think having a simple set of metaphorical hats and rules for the game will really help improve thinking and collaboration, and avoid the stale-mates that can often happen in meetings. As the author puts it, you "think your way forward versus judge your way forward."
Darren asks Which Feed Reader is Best? I was going to just add a comment, but it quickly turned into a post.
I've used Bloglines, Google.com, Google Reader, Live.com, Newzie, OMEA Reader, and RSS Bandit. I know I've used more that I'm forgetting. They all have their strengths and weaknesses, so finding the right match for my scenarios is the key. They all seem to continue to improve, so I find I also have to go back and re-evaluate from time to time.
For the rich desktop experience, I ended up using Newzie. Rob pointed me to it and I know he does a lot of feed reading and he too had tried a lot of readers. What's interesting about Newzie is its use of color-coding to flag by time. I also like the fact that it has multiple views, including a tree view, list view, news ticker view, and a today view.
For my "webtop" experience, I end up mostly using Live.com so I could get to my feeds from any desktop. I created pages for different topics. This lets me chunk up my reading experience and never get overwhelmed. The nice thing about a page view is it's easy to scan across.
When I help somebody get started reading feeds, if they have a Windows Live account, then I show them how to add pages and add feeds to Live.com, since I don't think it's obvious. If they don't have a Windows Live account, then I have them download Newzie and help them add a few posts of their favorite topic, and then show them how to swtich views.
My Related Posts
I was skimming The Secrets of Consulting and I came across this nugget:
“...Many years ago, Sir Ronald Fisher noted that every biological system had to face the problem of present versus future, and that the future was always less certain than the present. To survive, a species had to do well today, but not so well that it didn’t allow for possible change tomorrow. His Fundamental Theorem of Natural Selection said that the more adapted an organism was to present conditions, the less adaptable it tended to be to unknown future conditions. We can apply the theorem to individuals, small groups of people, large organizations, organizations of people and machines, and even complex systems of machinery, and can generalize it as follows: The better adapted you are, the less adaptable you tend to be...”Source: Gerald M. Weinberg, The Secrets of Consulting (New York, Dorset House Publishing, 1985) pp 29-30
Along the same lines, I was scanning Lean Software Engineering and came across this nugget:
"... When it comes to large-scale, creative engineering, the right processes for all the various teams in an organization depends on both people and situation — both of which are constantly changing. You can’t just adopt a particular process and be done with it. So really the only “bad process” is one that doesn’t provide framework to reflect and permission to adapt..." Source: Avoid Dogma When Herding Cats
This reminded me of a quote from Hereclitus - "Nothing endures but change."
I'm a fan of adaptability and continuous improvement. I think adaptability is a key ingredient for effectiveness. I always reflect on and test how adaptable is my mindset? ... my approach? ... my tools? ... my teams? ... my organization? ... my company? ... etc.
Ron talks security with Alik in ARCast.net - Defending the Application. If you want to hear some practical advice on security, listen to Alik. He's in the field doing security every day with customers. It doesn't get anymore real-world than that.
The key take-away for me is the focus on proven practices. I have a belief that focusing on a set of core practices is more effective than chasing all the variations of bad symptoms. For example, if you adopt a practice of constraining, rejecting and sanitizing input, and you verify input for length, range, format and type, you tackle injection issues (cross-site scripting, SQL injection, SQL truncation ... etc.) at the source.
At one point in the interview, Ron mentions that attackers share information all the time. Unfortunately, security is a game of what you don't know can hurt you. That's why I think community efforts and knowledge bases are a must. I'm glad to see more information sharing in blogs. I'm also glad to see efforts like the Open Web Application Security Project (OWASP). It's also why I try to share as much as possible through patterns & practices security guidance, Guidance Explorer, and SecurityGuidanceShare.com.
Per Vonge Nielsen is blogging! He's been my manager for several years at patterns and practices. He's also been a mentor for myself and many others, so it's great to see him share his learnings more broadly. Per has a way of distilling information down into the essential insights, which is a treat in today's information overloaded world.
Enjoy Per's first post - Divide and Conquer – one step at a time.
SecurityGuidanceShare.com is an experiment. I'm testing different ways to maintain and share a large body of guidance. I'm also exploring ways to factor and maintain a comprehensive set of more stable principles and practices, while dealing with more volatile, technology-specific information.
I'd like your feedback on
My two favorite features:
Comment here or send mail to SecNet.
Are you experiencing anxiousness, self-doubt or guilt? It might not be your fault. A parasite might be controlling your mind. Jason explains how in Mind Control and the Friendly Mouse.
I've worked with Jason for a few years from building software to writing guidance. He's fast and effective. We regularly swap techniques for getting results. He's got a gift for distilling insights into action. He shares that gift in his blog.
Check out Jason Taylor's blog - The Good Life, to learn:
You can also use his blog to learn how to recover from repetitive stress injuries.
Jason's currently working with me and Prashant on the patterns & practices Visual Studio Team System Guidance project.
Mark Tomlinson shared an emerging industry practice with me. Customers are setting up incremental environments. The environments are incremental steps from a developer environment to production. Incremental Environments
There's no strict rule for how many of each type of environment, and the most sohpisticated setup has multiple physical environments/labs which could be used for any of each purpose. The beauty of this approach is that instead of having a great big wall to throw your application over, it's a series of incremental hurdles. Each hurdle represents increasing requirements and constraints. This approach is also great for Centers of Excellence. A Center of Excellence team can build the environment to reflect and codify their practices. The Center of Excellence team can also harvest and share the lessons learned to help teams over each incremental step.
To engineer for performance, you need to embed a performance culture in your development life cycle, and you need a methodology. When you use a methodology, you know where to start, how to proceed, and when you are finished.
Keys to Performance EngineeringThese are fundamental concepts to performance engineering:
High ROI TechniquesThese are some of the most effective techniques we use to directly impact performance results:
More InformationYou can find more about the concepts above at:
I'm jazzed to see Corey and Bernie on the blog scene. They're partners in crime on a Lean Software Engineering blog. They have real advice for real people doing software.
Why listen to what Corey and Bernie have to say? They know what they're talking about from experience. They have the knowledge that can turn your software engineering around, if you need it. A lot of what they know, is not well known (or at least not applied), so their blog is something of a gateway to a world of better software engineering.
Whether you shape software, build it, or manage it, you'll find insights you can use. Here's some of the things you'll learn: