Rules to Successful Projects


Hold on a second! How would you like to view this content?
Just the title! A brief blurb! Gimme everything!


What others have to say about us
See what people think about this product I've been putting together Development Guidelines for my employer and in the process have reviewed many published standards (in the .NET arena) from around the world. In each category, the suggestions at SSW are always among the best. See what people think about this product
- Leon Bambrick

What is a successful project?

A successful project for a developer might mean something different compared to a project-manager and again quite different for the client.

Since our focus is on the client, a successful project for SSW refers to:
When a client receives what he's been expecting, on time and for the estimated amount of money.

Project managers define this as On Time, On Scope and On Budget.

"A successful project is where everyone involved is happy with the final outcome."

What is it that makes a good software development consultancy? What sets one company completely above the other? What makes a project completely successful?

The promise of a successful project is something we all work harder to achieve, but working harder is not the answer. Software companies need to work smarter before, during, and after development, to ensure that the client gets not only what they want, but what they need.

There are real gurus in this field like Joel Spolsky , Kent Beck , Tom DeMarco, and Timothy Lister . We like what they say, but we also reckon they miss a few things as well - everyone has their own ideas. These are the rules we run by every day. We believe they can help every software developer and team manager to deliver better code and a better end product.

Do you agree with them all? Are we missing some? Comment on individual rules, or email us .

  1. Do you understand the value of consistency?

    ​If you need to do something more than once, then there should be a standard for it. At the heart of our philosophy on creating rules and standards is the idea of consistency. There are 4 main benefits you will get:

    Say we are creating a windows forms application. We can expect to:
    • Improve productivity - because there are fewer decisions to make, and you build on existing work.
      For example, we don't need to discuss the pros and cons of MDI versus SDI because there is already a standard.
    • Improve quality - because you are following best practices.
      For example, which logging library is better out of Microsoft Application Block or Log4NET.
    • Improve communications - because people know what to expect.
      For example, when we complete a task we are clear and educate the customer by including a screenshot, the code and the time taken. We are consistent with whether we call it a bug or a feature because we define what's a bug.
    • Get straight to the meat of the customer's problem.
      For example, our developers don't need to decide whether to implement base forms or user controls. They already know because it's covered in Rules to Better Windows Forms Applications.

    At SSW we create standards for all manner of processes: from coding practices to project proposals and how to lock the office up at night. From the developer's perspective, consistency means that we understand each other's code, and if we don't know something, a standard will often save us asking someone. No more Chinese whispers and less time wasted. From the customer's perspective, consistency leads to a reliable and repeatable experience.

    The following story illustrates these values:

    The Barber (excerpt from "The E Myth" page 105)

    I went to a barber who, in our first meeting, gave me one of the best haircuts I had ever had. He was a master with the scissors and used them exclusively, never resorting to electric shears as so many others do. Before cutting my hair, he insisted on washing it, explaining that the washing made cutting easier. During the haircut, one of his assistants kept my cup of coffee fresh. In all, the experience was delightful, so I made an appointment to return.

    When I returned, however, everything had changed. Instead of using the scissors exclusively, he used the shears about 50 percent of the time. He not only didn't wash my hair but never even mentioned it. The assistant did bring me a cup of coffee, but only once, never to return. Nonetheless, the haircut was again excellent.

    Several weeks later, I returned for a third appointment. This time, the barber did wash my hair, but after cutting it, preliminary to a final trim. This time he again used the scissors exclusively, but, unlike the first two times, no coffee was served, although he did ask if I would like a glass of wine. At first, I thought it might be the assistant's day off, but she soon appeared, busily working with the inventory near the front of the shop.

    As I left, something in me decided not to go back. It certainly wasn't the haircut-he did an excellent job. It wasn't the barber. He was pleasant, affable, seemed to know his business. It was something more essential than that.

    There was absolutely no consistency to the experience.

    The expectations created at the first meeting were violated at each subsequent visit. I wasn't sure what to expect. And something in me wanted to be sure. I wanted an experience I could repeat by making the choice to return.

    The unpredictability said nothing about the barber, other than that he was constantly - and arbitrarily - changing my experience for me. He was in control of my experience, not I. And he demonstrated little sensitivity to the impact of his behaviour on me. He was running the business for him, not for me. And by doing so, he was depriving me of the experience of making a decision to patronize his business for my own reasons, whatever they might have been.

    It didn't matter what I wanted.

    It didn't matter that I enjoyed the sound of scissors and somehow equated them with a professional haircut.

    It didn't matter that I enjoyed being waited on by his assistant.

    It didn't matter that I enjoyed the experience of having my hair washed before he set to work and that I actually believed it would improve the quality of the haircut.

    I would have been embarrassed to ask for these things, let alone to give my reasons for wanting them. They were all so totally emotional, so illogical. How could I have explained them, or justified them, without appearing to be a boob?

    What the barber did was to give me a delightful experience and then take it away.

    What you do in your model is not nearly as important as doing what you do the same way, each and every time.

    Figure: The Barber gave an inconsistent experience. Excerpt from "The E Myth" page 10

    Standards don't need to come at the expense of creativity. Following standards means less time doing the administrative stuff and more time for the creative. Of course, standards are works in progress, and so we are always on the lookout for improvements. That's why standards should be shared with everyone.

  2. General - Do you know rules are made for the guidance of wise men and the obedience of fools?

    ​​​Standards should *not* be followed blindly. Aim for continual improvement.

    Whenever you're doing something more than once there should be a clear procedure. We call them “standards” or “rules”. That means that there should be lots of standards.​

    But there are pros and cons to having standards.

    The pros:

    • They help speed up the decision making process – getting you to the best decision faster
    • They help consistency

    The cons:

    • They take time to write in a generic fashion
    • Technological rules rust easily. Technologies and techniques change often, so you must be on the lookout for the new and better approaches and continually update these.​
    • They have errors as they are written by imperfect people.
    • People will sometimes follow an inappropriate rule. A set of rules can never predict every path, so  cases can and will appear that the standards fail to cater for.

    So standards should always help the critical thinking process, never replace it

    If you think something can be done better or the standard is simply out of date, you should improve the standard. This is best done as a team effort​ with everyone making little changes often. Whenever you come across a standard which needs updating or improving you have four options:

    1. Ignore it and hope someone fixes it (this is punishable by being sat on by a wild hippo);
    2. Fix it yourself straight away (preferred);
    3. Fix it yourself later (send yourself an email);
    4. Ask someone else to fix it (following the change "x" to "y" rule) 

    For any page on our sites, you can click the 'Feedback to SSW' link at the footer.

  3. Do you manage clients' expectations?

    Software development can be painful and costly. Hang on, that should say

         "Software development IS painful and costly."

    There's no doubt custom software development is a challenging industry. According to the Standish Group Report, 1999: Nearly 75% of all development projects missed their target release date or never ship at all. But what I find so interesting is that at least 7 of the 10 most common signs of product development failure are present before the design is created or a single line of code is written. (John S. Reel 1999).​

    Projects often fail because clients think suppliers under-deliver and over-charge. The client and the supplier have different expectations about the goals of the project. This difference of opinion often leads to a project's absolute failure.

    Don't give ranges! Let's say a prospect asks me "how much to do this Release?" I could say - "Somewhere between $15k - $20k". I hear 20, the prospect hears 15. I'm pleased we got it done for $25k with a whole bunch of changes, the client is annoyed we didn't get it done in 12. So I never give a range to a client. I tell them that the first Release, along with its spec is likely to take $35k. That's two guys working full time for two weeks.

    Be upfront about bugs I don't believe there is such a thing as bugless software. It's important to admit that bugs will happen. Bugs will get through testing, and bugs will cause a headache in production. In a fixed price agreement we cover bugs, because the goal posts are stuck in the ground, but in hourly-rate work, bugs are covered by the client. See what is covered in fixed price contracts for more information in relation to what is and what is not a bug.

    Fixed prices don't solve anything: A big fixed-price contract can also be dangerous in managing expectations because it removes flexibility. If you deliver exactly what the spec says, the client can quite easily be unhappy, because the hundred and one things they thought of during development weren't included. I recommend fixed-prices in Releases of no more than 3 weeks (1 - 2 releases) development which helps alleviate this problem. It will often occur that in the middle of a fixed price contract a client will ask you to add extra functionality. You should not do any such items straight away, but turn this request into a task for future development. You should generate another release plan for all the extra items once the fixed price contract has been signed off. It is important that the customer is always clear on what is part of a fixed price contract and what is not, that is why you should always finish a fixed price contract and have it signed off before starting extra work.

    Talk dollars at the first meeting: Talking dollars with the client is often something consultants don't like doing after the initial meeting. I've heard of consultants refraining from sending invoices when a project is suffering a few delays, or the client is unhappy with the application state. What makes this consultant think that if the client is unhappy to receive an invoice now, they'll be happy to receive it in two months? We send invoices for time and material projects every week. This way the client is informed of costs every week, and if a hassle arises, it's trapped straight away.

  4. Do you pursue short or long-term relationships with clients?

    ​​Treat clients the same way you would treat a prospective partner - that is, with lots of TLC. Think about your first conversation with a nice girl/guy. You have two approaches you could try.

    The first kind of approach is where you try and seal the whole deal in one go:

    "I think we would work well together, would you like to get married and have two children?"

    The likely response would be:

    "Get lost you loser."

    The second and more appropriate approach would be to ask something like:

    ​"Would you like to have coffee together?"

    You have a greater chance that your prospective partner will say:


    Unless you are a great salesperson, who has constant exposure to new clients, then I suggest you use the 2nd approach. Clients are likely to be frightened off with huge quotations from vendors that they have not got trust in, so avoid this by segmenting the project into smaller projects. It reduces the risk for the client.

    For example:

    Thanks for this initial meeting. I will now go and prepare a proposal for you.
    (You then do the proposal for free, and include a series of release plans costing $100K)

    Figure: Bad Example - asking a client to get married after the first date. This is likely to be too big a figure for them to risk on for their first taste of your work

    Thanks for this initial meeting. There are two options to consider for the next step:
    1) We could do detailed Specification Review, which is a commitment of 5 days with 2 developers, or
    2) We could do brief Specification Review, which is a smaller commitment of 2 days with 2 developers 

    Figure: Good Example - a client is more likely to appreciate this approach, they get a choice + they are given an option of proceeding with a small project. There are prospects of continuing the relationship based on how well the previous project goes


  5. Management - Is your client clear on how you manage projects?

    ​There must always be *one* person who is responsible for the project getting into production. That person is the technical lead.​

    SSW's Rules to Better Project Management, built on Scrum, allows businesses to address their most important challenges first, and respond quickly to a changing commercial environment. Whether you work on site or remotely, the key is good communication with the customer and users, becoming an integrated part of your team. Follow these rules and you will deliver functional, value-adding software - faster.

  6. Management - Do you enforce deadlines, have a sprint plan, a review/retro and a mark /10

    Developers love doing things in their own time, investigating interesting things they find on the web, and therefore they're generally easily distracted. If they don't have a Sprint Plan constantly in front of them, they'll never deliver on time! For every project you must have 4 essential things:
    1. Enforce Deadlines - Every week (usually Tuesday) the developer has a sprint review meeting with the client to discuss the status of project.
      Note: If you can't have a meeting, a phone call must make do.
    2. Have a Sprint Plan
    3. A Sprint Review and Retro when the release is done.
    4. A mark /10 - from the client.  ​

    In respect of the review and retro, when thing have gone off the rails, it is easy to speak your mind and say what you believe went wrong. However often when things are going right, the tendency is to skip the debrief thing, with a comment 'all is good'.

    A better idea is to figure out 'why are things are going right?', and work out how you can repeat it. For example, if your client calls and says,

        "We think Dan has shown very professional conduct and has delivered a high-quality solution"

    you should look at how the project was run. Was the solution high-quality because your developer is a faster coder, or good at following your coding standards? Or was his professional conduct due to lots of customer interaction and polite and clear communication?

    Of course, if in your retrospective, if you find that the client is unhappy due to bad conduct, scope creep, or poor quality code, you need to check that your standards are being followed to ensure a positive experience in the next debriefing.

  7. Management - Is your client clear on the definition of a bug?

    ​The answer to this question can make or break contracts. We think that it's such a fundamental issue it has to be captured clearly. This is how we strictly define a bug. ​

    A software issue can be classed as a bug where: 

    1. The application crashes to code (excluding bugs resulting from third party products (e.g. "blue screen of death" or crashing in a third party data grid that we cannot control); or
    2. The application displays data inconsistent with the specified business rules; or
    3. The application is missing functionality specified in the specification; or
    4. The page design/layout is substantially inconsistent with the agreed mock-ups

    and the developers can reproduce the above on the test server and the application is not yet "live" and the issue has been reported in time (generally 30 days).

    Examples of what *could* constistute a bug:
    1. The application crashes to code because it doesn't check that a connection is valid before running a stored procedure (this is likely covered because it crashes to code)

      Figure: Yellow screen of death
    2. A sum total is negative instead of positive because the wrong operator (plus instead of minus) has been used to calculate the running balance (this is likely covered because data is inconsistent with the specified business rules)

      Figure: An incorrect sum is likely to be a bug
    3. The application is missing the Monthly Sales report (this is likely covered because the application is missing functionality specified in the specification)
    4. The output HTML in the application is formatted way out of line and does not display in the specified browser (e.g. Internet Explorer 9) (this is likely covered because it substantially inconsistent with the agreed mockup)
    Examples of what is *not* a bug:
    1. Any problem caused by software or an application not written by the organization supplying the software.
    2. The customer requirement was not included in the user interface/mock-ups/specifications.
    3. The client decides that they don't like the look of the current form even though it is the substantially the same as shown in the specification and wants the buttons at the bottom of the form instead of at the top.
    4. The original specification states that the total price excludes GST, but it really should have included GST. This is a change to the specification, and is not included in the contract.

    Work items in TFS - Agile Template

    Using TFS allows you to create work items such as user stories, bugs, tasks, test cases etc. Only create bugs in TFS for defects, faults, flaws, or imperfections that fulfill your definition of a bug. For everything else use other work item types.

    Figure: Do I create this as a bug, or a task? 

    Handling additional work for fixed-price contracts
    Scrum wasn't designed for fixed price, fixed scope contracts, however, a​ny new features or modifications (non-bug items) not in the original sprint or sprints are classed as additional work and are outside the scope of the contract. Any tasks which are bugs should be marked as additional items and be completed in the current sprint if possible. Most importantly, after the sprint plan has been sent, a PBI should NOT be entered as an item (additional or otherwise) in ANY sprints if they are not a bug. Instead, move all non-bug items to the product backlog for future review after the warranty period for the fixed price contract has passed.

    Handling additional work in a Scrum project

    Any new features or modifications (non-bug items) not in the original Product Backlog are classed as additional PBI's and placed on the Product Backlog. Any tasks which are bugs found during the current Sprint should be fixed within the current Sprint. Any tasks which are bugs found outside of the current Sprint should be added to the Product Backlog. See Do you know when to create bugs? and Do you know the 3 steps to a PBI?

    Figure: Adding a bug to the Product Backlog in TFS

    If you see a bug in any software product, e.g. SSW Code Auditor, it is best to report the issue following the steps outlined the SSW Bug or Enhancement Reporting Standard.

    Note: The above is our definition. Others have different definitions that we do not subscribe to:
    You can also use the Wiki definition of "Software Bug" as a reference to understand this concept:
  8. Do you provide ongoing support?

    Just like a car, applications need servicing and tuning every now and then to stay in top condition. They might need alterations to deal with new business problems, or just tuning to increase efficiency.

    Figure: What happens after the software has been delivered and the development team moves on. The next phase is maintenance​

    So you’ve done 10 good sprints and the software has been delivered ​(ready) and the team is winding down. It will need maintenance.

    Different clients need different levels of support. Offer your clients a few different support offerings.

    1. Ongoing Maintenance: 1 day per week (or whatever quantity suits), a developer will work on enhancements and bug fixing. This is useful because the client always knows when work will next be done.
    2. Maintenance Contract: For 10% per year of the cost of the system you developed, all bugs will be fixed. This way your client will be guaranteed that the system will keep on running.
    3. Time and Materials or Prepaid: A client can simply call for bug fixing or support as and when needed. However, unless it's a show stopper, this model can involve waiting for developer availability.
    4. Fixed Price Warranty: For a fixed price project, a warranty commences after the Sprint Review. The warranty length is half the length of the sprint and, during this period, any bugs reported will be fixed for free.

    Warranty on a Fixed Price Contract

    Once the sprint review is complete, the Product Owner has half the sprint period again to report any bugs.

    Note: The warranty period pauses when the client reports a bug that stops them testing further. The warranty period resumes when a new version is sent. For example, the client may report a bug on a Wednesday morning on "Day 4" of the warranty. The bug is fixed on Friday and a new version is sent late in the afternoon. The warranty period resumes on Monday morning, at "Day 4". Therefore Wednesday through Friday was not included in the warranty.

    Note: There is no warranty on a time & materials contract.

    Important:  During the warranty period, all feedback from clients should be moved to backlog unless they fall into the bug definition.
  9. Management - Do you maintain verbal contact with your client?

    ​​With the convenience and cost-effectiveness of e-mail, it is tempting to resort to emails for too much client contact. Don't forget that clients are people too, and they need human interaction to ensure everything is OK. So it is essential that you maintain verbal contact before, during and after a project. What are examples of ongoing project contact?
    1. Set the expectations early. Let the client know what to expect in terms of communication. For example:

      "Hi Bill,
      We will run your project in an agile manner. Expect emails and phone calls that we need responses to. These are examples:

      • The first step - we will send you a release plan to approve. Once approved we can begin work
      • Every morning - expect a 'Stand up meeting' call or 'Morning Goals' email with a list of tasks the developers will be working on that day
      • Every time a task is done - you will get an email with information about what was done, often with screen shots and code snippets"
      • If you need to change the priority of a task - email us and we will consider it for inclusion either the next release, or a subsequent one, depending on its importance"

      Avoid going more than 3 days without a phone call to your client.

    2. New Resources - If you are put onto an existing project, it is good practice to call the client and introduce yourself. For example:

      "Hi, I'm Andrew. I'll be taking over from Mark on your project. Mark has filled me in on the specifics and I'm keen to get involved."

    If you use the phone instead of email when it is appropriate, you maintain an open channel of verbal communication with your client. This helps to break down communication barriers, lets the client know that you are friendly and involved, and makes them feel confident in your ability to deliver the project.

  10. Management - Do you spec in bite-sized pieces?

    The first problem with specs is that nobody writes them. Joel Spolsky says:

    "Writing specs is like flossing: everyone agrees that it's a good thing, but nobody does it".

    - Joel Spolsky, The Joel Test: 12 Steps to Better Code

    We know developers like writing code more than specs, but the rule is developers don't code without a spec (including a release plan).

    The second problem is that when people do write them, they try and spec the whole project, spending months detailing every Use Case, Business Rule, and Process Flow Diagram. The client spends lots of money and sees no real progress, and the requirements change and the process begins again.

    The most popular and most successful way to deliver projects is using a specific framework called Scrum. In Scrum,​ you fix the timeframe and the cost so the only variance is in the features that are delivered in that time. You should keep your time to between 2 and 4 weeks and all your team members should be full time, thus fixing the costs.  

    See Rules to better Scrum.

    At SSW we spec in two phases, the first to get an overview of the project, the second, to focus on the detail of first few releases only:

  11. Storyboarding - Do you conduct specification analysis by creating mock-ups?

    ​​​Complex documentation can waste time. Many user requirements can be best encapsulated in screen mock-ups. Spend more time on mockups compared with time on documentation.​

    Storyboarding is a technique taken from movie production. 

    Movie Storyboard
    Figure: Movies are expensive to produce, so directors do storyboards first and then the product designer, costume designer, lighting people etc. all know what they need to do for each scene
    Source: Woodsman Film Company

    There are five primary types of mockups:

    1. Hand drawn Mockups
    2. Wireframe Mockups
    3. Developer HTML Mockups
    4. Designer HTML + CSS Mockup
    5. Designer Photoshop Mockups (recommended)

    Often it's best to start with some hand-drawn ones to get started. Then if you have access to designers, complete a couple of full 'Designer Photoshop Mockups' for "look and feel" approval, then complete the balance as wireframes.

    Hand drawn Mockup

    'Hand drawn Mockups' are recommended to be done with the customer. Since it doesn't deal with any styling/color issues, 'Photoshop Mockups' will be needed after.

    Hand drawn Mockup
    Figure: A 'Hand drawn mockup' example. Nice and quick for early concept design

    Wireframe Mockup

    A layout of how the controls will look is usually all that is needed initially, without worrying about images. An example of Wireframe Mockup

    Tip: The tools to develop a wireframe depend on your skillset and the front end technology chosen. For example use:

    • Microsoft PowerPoint (ubiquitous)
    • Balsamiq
      Wireframe Mockup
      Figure: Wireframe storyboard mockup on Balsamiq
    • Adobe XD - preloaded with the most popular UI design blocks (recommended for web & mobile app design)
    Figure: Adobe XD prototyping
    Figure: Adobe XD Google material design UI kit


    • Sketch (Mac Only and for UX designers)
    • Moqups (HTML5 based App)
    • Photoshop (primarily for designers who already have the skills)
    • UXPin (more sophisticated, helps you create responsive designs)

    Developer HTML Mockup

    These are mockups done in the front end technology that will be used. Meaning it could be done as a Web/Windows Forms/Access UI with limited functionality:

    An example of an ugly Developer HTML Mockup.

    Developer HTML Mockup
    Figure: Developer HTML Mockup example - not recommended as it is a bad starting point from an HTML view and refactoring later is harder (if even possible) + this reeks of Bodgy Brothers and doesn't do a very good sales job

    Designer HTML Mockup

    These are also mockups in a Web/Windows Forms with full CSS Styling and graphic designer enhancements:

    An example of a pretty Designer HTML Mockup

    Designer HTML Mockup
    Figure: Designer HTML Mockup - not recommend because it is time-consuming to make changes (and change is all you do at the beginning of a project)

    Designer Mockup

    These are concept mockups produced by designers in Photoshop providing a guidance of the final look with full styling.

    Warning: Don't go down the track of giving a customer a few concepts (on some projects we gave 2 or 3 completely different concepts by different designers). There becomes too much mixing and matching when they see them. Once the images are approved, then the designers slice them up and turn them into HTML (slicing is the exporting of each image).

    Designer Photoshop Mockup
    Figure: Designer Photoshop Mockup example - recommended as quick to change, when changes happen

    More information – Add notes at the bottom

    Wireframes should include numbers (in orange circles) and notes at the bottom, explaining features and/or indicating priority.

    Wireframe with Notes
    Figure: This wireframe indicates priorities of features

    Mock-ups notes should also include the business rules that apply to the page. If there are a lot of rules then it is acceptable to link off to a Microsoft Word document.

    Good Mockup
    Figure: Good Example - This mockup states the validation and business rules that apply to the page

    Don't use UML - it is virtually impossible to get clients to understand these.

    UML is bad for mock-ups
    Figure: Don't use UML diagram which clients can't fully understand

    UML is not all bad. UML and other formal documentation methods can be useful for developers.

    The overarching problem is it gets out of date, so it gathers dust (aka Technical Debt).
    A better way of getting documentation is to flesh out the classes and use the VS Dependency Graph or NDepend.
    A demo can be seen in the 2nd video "A Modern Architecture Review".

    Figure: Tools like NDepend can generate diagrams from your source code so there's no "Technical Debt"


    Mock-ups and wireframes are far easier to understand.

    For example, to communicate that “a customer has many phone numbers”, a storyboard/wireframe of how that relationship will appear in the user interface is highly more likely to be understood by the client.

    The clear communication of the message is more important than the medium used to convey that message.

    Here are some more hot tips on mock-ups:

    • Avoid the thought of a "throw-away" prototype. An example of a throwaway prototype is when you design screens in Access, but the application will be HTML. So design the screens you and the customer are happy with the technology you will be using, and then use them in the app.
    • It is best to have a designer and developer and customer working together.
    • Get the mock-ups physically initialed, especially if you are performing a fixed-price contract. Yes, paperless is great - but not in this case.
    • If you can't get mock-ups initialed, then page by page approval over email is the 2nd best option.
    • A tip I picked up from Tom Howe was to always add a client's branding into the mockup - it makes a big impression
    • Mock-ups should follow standard interface rules
    • Write the related business rules at the bottom of each screen - and turn into unit tests.

    Related Rules

  12. Do you give each project a project page (that you refer customers to)?

    A project page is not a place to introduce the project. It will be used to share the project process information between your teammates and clients. See our rules to happy clients
  13. Do you conduct Market Research via the Web?

    Why write code when you may not need to write any at all? In every industry Market Research is conducted before a product is developed. Why is IT any different? Doing Market Research focuses the product on the right set of people so you can satisfy their needs. If you can't connect the dots between the work you do and how it helps the customer, consider investing your time elsewhere. Market Research bridges the gap between the techies and the users.

    A great way to get feedback on upcoming projects is by putting specs of upcoming projects on the web and inviting user comments - not forgetting to acknowledge their contribution. Often Surfers will tell you what is needed to make the product great instead of just good, or you may be told that there is already a program out there that does the job. You should also spend two days looking for similar products and speaking to users about the features. Since the specs are full of screen captures, this allows us to think of our end-users and increases the likelihood of creating a great product which our users love.

    Who comes first? The Technology or the User? I even wonder about Microsoft, they've built this great .Net Core technology but shoehorn a user interface and experience onto the framework so the user experience is compromised. What great products are designed this way? Do tailors measure their clients after the suit has been sewn together? I'm sure Microsoft spend heaps of time and money discussing the specs amongst themselves, but I believe they should've put the interface/Images on the web so that experienced users could voice their opinion and offer suggestions early in the product cycle. Instead we wait for the beta versions - if you offer a suggestion now, there is no time for it to be implemented as the shipping deadline is too close. The only contribution we can make at this stage is finding bugs!

    So balance engineering, business and usability, put your specs on the web, keep them updated with changes, and listen to your users!

  14. Do you know the best CRM solutions for your company?

    ​​There are a lot of different CRM solutions on the market. We would never suggest to develop a CRM solution from scratch. Instead pick an existing solution and customize it for your needs.

    The main choices for CRM solutions are:

    At SSW we implemented a lot of CRM services based on Microsoft CRM.
    The experience with this solution showed us high trust in using MS CRM as a base for future business needs.

    Read the rules to better Microsoft CRM to get an idea what MS CRM can do for you.

  15. Searching: Do you know how to be a great Googler?

    The best developers are also extremely good at finding a solution to a problem they don't know.

    I am pretty good at Googling but when I can't find something, I ask my friend Scott on IM. Scott Hanselman is the best Googler I know. He can find anything in 2 minutes...

    1. Think of a piece of the code that will be in the answer
    2. Include the company name if possible
    3. Use the advanced searching functionality​
    4. Use quotation marks when you're searching for an exact string
    5. Include the technology used if appropriate

    If someone asks you for help searching, always tell them the keywords - that will help them learn to search better.

    For example, take Site, a leading Australian news website. If you search on the key words 'Australia' and 'news' you wont find it on the first page, but if you add 'Sydney' (a word from the company name) then you're number 1...

  16. Searching: Can you instantly find any file on your computer or network?

    Often you will want to quickly find a file on your computer or local network. On the web, with the advances in search engines this seems so easy. New enterprise search tools are now making this same feat possible for your desktop. Your tool should index all your local files and emails, and also allow you to search your entire network.

    Using MSN Desktop Search​ ​​will allow you to instantly search for a name and find all correspondence with that person. Even if there has been no contact for 6 months, you can resume the discussion as if it were yesterday.

    Of course if you are using Windows 8, Windows 7, or Windows Vista, desktop search is integrated within the operating system.

    Follow our standard on setting up Enterprise Search.

  17. Management - Do you always inform your client how long a task took?

    Put 'Actual Time Taken' into your email. It's all about education and accountability - a customer that understands how long things take is better than one who doesn't.

    During the course of a Time and Materials projects, a client will often ask for an estimate on a particular piece of work. Of course we duly go about investigating the work to deliver to the client the required estimate.

    Sometimes, due to the nature of the work, the time taken to investigate is completely out of proportion to the time taken to complete the work. As an example, if you are working on a legacy ASP application with loads of spaghetti code, and the client wants a particular bug fixed, it can take 2 hours to locate the bug, and then only 15 minutes to fix it. When you report to the client the estimate for 'how long' - ensure you include the 2 hours investigation, not just the time to fix it. Thus, you need to put 'Actual Time Taken: 2:15'.

  18. Management - Do you use XP/Scrum wisely?

    Scrum is a big concept which we try to use here. I don't adhere to every idea, but there are some very practical rules I follow which improves the way we develop on large projects:
    Figure: You need to check up on your developers every 2 weeks. Then you'll never be fooled! Figure: You need to check up on your developers every 2 weeks. Then you'll never be fooled!
    1. Sprint Contracts/Releases - Never set a deadline more than 3 weeks from the previous deadline. Deliverables become a lot easier to manage and meet when they're small. Read more about Sprint Contracts
    2. Unit Tests - Write tests before you write code. Unit Tests become a way of life and although they're expensive at the beginning, they pay off during the course of the project. To find out more about Unit Tests see Rules To Better Unit Tests and for unit tests in the GUI of SSW Code Auditor please go to Rules to Better Code.
    3. Metaphors/User Stories - client's description of a task. Aim to take down the main points
    4. Validation Tests - To find out more about Validation Tests see Rules To Better Website Development.
    5. The 2 key reports
      • Burndown
      • Stories Overview

    Here are the rules we don't agree with:

    1. Physical Cards - emails are much better
    2. Pair Programming:
      • XP says 2 people at one PC - we have two developers on their own PC's sitting next to each other.
      • We fix production code in pairs. 'Too Expensive' some say. Yes it's pricey, but it's better quality.
  19. Methodology - Do you do Daily Scrums (aka stand-up meetings)?

    ​​Tight project teams have a Daily 'Scrum' every day at the same time.

    It was once called a 'stand-up meeting' but that discriminates people in wheelchairs.

    It is best to have it standing up, so it's short and to the point. No-one wants to stand around waffling.

    Everybody knows the 3 essential questions:

    1. What did you do yesterday? (and did you update TFS/other bug tracking system)?
    2. What are you going to do today? (and my current task on the physical task board has my picture on it)
    3. Do you have any roadblocks? (aka issues/impediments)

    Asking these questions of every team member means no-one can hide and everyone remains connected. Further, you can notice what was promised and what was performed. This enables the team to discovers issues quickly and keep abreast of the progress.

    The team's successes and failures are shared, and anyone who knows the answer to someone else's problem can help with a solution, *after* the meeting.

    Figure: Watch a Daily Scrum at Microsoft (short)
    Figure: Watch a Daily Scrum at Microsoft (long)

    "Great video guys. Remember, it is ok to change Scrum, actually, it is necessary for success. Just adhere to the values of Scrum. "

    Stephen Forte (Board member

    Follow these essential tips to improve your Daily Scrum meetings:

    Tip 1: Be prepared for the meeting 

    Before you join the Daily Scrum, check the Teams group to see what your colleagues have been discussing and working on, and check the portal to confirm the meeting time. If you’re joining a new project or re-joining a previous one after some time away, these steps are important to keep yourself up-to-date and abreast of progress. 

    Then you’ll be able to say to your Scrum Master, “I’ve had a look at the Teams group. I am ready to join the daily Scrum.” 

    Tip 2: Have your Scrum Master review the Sprint Progress at the end

    At the end of the Scrum, the Scrum Master should review the current burn down to check on the progress of the team.

    Figure: The burndown chart in

    Tip 3: Keep a schedule of the Daily Scrum times on a wall (+ have a recurring appointment in Outlook)​​​

    Subject: 🙋Daily Scrum – [Project Name]

    Hi [Team name],
    As per our conversation, the Daily Scrum will be held each day.

    Project: [Project Name]
    Scrum Master: [Scrum Master Name]


    [Your name here]

    <This email was sent as per Do you do Daily Scrums? >  

    Figure: Schedule a recurring Daily Scrum meeting in Outlook using this template
    Figure: Or you can use Microsoft Teams

    Tip 4: Keep to the schedule. Same place, same time (and start even if people are missing)

    Get started on time. Especially in the beginning, people will be late, but the meeting should be held with the remaining people. Don't worry. People learn.

    If the Scrum Master is not a full-time member of the team (often they are), they should attend every now and then to check the Scrum process is being followed and the Daily Scrums are being used synchronize the team and not a general meeting.

    Note #1: The Product Owner (often the client) is not required at the stand-up meeting. If he wants to turn up, remind him that he has tape stuck over his mouth, so he does not talk. 

    Note #2: If you are not doing an approved sprint and doing ad-hoc work, then best if the Product Owner (aka client) attends (see Ad Hoc work).

    Tip 5: Do you update tasks before the Daily Scrum?

    Daily Scrums are more effective when team members arrive when their tasks are already updated.
    See Do you update your tasks before the daily stand-up meeting?

    Tip 6: Don't go into detail

    Keep your answers short and concise. Do not stray from the 3 main questions. Remember to use the "Parking Lot" to record topics to discuss after the Daily Scrum.

    Tip 7: No phones + no checking email. No distractions.

    Technology in the Daily Scrum causes people to lose focus on the goal. The goal is for the team to synchronize by sharing what they are doing. Avoid giving people the opportunity to be distracted easily by forbidding email, SMS and mobile phones from the Daily Scrum.

    Tip 8: Use a task board (even better use an electronic one)

    A task board allows people to visualize what the team is talking about.

    Figure: The Task Board from (TFS 2012)

    Tip 9: Carry a pen and paper

    Use a pen and paper to jot things down.
    A whiteboard is also great for "Parking Lot" topics that arise, to be discussed after the meeting.

    Tip 10: Don't let your Daily Scrum become a general meeting - use a "Parking Lot".

    A "Parking Lot" is the place for any discussions that stop the Team from answering the 3 main questions. Only interested people stay for the "Parking Lot" to discuss issues after the Daily Scrum.

    Tip 11: If you have raised impediments, consider contacting the Product Owner

    Get the Product Owner on the phone
    Figure: Often the Product Owner won’t be at the Scrum. However, call the Product Owner if you have an Impediment (aka Roadblock). Communication with the Product Owner is essential and if you haven't touched base with him in the few days, then do so. A disconnected or absent Product Owner is a sign of dysfunction.

    Tip 12: What to do when you're working for a PO directly

    If you don't have a team, and you're doing ad hoc work for a PO directly, it's best to contact him for the Daily Scrum every day if possible, and follow up with an email. This will keep the 2 of you synchronized.

    Tip 13: How do you enter scrum meetings into your timesheets?

    Once you have completed your stand up, add “S” to your timesheet as per Rules to Better Timesheets.

    Tip 14: Use Teams or Skype

    Use Teams or Skype to bridge gaps in geography. 

    Focus on the Flow

    "Extend this rule to focus on 'flow of value', not just people. In a continuous flow mindset, the daily standup is less about the people..... it's about flow. The team faces the scrum board and goes ticket by ticket for all the items in the 'work in progress', finding out what is needed to get it to the next stage.. respecting work in progress constraints."

    Joel Semeniuk

    When using email or IM try to be as specific as possible.

    Hi Adam,

    I have XX days until my next client booking.
    I have 22 emails in my inbox.
    Yesterday I was on sick leave.

    Today I am working on:

    • Timepro PBIs
    • Tidy inbox

    <This email was sent as per>

    Figure: Bad example - Lack of details. Eg. Yesterday - if it's Monday, you wouldn't say “Yesterday was Sunday"... so if you were sick, it's more useful to go back to the prior day you were working


    I have XX days until my next client booking.
    I have 22 emails in my inbox.
    Last Friday I was on sick leave.

    Today I am working on:

    • TimePro - Adding new button to the next day
    • Getting my emails on "" to zero

    <This email was sent as per>

    Figure: Good example - Clear details 

    More information

    What happens when you run out of tasks?

    The goal is to be productive for 8 hours of the day, so communicate with the rest of the developers and work with them on any other outstanding tasks. If there are no more tasks then take the next task from the top of the Sprint Backlog.

    What happens if there is a major incident?

    It is important that any major incidents are dealt with first. Start with any major incidents that occurred in the last 24 hours.

    Figure: Daily Scrums will alert everyone if there is a major problem and get all brains aligned in the right direction. There is no sense in putting a Band-Aid on a patient's scraped knee if there is a big knife in his eye!
    Figure: If you like this, retweet  ;)​

    Related rule

  20. Do you send Morning Goals? (This rule is out of date)

    *Note: We no longer do this, we now do our daily stand-up meetings (Scrums) because it is more effective with interactions between team members.

    (An alternative to morning goals is having daily stand up meetings (scrums) which is more effective for interactions between team members and the client/manager. We now prefer scrums.)

    Before a day starts it is not only important to have a list of what you plan on achieving that day but to communicate that list to your manager and/or client. This not only keeps you accountable but allows your superior to change your priorities if needed.

    You can use eXtreme Emails to communicate your "Morning Goals" using the following method:

    Morning Goals Email 

    Figure: Sample Morning Goals Email
    • Forward the previous morning goal from yesterday, striking out completed items
    • Comment (in a different colour) and give the reason whether any items were not completed
    • Copy outstanding items to today's morning goals, appending any new information
    • If we are working on-site we always send our morning goals from our SSW mail account, not an internal account the client may choose to give us. This enables us to keep a record of the email, and also keeps the branding consistent. If this is not possible, we always CC our SSW account (and then move the emails into your "Saved Items" when you get back to the office)
    • If something more important arises during the day, we note it down on the next days morning goals.
    • If a task is huge (e.g. clean up my email inbox) and we only aim to do a portion of it, we say so in the morning goals as well.

      Morning Goal Aims

      Figure: Morning Goal Item with a mini goal (140 emails)
    CC the people you are working with on the email.
  21. Do you allow users to check for a new version easily?

    It is important to give users the ability to check for a new version of the application they are using. And once located it should be easily downloaded and installed. You need: 

    1. A visual identifier such as a tick or a cross on the main menu
    2. A "Check for Updates" option in our Help menu.


    • This is mainly for Windows Forms, but you can do the same for new versions of Web Applications - e.g. a knowledge base package or Reporting Services Application.
    • You can do a complete check of your PC at the click of a button using SSW Diagnostics.
    • Since this check occurs over the web, you should use threading to avoid slowing down the forms responsiveness. This is a generic component that is available in the SSW .NET Toolkit.
    • If the UI is a Windows Service, be aware that they don't open up the UI very often. Therefore you can't rely on this method. In a coming release Diagnostics will ask for your email and let you know when updates are available for you PC.
    Check for UpdatesFigure: BAD UI - a nagging message box that forces the User to click OK
     Figure: Show a Tick when the application is up to date
     Figure: Show a Cross when the application is out of date

    To keep the consistent look and consistent code, we have implemented our version checker as a user control.

     Figure: SSW.Framework.WindowsUI.VersionStatus

    As it is a user control, we can easily implement this in all our applications. We just need to place the user control on the winform, and have the ProductDownloadID and ProductLatestVersionURL entered with the correct values.

     Figure: Enter the ProductDownloadID and ProductLatestVersionURL  

    Check for Updates

    Figure: Include 'Check for Updates' in your applications
  22. Do you keep the best possible bug database?

    ​There are 101 bug databases on the market at the moment and of course many companies make up their own in-house systems.

    This is a common scenario: Your tester/client finds a bug, they log on to your on-line bug database, and enter the data, they save the error message as a gif and upload the image. As Project Manager, you get notified by email of the bug, you log on to the application, view the image, review the status, assign a priority, and assign it to a developer. The developer receives the email, logs on and sets about fixing the bug. When completed, he logs back on to the application, enters a completed date, and an email is sent to the tester/client. The tester/client logs on, and is told what to test, reviews the work, enters a checked by date, and the final email is sent to the manager who closes the bug.

    Phew! That sounds like a lot of steps which is why most people resort to just sending an email. I believe most people send requests for tasks via email, if this is the case, why should developers have a separate "to-do" list, in the form of a bug-database in which they re-enter data?

    MS TFS has an Outlook addin which can save you a lot of this work called Team Companion. This has a number of benefits including:

    • Developers don't have to re-enter data
    • TFS fully integrates your bug tracking with your source control.
    • Managers can see important information like Tasks Completed and Tasks Assigned in TFS Reports
    • Clients can see what developers are working on via TFS
  23. Do you log every error?

    When you walk into a clothes store to exchange a pair of jeans, you expect to be treated with respect. The sales person should talk to you at your level, deal with your issues, and in a polite and fair way handle your problem. Developers should not expect software users to be treated any differently​.

    Every error message you put into your products is an opportunity for good service. Users don't want to see "Run-time error. Can't save record with zero length string", instead the User should receive a message that helps them through the situation.


    Figure: Log every error

    Not to say though that there is any ideal error message - a great error is one that has been eliminated! In packaged products, every unhandled error is our problem.

    In the old days, unhandled errors would be stored in a local Access db, but now all unhandled errors should be automatically emailed to the product team. This is a proactive and polite approach to dealing with unhandled errors. If it's serious we will contact the client to resolve the situation - they get a bit of a surprise and think we have ESP!

    Remember what it is like to have good service in a restaurant. A good waiter knows when to interrupt you, when to leave you alone and how to do it all in a courteous and respectful way.

    Read more about Do you log every error?
  24. Do you provide your users with a Validate Menu (aka Diagnostics)?

    We recommend adding these menus to your Tools Menu:

  25. Done - Do you go beyond 'Done' and follow a 'Definition of Done'?

    ​Having a clear Definition of Done for your team is critical to your success and quality management in Scrum.

    Every team is different, but all need to agree on which items are in their "Definition of Done".

    There are 3 levels of 'Done' in communication

    Level 1

    Level 2

    • Sending a "Done" email
    • Screenshots
    • Code

    Level 3

    • Sending a "Done" email
    • Recording a quick and dirty "Done Video"
    • Code (showing a full scenario e.g. a user story)

    Example of a level 3 "done"

    Subject: RE: Manad - Coded UI Tests #2

    > Create a new CodedUI test on your feedback form – search only to test the Telerik


    Coded UI Test passes in Visual Studio Figure – Coded UI Test passes in Visual Studio

    Jing Video of the test running:

    Figure: Good example - The "done" shows a full scenario

    There are 8 levels of 'Done' in software quality

    Start with these examples showing typical "Definitions of Done" from beginner teams to more mature teams:

    Team - Level 1

    • The code compiles
    • All tasks are updated and closed
    • No high priority defects/bugs are on that user story

    Team - Level 2

    • All of the above, plus
    • All unit tests passed
    • Greater than 1% code coverage (not earth shattering, but you need to start somewhere)

    Team - Level 3

    • All of the above, plus
    • Successful build on the Build Server
    • Git Branch Policies
      TFS Check in Policy - Change set Comments Policy (all check-ins must have a comment)
    • TFS Check in Policy - Work Items (all check-ins must be associated with a work item)
    • Code reviewed by one other team member (e.g. Checked by Bill)
    • Sending a Done email with screenshots
    Check in policy
    Figure: Good example - Add check in policies to enforce your Definition of Done

    Team - Level 4

    • All of the above, plus
    • All acceptance criteria have been met
    • All acceptance criteria have an associated test passing (aka. Automated functional testing with Web Tests (Selenium), Coded UI Tests, or Telerik Tests)
    • Tip: Use Microsoft | Test Manager
    • Sending a Done email (with video recording using SnagIt)
    Figure: Organize tests in suites with built-in E2E traceability across requirements, test artifacts and defects
    Figure: Use the client, Microsoft Test Manager, to run tests and not just capture the pass/fail of steps, comments/attachments and bugs, but also capture diagnostic data during execution, such as screen recording, system info, image action log etc
    Figure: Explore your web applications, find and submit bugs directly from your Chrome browser – no need for predefined test cases or test steps
    Figure: Good example - Done video showing the features worked on

    Team - Level 5

    • All of the above, plus
    • Deployed to UAT (ideally using Continuous Deployment)
    • Complex code is documented (removing technical debt)
    • Product Owner acceptance

    Team - Level 6

    • All of the above, plus
    • Multiple environments automatically tested using Lab Management
    Lab management
    Figure: Good example - A tester Lab Management to create VMs for testing the application, then defines a test plan for that application with Test Case Management

    Team - Level 7

    • All of the above, plus
    • Automated Load Testing
    • Continuous Deployment
    Acceptance Tests in MTM
    Figure: Good example - Load testing involves multiple test agents running Web Performance Tests and pounding the application (simulating the behavior of many simultaneous users)

    Team - Level 8 (Gold)

    • All of the above, plus
    • Deployed to Production

      Congratulations! You are frequently deploying to production. This is called “Continuous Delivery” and allows you to gather quick feedback from your end users. 

      You might have everything deployed to production, but it might not yet be visible to the end user. This can be achieved by having “Feature toggles ” in place. The actual release of the functionality is a decision that the Product Owner and business takes.

    More Information:

  26. Management - Do you fix bugs first?

    This rule has been important for a long time: Fix bugs before adding functionality.​

    • Bugs get more expensive as they get older
    • Bugs become more complex the longer you wait to fix them
    • You have better access to the developer who created it who will be able to fix it faster

    Failing to follow this rule encourages developers and creators to focus on new 'interesting' functionality which is exactly what you don't want...
    You must be strong in the face of pressures from project plan scheduling!

    Note: The principle of this bug rule can apply to more than just developers.

    Let's suppose you work in Marketing and have a problem with a hypothetical report. You should fix that issue first, before adding new information to the report.

  27. Do you write end-to-end tests for critical happy-paths?

    It’s not uncommon for critical workflows in projects to become flaky and brittle, and on occasion, this will not be caught until the product hits production.  An example of a critical workflow is placing an order on a shopping cart, or adding a timesheet in a time tracking site.
    These are workflows that, if errors occur, the product becomes rather useless, and thus needs to be strongly tested.

    The best way to test this workflow is by performing the workflow against a real environment, using a real browser – of course, in a repeatable, consistent way.
    A nice option is to use Seleno​ with an appropriate web driver for the desired browser – see the Seleno documentation.  This library lets you write code to drive a user’s action in a browser, including  for example logging in, searching for a product, adding it to the cart, proceeding to checkout, entering test credit card information and ensuring the success message.
    This isn’t free though.  The nature of these tests mean that without proper care and maintenance, tests will fail intermittently.  There are difficult-to-predict timings, DOM changes and browser compatibility issues and ongoing maintainability - so it is beneficial to limit these kinds of tests to critical happy-paths.
    Figure: Bad example - No end-to-end tests, no automatic feedback when things go catastrophically wrong
    Figure: Good example - End-to-end Seleno tests run in Continuous-Integration, giving us very rapid feedback when the deployment breaks
  28. Do you know where to keep your files?

    ​Each client project should have a nice place to keep files. In the old days, things were simple but limited, we simply used Windows Explorer and file shares. Today there are so many places that teams can store documents e.g. Dropbox, OneDrive, SharePoint, TFS, and even Microsoft Teams.

    Which is the best corporate solution?

    The solution that allows the best collaboration with Developers, Project Managers, and other stakeholders is SharePoint and Microsoft Teams. It is super easy to create, upload and share documents with others.

    What stuff do you need to store?​

    For most projects you need to quickly store and locate important details and documents such as:

    • Server details (Dev, Test, Production)
    • Change-log documents
    • Upcoming features (most often in Word or OneNote)
    • General documents e.g. Requirements/Specifications (Note: it is possible to share documents from Microsoft Teams externally, but not from Teams directly... just open it in ​Office Online or a specific Office app first)​

    Keep Files Bad Example
    Figure: Bad example – It might be easy to use File Shares, your Local C: or emails – but don’t. They don’t work in a team environment as they aren’t easy for others to access
    Keep Files Bad Example
    Figure: Bad example – SharePoint integrated into TFS is not supported via Visual Studio anymore
    Keep Files Bad Example
    Figure: Bad example – even though this is using SharePoint - this is using a Team Site with a Document Library - it is better to use Microsoft Teams which uses SharePoint under the covers
    Keep Files Good Example
    Good example: Use Microsoft Teams and it will automatically create a Site for the Team (and that includes a document library which you can connect to with OneDrive)

    What does not get stored in Microsoft Teams? 

    1. For developers,

    ​A: code obviously belongs in github, azure, devops, etc.

    B: Also the 6 important documents should be stored in Azure DevOps (was TFS/VSTS).​​.. or instead use Markdown with the Wiki

    2. For designers with large files, OneDrive is a better choice. See: Do you know the best Source Control for Designers?

    What about usernames and pas​swords?

    Documents with user names and passwords should not be stored in Microsoft Teams. Security is very important for everyone and every company. Use Azure KeyVault or KeePass to store usernames and passwords. KeePass keeps all passwords in one database locked by a master key, which should be accessible only by the few people you trust.

  29. Do you 'zz' old files rather than deleting them?

    ​​​When you are regularly creating new releases of a cool .NET application or simply producing new proposals in Microsoft Word, files will inevitably become outdated. Rather than hit the DELETE key put a 'zz' at the front of the filename. The old versions should not be deleted straight away - it is just an unnecessary risk! The zz'd files can remain there until you need more space, then you should delete them.
    Obsolete old files aggressively Figure: 'ZZ' your files rather than deleting them!

    Alternatively ​add a folder named zz and move the outdated files into the new folder.

    Note: Other systems are used that are less aggressive than our 'zz' rule.

    • In .NET, the keyword obsolete​ Leave site is used to mark types and members of types that should no longer be used - these then turn up as a compiler warning.
    • In HTML, the keyword deprecated leave site is used.

    Both allow for some backward compatibility.

    See our Rules to Better SQL Server Databases - Do you add zs prefix to table name?

  30. Do you know the best way of managing recurring tasks?

    ​Recurring tasks are tasks that happen on a regular basis, but not necessarily every day (and therefore potentially easy to forget!). They might be personal tasks, such as changing the oil in your prized Datsun 120Y every six months, or booking a holiday for you and your partner a month before your anniversary. They could be work related tasks, such as updating your profile on the Microsoft Gold Partner website (every three months), running financial reports on a monthly basis, or even watering the office plants every week.

    Now managing those tasks can be difficult. "Just stick an appointment in Outlook" - yes I've heard and tried that method. Outlook is perfect when you are the one performing the task. But it's nowhere near perfect if you're managing people who are allocated to perform the task. In fact it's a disaster, because when that person leaves, (or just changes job role) that scheduled task/reminder disappears with them.

    The other problem with Outlook is if you are an organization that relies upon email as a to do/task list, Outlook doesn't send an automated email.

    After reviewing a few different options, we decided using Google Calendar to manage recurring tasks was the best option.

  31. Do you constantly add to the backlog?

    In the course of work everyone encounters bugs or problems. They can be dealt with by either:

      1. Pretend you didn't see the problem
      2. Fixing it straight away
      3. Add the issue to the backlog so someone else can fix it

    The best solution is to use a combination of 2 and 3.

    • If it will take less 15 mins to fix, do it straight away.
    • If it will take more time, add the problem to the product backlog and email a link to the appropriate person (even if it’s a third party product).

    This approach raises the question of priorities. If you hit too many hurdles you continually get diverted from the main task: for example when fixing the Client form you encounter a problem with the Client Contact form which breaks the Products form etc. (This can be described as the "Tree Approach" as opposed to the "Straight through to the Goal approach".)

    You need to try to balance short term productivity with long term improvements. My view is that it is better to get 2 things done at 100% than get 4 things done at 75%! At a minimum, always add the issue to the backlog.


  32. Do you have a Knowledge Base (KB)?

    ​​Do you know what the most useful thing on Microsoft website is? It is their knowledge base at​ ​ When a problem arises it should be your first port of call - it allows you to help yourself. ​

    So, if you answer questions on your products to customers, you are wasting time if you don't have a knowledge base. Just think, you might not be answering Harry's question if he could have looked it up himself.

    Now of course there are many customers who don't look for a KB, but instead you fire off the same old email that you already know is an MDAC related error, and your current solution is to tell them to run SSW Diagnostics and get all the green ticks.

    Dear Harry,

    Thank you for taking the time to report the issue for SSW Code Auditor. I'm happy to let you know that this is a known issue and has been addressed in our knowledge base.
    John Prince
    Figure: Responding to a known issue with a KB article

    The basic rule is:​ don't send back the answer in your email - instead send back the link. More specifically:

    1. If you can answer a support email then reply to the support email (using one of the 4 templates on the right)
      • TO: the client
      • CC: the developer and your manager with the KB link
    2. If you can’t answer the question then reply to the support email
      • TO: the client and the developer
      • CC: your manager
      • Ask the customer if they can get diagnostics to all green ticks.
      • Ask the developer to “Please action?"

    Dear Harry,

    Thank you for taking the time to report the issue for SSW Code Auditor.

    I am sorry to let you know that I cannot reproduce this. Could you please provide me with more details or, even better, would I be able to connect to your PC? It is simple and you can see everything I do. To do so, you can send me an appointment for an appropriate time or add me to your Skype

    P.S. Don't forget to run SSW Diagnostics, ensuring that you only get green ticks.

    Kind Regards,

    Figure: Responding when you cannot reproduce the issue

    Dear Harry,

    Done. The code changed from


    Thank you for reporting this bug - our software only gets better with help from our customers. This fix will be available in the next version shortly. In the meanwhile, download an interim build.

    Kind Regards,

    Figure: Informing of a Fix (Email 1 of 2) Note: In this email, you can offer them an interim build

    Dear Harry,

    Thank you for taking the time to report the issue for SSW Code Auditor. I'm happy to let you know that this problem is fixed in this release.

    Please download the new version at

    P.S. Don't forget to run SSW Diagnostics and gets all green ticks

    Kind Regards,

    Figure: Informing of a New Version (Email 2 of 2)

    Notice how by just giving them the URL, this email does the job of encouraging them to use your knowledge base in the future. You need to make sure the support staff know that there are really only 4 types of emails customers should be receiving (see the 4 grey boxes).

    Things are running well when you have support staff adding new KB for:

    • Known issues
    • Hot tips
    • Performance tips KBs also play a very important role in getting a product released. You will never get every feature done or bug fixed - we all know it. Focus on getting a version out. It is usually more important to have a version available than having no version at all. When you are looking down the Project Plan, decide on what the *must haves* are. The others features and known bugs will have to remain outstanding. All the longer term bugs should go into the KB. We also put in the feature requests that we plan on doing. This way our customers know of our exciting features coming in future versions of our software.

    However *don't* write a KB article if fixing the bug and making a new version solves the problem. You'll have to fix the problem anyway, so don't waste time writing a KB, just email the new version. Please see How to Develop and Reply "Done"

    You don't need to be Microsoft to build a KB. A Knowledge Base does not need to be complicated. We use a simple knowledge base which is located at

    Suggestions for features should be added to the backlog and voted on at

    Dear Harry,

    Thanks for the suggestion for SSW Code Auditor!

    I have added it to the list of future developments (which we call our backlog). Future features can be voted on at uservoice. com .

    John Prince

    Figure: Responding to a Feature Suggestion
  33. Do you know the best way to give the best customer support?

    There are a few methods to control a client's machine remotely, all of them have the same functionality, but different usage, and different pros and cons.

    Desktop support

    For supporting end users' workstation machines remotely, here is the order you should try with the end users:


    For server machines, we recommend using either Windows' built-in Remote Desktop (also knows as "Terminal Services") or a VNC-based tool. Remote Desktop provides each authenticated user a Windows login session that is not shared. If your client lives in a place where the time zone is different, Remote Desktop should be your first choice as it doesn't need the client's interaction once Remote Desktop is enabled (typically it should have been enabled for a server for the ease for remote maintenance and monitoring). For servers, Remote Desktop is usually enabled via a group policy (AD GPO), although it can also be enabled through Windows System Properties.

    remote connection
    Figure: Enable Remote Desktop

    Remote Desktop works for workstations, but it's not recommended due to a security risk if Remote Support isn't disabled. Also, because of the End User License Agreement (EULA), only allows 1 user at a time, if you log in to client's Windows machine, the client will be logged off.

    If you can't use TeamViewer, Skype, or Remote Desktop, you can try VNC. There are a number of VNC servers and clients available. VNC-based sessions typically behave as if you're physically using the computer. This means that it shares the same login session with the user who is currently logged on the machine. VNC software allows you to configure a specific username and password for remote access, which means that you don't have to share Windows usernames and passwords or create a temporary Windows user account. Some clients may also prefer this as they can sit in and watch what is happening.

    The VNC tools we prefer: ​​TightVNC and​ Ultra VNC.

    Read SSW Remote Support Standard.

  34. Do you always install latest updates when you fix someone else's PC?

    ​When you fix someone else's PC (locally or remotely), one of the best practices is always make sure it has the latest updates.

    To achieve this, we run Microsoft Updates (not to confuse with Windows Updates) and install all latest updates for all the known Microsoft products.

    Note: "Windows Update" only updates the operating system, where "Microsoft Update" updates other products as well, such as Microsoft Office, SQL Server, etc.

    Microsoft Update Figure: Microsoft Update (Good - all updates are installed)

    And then we run SSW Diagnostics to check the latest version of other applications (mostly non-Microsoft) are installed.

    Warning: Of course if you are fixing a bug on someone’s PC, you should only update one piece of software at a time, so you know if an update fixes the problem. After that (if the company allows it), update all software to the latest version. If they get a new problem, then rollback.

     SSW Diagnostics Figure: SSW Diagnostics (Good - all updates are installed)
  35. Do you stop dealing with Data and Schema?

    Why don't most developers plan ahead? Take an average Desktop application that you sell to a few customers. When the customer wants a new version, there is no problem giving the customer the new exe. But what if you made a back-end structural changes to your database? Big hassle! You need to compare the database to remind you what was changed. Sure there are utilities for this - for Access back ends you can use SSW Data Renovator or for SQL Server back​ ends there is Red-gate SQL Compare - but why go to this trouble?

    Version control for your Schema and where required your Data should be an important part of planning your projects.

    For more information read Rules to Better SQL Server Schema Deployment​

    ​We have a program called SSW SQL Deploy to solve this problem and automatically make schema changes.

  36. Do you have separate development, testing and production environments?

    It is important to maintain three separate environments for development, testing and production. Some companies skip the testing server because it can be a hassle to copy new files, register DLLs and deploy backend changes. This will usually result in higher support costs and unhappy users due to simple bugs that could have being found in testing.

    The best solution is to use build scripts (.bat and .vbs files) to automatically create a setup package that can be used to deploy to testing and production environments. For backend changes, you can either include the change scripts with the setup package (if it's a localised database), or run those scripts as part of your deployment process.

    Read more about setup packages at SSW's Wise Standard for Products.

    Now make each environment clear.

    Whenever an application has a database, have a visual indicator. I recommend a different background color for each environment

    • Red for the Development database
    • Yellow for the Test database
    • Grey (no colour) for the Production database

    Note: The Yellow might have been Orange (kind of like traffic lights) but the color palette in Word doesn't give Orange.

    colors in Word color palleteFigure: colors in Word color palette

    This prevents testers from accidentally entering test data into the production version.

    Windows Forms Tip: Implement in the base form in the header
    ASP.NET (at least version 2.0) Tip: Implement in the master form in the header

     Figure: Spice up your environments with different colors

    An application of this rule is how we identify our CRM servers - see rule Do you identify Development, Test and Production CRM Web Servers by colors?

  37. General - Standards Watchdog - Do you help everyone to learn the rules?

    "An ounce of prevention is worth a pound of cure" goes the saying. Having a strict coding standard is prevention. To create good code you must have good standards, such as commenting standards, naming standards, versioning standards and knowing the value of consistency

    But this can really only happen if you’re going to go the extra mile and stick your neck out and correct someone.

    Figure: Bad Example - Correcting someone in a mean way
    Figure: Good example - People make mistakes but correct them as though they’re a soft cute puppy 🐶

    Every member of a team plays an important role in maintaining standards. Whether it's your work or someone else's, always keep an eye out for things that can be improved.

    This rule applies to all company standards. Standards are important because they ensure your experience at work is consistent and enjoyable. For example, if there was no standard to stack the dishes in the dishwasher when you were finished using them, dishes would build up and create a big mess in the kitchen!

    Be nice, not harsh 

    Do you know the nice way to correct someone?

    Small things = Tiny Tip

    When the 'mistake' the person made is not an actual mistake, but something that the company has decided to do in one way for consistency, without a strong argument.

    Tiny Tip: I’d use international format on your phone number so people outside Australia can just click to dial - as per

    Figure: Good example - nicely informing of a small standard oversight

    Important things = Tip 

    When there is a proven better way to do something different from what the person has done. You should try to include the reasons.

    Tip: I noticed your email has a very generic subject: "website". Please resend with a descriptive email subject as per Rules to Better Email. This way it is easier to identify, categorize and find this email later, without having to open it :)

    Figure: Good example - nicely informing of a better way to do something

    Crucial things = Critical

    When the error the person committed can lead to a misunderstanding or a security breach. You should include a task with action when necessary.

    Critical: When sending a proposal never use the word "quote", but use "estimates" instead. As per Rules to Better Project Management we don't work with a fixed price, which is opposite to what the word "quote" implies. This might create different expectation and consequently frustration and legal problems with the client.

    1. Please fix asap

    Figure: Good example - nicely informing of a critical mistake

    Coding - For Developers

    When you come across an error, don't just fix it, as the developer who made it is likely to make it again. Instead, write an email to the person explaining what has been done wrong and how you would've improved the code. CC relevant parties to improve others, to collect your brownie points or to set a good example.

    No one likes being corrected but hopefully, with everyone doing this in the office, it's not a matter of finger-pointing, it is working together to write better code or developing better solutions.

    Tip: In code, if you don't know who made the mistake, use the annotate tool.

    What if it's recurring?

    When you notice someone doing the wrong thing:

    • First time just send an email with a pointer to the rule
    • The second time, have a very quick chat with them
    • Third time call them in and give them a formal talk about it

    Focus on the meat first

    When you receive a great 'done' email or document, make sure you mention how great it is before correcting any potential error.

    Timing is everything - Don't bottle it up

    It can be tempting to offer your feedback as soon as you think of it, but it's better to hold off until the recipient is in a place where they can hear it. If a person is busy, distracted, or in a poor emotional state, chances are your feedback won’t hit the mark. Wait until the person is calm and relaxed before asking them if now is a good time to offer your feedback.

    For more, check out Do you know to create a safe space instead of jumping into feedback?​​

    Figure: Bad example - seeing a mistake and not pointing it out doesn't improve a person. Allow them to benefit from your experience!

    Going Anonymous

    When something is really personal, you can’t really correct someone unless you are a close friend and have credit with the person, so you should discretely ask your manager how to proceed in that specific case.

    Taking Feedback

    Figure: Good example - say 'thank you' to a person's corrections to show you don't have thin skin and encourage further positive and negative feedback. It all helps you to improve

    In Summary

    It's important to ensure others are doing their best to maintain and follow the standards. Remember, it can be just as important for someone's professional development to give feedback as it is to receive it. Being able to communicate feedback in an effective and professional manner can benefit you in any career.

    To: Peter
    CC: Adam (Manager)

    Dear Peter,

    While you were away, I came across this page you edited, called ApplicationForm.aspx which was giving an error: 
    'The conversion of a char data type to a DateTime data type resulted in an out-of-range DateTime value.' 

    Please note that whilst inserting data from your Front End application, you should not use the format dd/mm/yyyy
    Instead, you should use yyyy/mm/dd as per Rules to Better Databases.

    Let's fix it together when we get to work tomorrow.


    Figure: Good example - nicely informing of a standards violation 
  38. When you follow a rule do you know to refer to it (including the icon)?

    ​ When you follow a rule, remember to refer to its URL:

    RuleReference Good Example: Refer to the URL
  39. Do you thoroughly test employment candidates?

    ​​Do you rely entirely on the claims of Recruitment Agencies when selecting new employees? If you do, it may be a very costly mistake. I have been giving coding tests to new employees for 10 years. A candidate has to prove they can walk the walk before they can join our team.

    I give a Project Management test to coders as well. I want my coders to be able to contribute to the working of a project from end to end. They need to be able to communicate with not only sales and marketing staff, but also clients and people that walk off the street! Clients typically think developers (aka computer nerds) come from another planet. Getting Project Managers at the go between is good, but on many jobs it just adds a layer and an unnecessary cost to a job. Recruiting developers that understand the ins and outs of project management means that that developers have less reliance on a Project Manager, they get to speak to customers more (a very good thing) and the customer gets a cheaper solution.

    Another thing is that when interviewing you have to go on your instinct a bit. This won't always work, but as Joel says, "a bad candidate will cost a lot of money and effort and waste other people's time fixing all their bugs." It's best to let a good candidate slip occasionally than let a bad one spoil your coding and client relationships. Joel again: "If you have any doubts whatsoever, No Hire."

  40. Do you have a healthy team?

    Developers are notoriously unhealthy people. They don't exercise enough, don't sleep enough and eat the wrong food. An unhealthy developer is not going to be able to concentrate or put in the hard-yards when required, nor are they going to be very happy. In the office I try to look after them as best I can by:

    • Not having chocolate biscuits and instead keeping a bowl of fruit
    • Not having coke machines and instead having a purified cold water bottle in the middle of the office
    • Encouraging them to do as much exercise as possible - even doing push-ups every day.
    • And instead of dinners for birthdays where you eat and drink all night, every few months we always do something fun for someone's birthday, like indoor climbing, ten-pin bowling or even a bush walk in the Blue Mountains.​

    I also conduct a monthly weigh-in, with incentives to look after yourself. I don't encourage my developers to stay up all night investigating new stuff, and I take them away for a two weeks every year to work by the beach and get some fresh air into their system, as well some early morning swims.

    I find that encouraging a healthy life-style really helps my team be more productive and have more fun.

    Read more about Do you have a healthy team?
  41. Do you know how to deal with distractions?

    ​​Keeping your mind on the job is very important, especially when you're trying to fix a bug/issue or finalize a task to meet this afternoon's deadline. Here is how you keep "in the zone":​

    1. ​Refer people to standards and you will be helping them learn + reducing the number of interruptions they get. This is why we invest in the SSW Rules.​
    2. Avoid multi-tasking as much as possible. Don't open an email, respond to half the questions, and then open another. Complete the first task and then delete the email. When you multi-task, there’s a higher chance your work quality will be dropped, as well as your attention to detail.
    3. Set your Browser's default to "About: Blank"  so you don't get distracted by news or social media, for example. Tip:​​ There is an extension for Google Chrome to replace your homepage called Momentum​, where you will be shown a photograph as the background, time, greetings, and your own focus for the day.
    4. Minimize Phone distractions. If you are in a meeting, it’s a good idea to put your mobile phone to “do not disturb”.
    5. Minimize Microsoft Teams distractions​.
    6. Minimize Outlook distractions.
    7. Minimize Skype distractions.
    8. People should avoid distracting you - using IM unnecessarily can be evil. See Do you know important chats should be in an email?​
    9. People will interrupt you less if you let them know what you are working on. Tip: Use the Teams status to let people know what you are doing (saves them having to ask you). See Do you use the status message in Teams?
    10. Whenever you can, programming/working in pairs is great as it means you will be forced to focus, you won't cruise the web, or play Solitaire.
    11. Use a concentration technique, such as Pomodoro​.

    Square SM photos.png
    Figure: Multi-tasking can be your deadline's enemy
    ​​Figure: The ​Pomodoro technique uses a timer to break down work into intervals, traditionally 25 minutes in length, separated by short breaks.
  42. Do you always carry your Tool Box?

    ​Carrying your laptop with the right stuff installed is not enough. 

    Not only software, carrying your own hardware and peripherals will save you hours one day:

    Here are the things you should also physically carry:


    Carry the right tools and you'll rescue someone, one day...
    Figure: St. Bernards are known for rescuing lost mountaineers, bringing life saving provisions


    • Business cards
    • A network cable (optional)
    • An extension cord (optional)
    • A thumb drive on your key ring (a personal choice, but 16 GB is a good choice)
    • An external hard drive (a personal choice, but 750 GB if a good choice if you have lots of 10+ GB VMs)
    • Software DVD's (generally you can keep the .ISOs of MS Office and Visual Studio D:\DataSetup\ISOs\)
    • Current brochures - Hand them out to interested clients
    • User story cards - These help Product owners create user stories
    • Evaluation forms - Ask for feedback if you did a presentation
    • Even a text book or two

    We have one guy in our office who carries two bags, each weighing about 10 kgs. He is the SSW St. Bernard! *

    If you need to quickly share something with your mate:


    * One of our mean guys put a house brick in the bottom a bag to see if he noticed it. He carried it for 2 weeks. It was very funny.
  43. Do you use an Internet/Intranet for sharing common information such as Company Standards?

    Employees need easy access to standards that are used everyday. We maintain standards at SSW for any activity that can be standardized including coding practices, naming conventions, standard form layouts and documents. There are also internal standards like expense and leave procedures.

    The first step is to use HTML rather than MS Word documents.

    The second step is to think about location. Should it go on a Web site or Intranet? We believe in dividing it up into 2 groups:

    • Public - e.g. /Standards
    • Private - e.g. /Standardsinternal
    The benefit with standards on the Web is to get feedback from other developers. See our SQL Server Naming Standards for an example.

    The third step is to decide on a web page theme so every page is consistent. I am continually surprised at how much time is wasted by managers explaining to web designers the corporate template - so get smart and do one up that they can follow.

  44. Do you know the best CMS solutions for your Internet/Intranet?

    ​​You don’t want to build solutions from scratch, take the business value you can, from a CMS and a CRM. Don't reinvent the wheel.
    The main choices are:

    There are pros and cons to all and it depends on what functionality/customization you need but we lean towards Orchard and SharePoint for most solutions.
    See The leading CMS Solutions.

  45. Do you manage your papers?

    ​It is common during the course of a project to assemble a pile of papers of notes and other information related to the client you are working with. Some of these will be tasks that relate to the project, some will be general information that does not require any action, and some will have no use. In any case, it's important that you don't lose anything that may be needed later.

    At SSW we use the following system for managing papers around the office:

    All SSW staff are allocated a physical inbox. You must check it daily to ensure that it is kept empty - this is where papers relating to your projects will end up.

    1. Paper is related to a task:
      • Send an email to yourself with 'Note to self' in the subject line, and the task in the body.
      • Throw the paper away.
    2. Paper has no use:
      • Throw the paper away! Examples of this would include your own notes that are no longer relevant.
    3. Paper is not a task but needs to be kept anyway:
      • The SSW filing system is split into 3 categories: current clients, past clients and SSW internal. It is your responsibility to make a new folder if one doesn't exist for your client (filing supplies and the label maker are in the machine room). Write the ClientID and your initials and date in the top right hand corner of the paper. e.g. HOED - CA - 11/11/2000.
      • Hopefully any papers you may have will be related to current clients. Paper in this category include Non Disclosure Agreements, and Terms and Conditions. File the paper in the clients folder.
    Read more about Do you manage your papers?
  46. Do you avoid reviewing performance without metrics?

    ​If a client says:

    "This application is too slow, I don't really want to put up with such poor performance. Please fix."

    We don't jump in and look at the code and clean it up and reply with something like:

    "I've looked at the code and cleaned it up - not sure if this is suitable - please tell me if you are OK with the performance now."

    A better way is:

    • Ask the client to tell us how slow it is (in seconds) and how fast they ideally would like it (in seconds)
    • Add some code to record the time the function takes to run
    • Reproduce the steps and record the time
    • Change the code
    • Reproduce the steps and record the time again
    • Reply to the customer:
      "It was 22 seconds, you asked for around 10 seconds. It is now 8 seconds."
    Figure: Good example – Add some code to check the timing, before fixing any performance issues (An example from SSW Code Auditor)

    Also, never forget to do incremental changes in your tests!

    For example, if you are trying to measure the optimal number of processors for a server, do not go from 1 processor to 4 processors at once:

    Figure: Bad Example - Going from 1 to 4 all at once gives you incomplete measurements and data

    Do it incrementally, adding 1 processor each time, measuring the results, and then adding more:

    Figure: Good Example - Going from 1 to 2, then measuring, then incrementally adding one more, measuring...

    This gives you the most complete set of data to work from.

    This is because performance is an emotional thing, sometimes it just *feels* slower. Without numbers, a person cannot really know for sure whether something has become quicker. By making the changes incrementally, you can be assured that there aren’t bad changes canceling out the effect of good changes.​


    For sample code on how to measure performance for Windows application form, please refer to rule Do you have tests for Performance? on Rules To Better Unit Tests.

    Related Rule

  47. Do you ring a bell or similar when you secure a big deal, make a sale or get some great feedback?

    A great way of motivating your staff is to have some form of recognition in place; happy employees are good employees! One of the simplest ways to achieve this is by having a bell located within the office for employees to ring when they have made a large sale, secured a big deal or some important news to announce. By showing appreciation to your employees you encourage all your staff to perform.

    At SSW whenever a big new project is signed up, we sell an enterprise license for one of our products, or we release a project into production we send an email to all staff and then ring the bell, which is located in the middle of the office.

    Ring the bell Email Figure: We send around an email like this and ring the bell when we get good news!

    Similarly, when we get some feedback we will send around an email.

    As a company owner or manager, you might want to see who of your employees are contributing to this feeling of appreciation around the office, and you can do that by querying your Exchange Server for threads with "Ring the Bell" in the subject

  48. Do you know you should always use a source control system?

    ​Level 1: Use Source Control. 
    You should always use a source control system! SSW uses and recommends Team Foundation Server (TFS).
    It is not for a backup, it is because changing code can introduce new bugs. Often these bugs are non-obvious ​​​and appear in a part of the system, far removed from your changes. They are especially useful when another developer made the breaking change.
    So source code tracking allows you to see what changed recently to introduce a new bug. This dramatically reduces the time it takes to find and fix a newly introduced error.

    Level 2: Do you integrate your source control with your bug tracking tool?
    Source control works best when integrated with a task tracking system. SSW uses and recommends Microsoft Team Foundation Server which allows you to check in changes and link to the work item (Bug or Task)... all from within Visual Studio.
    Tip: If your systems are not integrated automatically, you can still integrate manually by convention. Just quoting the work item or bug ID in comments, whenever a source code change is committed.
    Whatever you use, your toolchain/process/IDE should fulfil the following user stories:

    1. As a developer working on a code file
      I want to easily view a file’s change history and navigate to the work items that were associated with the changes
      So that I can fix a recently introduced bug quickly
    2. As a senior software developer
      I want to browse work items of junior developers, and have it linking/showing the code
      So that I can easily review their recent code

    SSW Rules to Better Source Control

  49. Do you know what to look out for when signing legal documents?

    Make sure there are no specific damages mentioned in any legal document. They should always be left to the relevant courts to decide.
  50. Do you ask clients to initial your work?

    ​​​​A person's signature is extremely valuable. Getting a signature is hard work. Salespeople use all sorts of euphemisms to avoid that confronting request: "if you could just sign here..." ​

    However, requesting a signature (or just an initial) on non-contractual type documents (especially screenshots, mockups, or data-schemas) is very beneficial. 

    When you ask a client to 'review this screen mock-up' they will generally take a cursory glance, perhaps make a comment or two and then move on to something else. Asking them to initial/sign the document always makes them take a second or third look, ask someone else, or at least spend a few more minutes working out whether it's correct or not.

    Training clients to review the work carefully leads to better quality projects. 

    Figure: A signature can be very valuable but sometimes hard to obtain, like Michael Jackson's autograph

    Related Rule

  51. Efficiency - Do you always try to work in pairs?

    ​​​​There are many good reasons why it's better to work in pairs.
    Do you always try to work in pairs?
    Figure: Do you always try to work in pairs?

    For everyone:

    • Less time stuck on a problem - you have someone familiar with the project to help you work through the problem
    • You can keep each other motivated  and you absorb knowledge from each other
    • Experience shows that people are more productive. As per​ Strengthening the Case for Pair-Programming

    Extra for d​evelopers:

    • Your code will have less strange workarounds - because if something doesn't add up to a developer, he has someone to ask
    • Cleaner code - because you know someone else is going to be looking at your code
    • Support - when you need changes down the track, you have two people to call on

    "I have found developers work better in pairs. I am not a fan of the classical pair programming - which is 2 developers working on the 1 PC. There are times for that especially during brainstorming activities, however on a day-to-day basis, I advise that developers work in pairs, but they each have their own PC."

    - Adam Cogan​
    SSW Chief Architect + Microsoft Regional Director

    If you are not sitting next to a person working on the same project, then fix it. If you cannot then at least mention it to your manager.

    Figure: Bad example - This is normal ‘pair programming’, two people working at one PC
    Figure: Good example - This is ‘working in pairs’, two guys working on the same project, with their own laptops, but sitting very close to each other

    Is there an overhead?

    Some projects are done quicker with two people - especially when they are complex. But on most projects there is an overhead, because of the extra communication between the developers - you now have to please someone else - not just yourself.

    Estimates vary for the overhead, but say it is 20% extra, this is more than offset by the cleaner code and better solutions that come from two brains working together.

    What if you are working remotely from each other?

    If you are working with someone remote, you will be using an application like TeamViewer or another support tool to view one another's desktops so you can help each other out when necessary. You should have TeamViewer showing on a 2nd monitor.

    What is the best code collaboration tool?

    Visual Studio Live Share - See Video (3 minutes):

    Please complete this survey on Working in Pairs.​
  52. Do you perform migration procedures with an approved release plan?

    A migration from one technology to another is a process fraught with danger. Everyone would love the "upgrade" button to work perfectly but it doesn't. Expect any migration to fail first go. Any statement that "I didn't expect to have any problems" shows inexcusable ignorance.

    A release plan for a migration will typically include:

    1. Business purpose for migration
    2. Test migration
    3. User Acceptance Testing of the test migration
    4. Rollback procedure
    5. Decommissioning procedure

    Approved release plans are mandatory for a migrations such as:

    1. Exchange Server 2003 to 2007
    2. ISA Server to a hardware firewall
    3. Phone system to VoIP
    4. etc.​
  53. Do you know you should always refer to rules instead of explaining it?

    ​When a new programmer on your team needs to get up and running on the SharePoint image you know the right and wrong way to say it.

    Sit with John Liu and he will get you up on our SharePoint image ​​​
    Bad Example: Explain how to run the SharePoint image
    ​Get the URL to the standard from our intranet, if the standard is unclear, check your changes with John Liu and​​ then make them
    Good Example: Refer to SharePoint rules
  54. Do you use Expression Blend + SketchFlow to create mock-ups?

    Mock-ups are very powerful tools to communicate requirements with clients, however it could be very time consuming and costing to create a good looking mock-up. Also, we don't want to "create and throw" our mock-ups, they should be picked up by developers and add features on top of them once the client approves the work.

    Using Expression + SketchFlow, you can:

    • Quickly create sketch-style mock-ups with little efforts,
    • Share your mock-ups with the whole team and clients easily,
    • Collect feedbacks from clients,
    • Use them in development process directly (as they are real Sliverlight and WPF solution files)

    Figure: Expression + SketchFlow

    Read Do you conduct specification analysis by creating mock-ups? to learn more about other mock-up types.

  55. Do you Reward your developers for completing a release on time and budget?

    ​When your team has completed a release successfully, they should be rewarded with a morale boosting event such as lunch, dinner, the movies or bowling, so long as you can meet the following conditions:
    1. Budget - the release must be completed within the budget allocated
    2. Scope - no more than 50% reduction in work item hours
    3. Quality - must pass test please and get a mark of 7/10 or above from the client
    4. Time - the release cannot be delivered 50% over time e.g. if the planned finish date was 14 days (two weeks) after the start, then the release must be delivered less than 21 days after the start date​
    5. Release debrief - sent to the client and completed and a review of "Rules to better project management" by the project manager

    Subject: "Release completed on budget and customer happy - reward!"

    • Release - on time
      • Done.  Release was handed over on the deadline.
    • Release - on budget
      • Done. The release was fixed price
    • Scope - no more than 50% cut-out in items (count the work hours removed compared to the original total)
      • Done.  No items were cut from the release plan
    • Quality - must pass test please and get a mark of 7/10 or above from the client
      • Test please passed.  The client assigned 8/10
    • Release debrief to the client to be completed -  
      • Release debrief completed.  Rules to better project management reviewed.  Greater visibility of progress would be beneficial and remote access to staging server during development.
    • Our team will be celebrating our success by going for lunch.


    Congratulations on completing the project on time!  We will celebrate by going for lunch together at Bistro Paris on Friday!  We have a budget of $50 per team member!


    If you are available it would be great if you could join us.  Meet at the SSW office in Neutral Bay at 12:45pm.

    Figure: Email to accountant/team members and client informing of release success and reward event
  56. Do you know how to handover a project?

    A common source of pain, is picking up a project without a decent/complete handover. To have a successful project you must navigate over the problem of changing resources/people leaving etc.

    As soon as an employee has given their resignation notice, their manager should become responsible for ensuring a successful handover takes place.  Each project they were involved in should be reviewed and another employee with a matching skill set should be selected to receive the handover.  Handovers should be booked in for each project with both employees in attendance, as early as possible and with high priority.

    Once the handover is complete, the resigning employee should no longer work on that project so that any gaps in knowledge can be covered ideally before their notice period expires.

    Always ensure that you complete the following checklist and always send the email confirming the handover is complete.

    Here are the 8 steps you should follow for a good handover.

    1. Confirm current tasks
    2. Confirm future tasks
    3. Confirm the primary contacts
    4. Do a code review
    5. Review the client portal
    6. Confirm location of info and procedures (hopefully, these are on a wiki or SharePoint document library)
      • Source control. Make sure there is no stale or old branches. ​​​Check out: ​​Do you know when to branch in git?​
      • Database
      • Documents
      • How to Build and Package
      • Testing Steps and users and passwords to access the test and staging servers  
      • Deployment Steps
      • Servers and Passwords
      • Failure & Recovery Steps
    7. Test that the users, passwords, URLs and server details provided in the handover are correct by logging in with each
    8. Complete the Handover by sending an email with: As per our meeting the handover has been completed to my satisfaction

    From: Andy
    To: Gracia
    Subject: SSW - Northwind handover


    • Confirm outstanding tasks


    • Confirm planned tasks

      Get release 43 out.

    • Confirm location
      • Source control


      • Data storage


      • Deployment

        Make a build by using WISE
        Test: seadragon
        Production: squirrel

      • Failure & Recovery

        Do not work on the Master folder, work on local machine. If it has some issue, grab the file from master folder.
        Always backup master folder’s file before uploading the changes to the master folder

    • Update the Employee Responsibilities in SSW intranet


    ​​​Figure Bad Example - This handover is incomplete and light on details

    From: Andy
    To: Gracia
    Subject: SSW - Northwind Handover

    Done - As per our meeting the handover has been completed to my satisfaction

    • Confirm outstanding tasks


    • Confirm planned tasks

      Next release is Release 43.
      The aim of this release is to improve the reporting available from the management module with chart reports
      Query = tfs\Northwind\Work Items\Team Queries\All Work Items - R43 - Management Module Reporting

      Backlog is in TFS.
      Query = tfs\Northwind\Work Items\Team Queries\All Work Items - Backlog

    • Confirm location
      • Source control


      • Data storage

        file://server/DataSSW/SSWProducts/North wind

      • Deployment
        • Make a build by using WISE
        • Test db to connect to:

          server: seadragon
          database: SSWNorthwind_test

        • Production db to connect to:

          server: squirrel
          database: SSWNorthwind 

      • Failure & Recovery

        Do not work on the Master folder, work on a local machine. If it has some issue, grab the file from the master folder.
        Always backup master folder’s file before uploading the changes to the master folder.
        If a problem occurs, restore the backup of the master folder and restart

    • Update the Employee Responsibilities in SSW intranet


    • Complete Handover
    Figure: Good Example - This handover has lots of URLs and is complete

    If you need to handover only a single task there are more details here: Do you know how to hand over tasks (aka Emails) to others? ​

  57. Do you carry more than just the Microsoft Tool Box?

    A spanner might get a plumber through 90% of jobs, but he'll get stuck on the last 10% if he doesn't carry anything else.
    Microsoft tools are the most important tools we have, but they only cover the first 90%. I spend most of my time using Outlook, Visual Studio .NET, SQL Server Management Studio. However Microsoft tools don'​t do everything. Rather than spending our time recreating the wheel, we should always look out for non-Microsoft options or extensions that will save me time.

    We have these 3rd party tools installed and they make us better than developer next to us.

  58. Do you have a deployment plan?

    ​Instructions are very important when maintaining a project. When someone new joins the project, you want to make sure that they can easily find the documentation to do tasks like setting up the project and deploying it. See our rule "Do you make instructions at the beginning and improve it gradually for web projects"

    That being said, the deployment plan is an important part of the Instructions.docx. It should clearly layout all the steps required to:

    1. Deploy from scratch to a new server
    2. Update versions
    3. Rollback to a previous version
    4. Update Schema or data

    It should also include checks to verify the deployment was successful e.g.

    1. Check zsValidate.aspx​
    2. Check runtime settings (e.g. Payment Gateways, Google Analytics, Connection strings)
    3. Manual testing procedure (e.g. Place an order)

    This document should also be signed off by the project lead and verified by the client.

  59. Do you sometimes write off small amounts of time to keep clients happy?

    ​Sometimes a client may ask for a small amount of time to be written off and may not have a good reason (from SSW’s point of view). Normally this would mean that the time would not be written​ off. However, sometimes, in the interest of continuing relationships with valued clients, some time may need to be written off simply to keep the clients happy.
    This may seem counterintuitive since there is no logical reason to write off the time but in situations where it is necessary:
    • Make sure you are not setting a precedent (“This is a one off” or “We don’t normally do this, but...”)
    • Make sure you are not allowing yourself to be bullied (If the client seems entirely unreasonable or just expects a discount, they may need to be trained to our way of working)
    • Make sure that the potential for more work substantially outweighs the amount of time written off
    • Make sure that you are actually solving the problem, and not just giving a token gesture which may not fix the issue (e.g. just giving a discount as a way of placating a client who is unhappy about our project management methodology etc.)
  60. Do you draft all important agreements yourself?

    Any time you come to some verbal arrangement with an employee, client or contractor, which creates or varies a contract (for example changes to rates, deliverables etc.​), it's crucial you draft the agreement yourself.
    Figure: Can you really trust the other side to draft the agreement correctly?

    Sometimes, especially if you are an efficient manager and enjoy delegating, it's tempting to ask the other party to write up the change. This is a major risk:

    1. The other party may not even get around to drafting the agreement leaving you without a paper trail
    2. If they do draft the agreement it may not accurately reflect the conversation

    Take responsibility for any agreements you make. Draft them yourself and then send an email "as per our conversation".

  61. Do you know the best way to find a phone number of a staff member?

    Bad way: use the Global Address List in Active Directory, because you can’t update it from Outlook... Only an administrator can maintain the details
    Note: good UI as it is easy to find inside outlook

    Good way: use the Dynamics 365 (formerly CRM 2016) toolbar?
    Note: We have a suggestion that Outlook should allow you to put the CRM2016 URL into Tools | Options so this is better integrated

  62. Do you conduct a "test please" internally and then with the client?

    ​Test, test, test! Testing is the most critical part of any project. Before the delivery of any release the application must pass an internal "test please". Clients quickly become disillusioned if you have delivered a bug-riddled application.
    Do you want users to have good first impressions?
    Figure: Do you want users to have good first impressions?

    There are a number of different types of tests that you can perform:

    • Unit Testing:

      It validates the smallest testable parts of an application. Unit tests do not cover the UI layer. There is no industry standard 3rd party unit test tool but at SSW we use NUnit and Visual Studio Team Test.

    • White Box Testing:

      White box testing or structural testing is done knowing the internal code implementation and targeting specific aspects: for example security risks or a potential performance bottle neck. By looking at the implementation it helps to identify areas where the system could be flawed. Because the tests are designed to match the code, if the implementation changes, the tests will need to change.

    • Black Box Testing:

      Black box testing or functional testing, unlike the White box testing, doesn't rely on the knowledge of the internal code structure. It relies on the software specifications and requirements. The tests use valid and invalid inputs and check that the output is correct.

    • Integration Testing:

      Integration testing is performed when all the software components are put together. This testing should be done after each individual software component has passed unit testing. This type of testing highlights interface problems or misunderstanding of the software specifications where unit tests local to each component actually passed. Automated integration testing is essential and often run overnight due to the time it takes.

    • User Acceptance Testing (UAT):

      UAT or Beta Testing occurs at the end of the software development cycle (this could be at the end of a Scrum Sprint where the software is potentially shippable). As its name points out the end users will test the software and check it meets their acceptance criteria.

    • Security testing:

      Security testing is done to check that a system protects data and maintains confidentiality as intended. The concepts covered by Security testing can include: network mapping, vulnerability scanning, password cracking, confidentiality, integrity, authentication, authorization, availability, non-repudiation and virus scanning.

    • Performance testing:

      Performance Testing is used to determine the responsiveness, the effectiveness of a system under a given workload. Qualitative attributes such as reliability, scalability and interoperability may also be evaluated. Performance testing is often done along with stress testing.

    • Smoke testing:

      Smoke testing is done to ensure the system doesn't have any critical bugs that would make other types of testing unnecessary. This type of testing is generally performed on a new or fixed software. A Smoke test should cover essential parts of the application so it is said to be shallow and broad.

    Does the "Test Please" principle apply to more than code?

    Yes! A "Test Please", aka peer review highlights unseen errors, proposes new ideas for consideration or confirms the existing work as the best solution. A peer review can also effect cultural change amongst your development team as developers become more open to critiques of their work and comfortable with a 'continuous learning' environment. A "Test Please" will also be applied to:
    • Brief proposals
    • Release plans
    • Estimates​
    • Anything else being sent to a client
    • Anything else being sent to an employee of a sensitive nature
    • Anything being sent for public consumption - such as newsletters, print documents and or advertisements.

    Always put "test please" in the email body so readers know they are expected to react quickly.

    Lead Developer responsibilities

    Please cc the client in all your "Test Please" emails including internal ones.

    1. At the end of a release, prepare a "Test Please" email.  Create the email by copying the text from the sample Test Please Template .
    2. Get two testers to test your app - if it's a web app make sure one uses IE and the other Firefox.
    3. Specify exactly what is required to be tested by adding some bullet points at the top and highlighting in yellow, so it stands out from the template text. e.g.
      • Run Timesheet report
      • Check changing a rate
    4. Make sure the testers send one bug/suggestion per email.
    5. Triage emails as they come in for completion in this release, or a later release.
    6. Don't change testers in the middle of a release. It is just sneaky to get a test failed from a tester and then try again by using another tester :-)
    7. Make sure that the testers know which build they are testing. The developers may be 3 builds ahead of the testers, but they need to complete a test run on an individual build to make sure that bugs are fixed and that there are no regressions.

      Note: Having a good branching strategy makes this easy as you can run an Internal and External "Test Please" on your DEV branch before allowing the code to be committed to Main/Trunk. This protects your Main/Trunk branch from contamination by code that does not work.

    8. Randomly have the manager do a "Test Please" as well. He gives a pass or fail on the job the testers did.
    9. When you receive a "Test Please Succeeded" from both testers (and never before) prepare a "Test Please" for the client. (If you are requested to issue a non-tested release to a client state "Has not passed internal testing" in the email.)

    Tester responsibilities

    1. Confirm you are a tester - If the developer did not name you, make sure he corrects himself and resends the 'test please' email.
    2. Ensure you are working on the Standard Operating Environment specific to the client and using the right browser for web apps.
    3. Use Team Viewer if you aren't available locally.
    4. Test within the hour - testing is typically urgent.
    5. Know what to test.
    6. Be thorough - anything from a crash-to-code bug to a minor UI change should be reported .(one email at a time)
    7. Classify issues accordingly to "this release" or "next release" following the report bug/enhancement standard. Any crash to code bugs must be fixed in the current release.
    8. "Reply to all" for each bug or feature. (to ensure no issue is reported twice)
    9. Specify how you replicated the bug through clear instructions and screenshots.
    10.  When finished reply to the 'test please' email with "Test Please Succeeded (as no Critical bugs)" or "Test please failed (as per critical bugs reported)".

    Subject: RE: Test Please - \\Public Folders\All Public Folders\SSWeXtremeEmailsDatabase\SSWCodeAuditor\Release09


    Test please failed

    (as per critical bugs reported in other emails)  

    Figure: This is how to reply failed to a "test please" email

    Note: If the test to be performed is quick and the tester is available on the spot, consider using a "checked by" style instead to save some time.​

  63. Do you have an Engagement Lifecycle?

    Having a documented process for managing engagements provides clients with a consistent experience. It also helps to get new employees up to speed quickly, and provides a reference to existing employees to ensure no steps are accidentally missed.

    Our engagement lifecycle overlaps with our sales pipeline, and maps to the 8 Steps to Scrum.


    Figure: Good Example - Engagement Lifecycle


    1. Initial Phone Call
      • The client has made contact but no initial meeting has yet been made
    2. Initial Meeting - Booked
      • Sales team has arranged an initial meeting and it's booked in.
      • The Initial Meeting is a non-billed meeting that maps to the Initial Meeting described in the 8 Steps to Scrum. It is attended by a Sales person and ideally a Solution Architect.
    3. Follow Up Meeting - Booked
      • In some cases, more than one initial meeting may be required before work or speccing commences.
    4. Specification Review Proposal - Waiting for Approval
      • After the Initial Meeting, if the work requires it, a specification review is proposed.
    5. Specification Review - Booked
      • The Specification Review meeting has been approved and booked in.
      • The Specification Review is a billed meeting with the customer to review existing specifications, understand specific goals, risks and relevant technologies appropriate for the solution, and create the initial backlog.
      • During the Specification Review, the Solution Architect prepares a document, presentation, or video outlining the results of the Specification Review, as per Spec - Do you effectively present the outcomes at the "Specification Review Presentation"?.
    6. Project Proposal - Waiting for Approval
      • After the Specification Review, the client is given a proposal for a chunk of work. Once this is approved, the Sales Team closes the opportunity as 'won'.
      • Proposal is sent to the client including financials and the result of the Specification Review.
    7. Project Execution
    8. Project Closure
      • Project is completed, any handover or other transition that has been defined is completed with the client.
      • Just like a Sprint Retrospective is held at the end of each Sprint, a Project Retrospective is held to learn from the project that has just completed.
  64. Quality - Do you know how to request a "test please"?

    ​These are the steps you should take when request a "test please" :
    1. Find two free testers to send the email below
    2. Stop working on the project until you receive either a "pass" or "fail" email
    3. Create your "test please" following this template: (refer to Windows Forms or Email templates below)

      Subject: Test Please - Product Name v1.11

      Dear [XXX],

      I am looking for bugs or approval to release this version.

      I have done what I could for my code's health. E.g.

      • Run SSW Code Auditor - it has [XXX] errors [If not 0, give reason]
      • Run SSW Link Auditor - it has [XXX] errors [If not 0, give reason]
      • Kept my eye on Application Insights

      Specific issues to look out for are:

      • [XXX]
      • [YYY]

      The latest version of [XXX] is at [WWW.URL.COM]

      Keep in mind that a "test please" is an urgent task and that it should start within the hour.


      Thanks, [XXX]

    4. What if you're doing a Windows Forms test?

      Then you should also include this to the email:

      • The latest version of [XXX] has been uploaded to \\frog\SSW\Download\[Application_verX-XX_beta.exe
      • Test on a fresh VPC image of Windows
      • Install into a non-default directory
      • Check the installation folder for misplaced items
      • Test Unit Tests via "Help - Run Unit Tests"
      • (If Applicable)Test the "Create" and "Reconcile" buttons. Read Rules to Better .NET Projects
      • Test open and closing forms and saving values
      • Test most buttons and menus and links
      • Disable your network connection and test again (check for unhandled errors)
      • If your test fails, please rename the executable to [Application_verX-XX_failed.exe]
    5. What if you are doing an email test?
      • DO NOT add Test Please to the subject. (it is too easy to forget later!)
      • Instead, add "Test please" with a yellow highlight to the top of the email body.

      Subject: Product Name v1.11

      Test please

      ​ ​

      Dear [XXX],

      I am looking for bugs or approval to release this version.

      I have done what I could for my code's health. E.g.

    6. Note to developer: If current version is better than the last version you can release (even with a test fail) as long:
      • The bugs reported in the test fail existed in the old version
      • Two people have tested it
      • The changes in this version are fairly important to get out
      • You get to work on the failures ASAP
    7. For clients on fixed price contracts, this email marks the start of the 30 day warranty period.
    8. Use TFS to email the work items to the project manager and client:
      Figure: TFS makes it easy to export work items
      Figure: How the email is generated

  65. Do you know the tools you need before a "Test Please"?

    Don't let your client find bugs in production that they would have found if you had asked them to do a 'Test Please' 1st
    Better still... Don't let your client find bugs that your internal tester would have found.
    Better still... Don't let your t​ester find bugs that a tool could have found?

    So, prior to a version being submitted to the client, these are the 4 steps you should follow:
    1. Perform automated testing with tools:
      - SSW Link Auditor (for Web Apps)
      - SSW Code Auditor (for all Apps)
      - SSW SQL Auditor (for all Apps with databases)
      - SSW SQL Deploy's Reconcile (for all Apps with databases) 
      - Visual Studio Team System Code Analysis (optional)
    2. Perform automated testing via Unit Tests
      - nUnit (for Windows Apps), or
      - Visual Studio Team System Unit Tests (for Web Apps)
    3. Perform an internal "Test Please" (aka "Alpha Testing" e.g. only testing that pages or forms load, not checking the business rules)
    4. Then send a "Test Please" to the client (aka "Acceptance Testing" to check the business rules)
  66. Does your Scrum Master (aka Project Manager) maintain a strict project schedule?

    It's been called 'herding cats'. Managing the project team and keeping the client well informed during the release development phase is critical. Keeping development of the release on track involves maintaining transparency on the important variables of project management: time, scope, budget and quality. This is achieved by maintaining a strict project schedule with particular activities taking place regularly like clock-work.

    Some activities are run internally; some are run with the client.

    Day Internal activity With the client


    Only with a strict project schedule can the manager coach the team to success! Figure: Only with a strict project schedule can the manager coach the team to success!
  67. Management - Do you have a "Release Update/Debrief Meeting" on a weekly basis?

    Every week the project manager should meet with the client to conduct an external "Test Please" as well as to discuss the status of the release.

    Tip #1: Choose the same day each week (for example SSW chooses Tuesday)
    Tip #2: While it is better to conduct an internal "Test Please" before the meeting (for example SSW chooses Friday), this "Release Update/Debrief Meeting" should proceed (even if it hasn't been completed).

    This is the agenda:​​

    1. Status of original work items - are they all done?
    2. External Test Please - go through the application and get the clients thoughts. Many issues they see, will already be reported by the internal "Test Please". Send emails to the new ones.
    3. Triage these additional work items - try to move all to the next release
    4. Approval for additional work items/budget overruns - talk $$
      e.g. look at the "Actual" and "Estimate" figures on the top of the report
    5. Release sign-off - "Yes" or "No"?

    If "Yes"

    1. Ask the client for a mark /10 for the release
    2. Ask the client if you can do a deployment to Production?
    3. Ask for Approval for next release  

    There are tools to help you do this:

    Figure: The actual output of the Release Update Report

    Here is a PDF format SSW Release Update Report.

    If you are at the end of a main section of work, promote your success

  68. Management - Do you know who has authority?

    ​Ok, once a project gets going, you can end up dealing with many people on the client side. From the Boss to the Business Decision Maker (we call them the "Product Owner") through to Mary the receptionist (aka "users"), everyone has something to say about the software as it is being developed. However, when you are working on a Time & Materials basis in a rapid development environment with continually changing specs, you have to be certain that the work you are doing is authorised by the person who signs the cheques.

    To: Angelo;
    Cc: John, Sophie
    Subject: Changes Requested by Sophie

    As per our conversation, Sophie has requested the following changes to your application: modifying rptContractRenewal to include the "MaidenName" field from the ClientContact Table, and positioning right next to the Surname field.

    Please let us know ASAP if you don't want this problem fixed.


    ​Figure: Sample Change Request Confirmation email
    So, say Alan from Accounts would like the Username and Password authentication to have a "remember me" checkbox for the Accounts module. This sounds reasonable, but it doesn't mean that you should charge right in and start coding.

    As an example, this is how we govern this process:

    • At the beginning of the project one of the client staff is assigned as Product Owner. This person has full authority from the Business Decision Maker of the client as to what work is IN or OUT. Every new item of work must be authorized by this Product Owner.
    • Whenever someone who ISN'T the Product Owner makes a request for work, the Product Owner must be CC'd. If Mary the receptionist has not done this, the developer sends the email again to himself, and CC's the Product Owner (CC'ing other relevant people - if they may give feedback on the task) to let them know about the request.
    • We make the assumption that the task is good to go, so it is the Product Owner's job to make sure that they reply ASAP if they don't want the problem fixed.
  69. Do you have an induction program?

    ​​​​​The problem is companies have a lot of information – some of it is public, some of it is private. 

    You need an Induction or a Continuous Learning tool. We recommend It's a great tool and ​it can test employees' knowledge; e.g. whether they can find relevant information on the intranet.​

    T​he goal of SugarLearning is to help you learn. 

    SSW induction covers a combination of public and private information. This information is available on the SSW website (public information) and the intranet (private information). We want to maintain these sites as the sources of truth for that information, so we don't want to duplicate this information on SugarLearning. 

    What SugarLearning does is aggregate your learning items into the one space to make it​ easy for you to complete your induction. Once you've done your reading, the follow-up quizzes help you confirm what you have learned.

  70. Do you identify Development, Test and Production Web Servers by colors?

    As per rule "Do you have separate development, testing, and production environment?", it's better to use different background colors to identify Development, Test and Production servers.


    crm staging.png
    Figure: Staging uses blue background
    crm production.png
    Figure: Production uses red background 

    The way to change the default background color is to edit the CRM CSS files. These changes aren't supported and may be overwritten when CRM Rollups are applied.

    CRM 2015 and CRM 2016

    Using theme feature to change the environment color.

    Figure: Changing CRM 2016 UI by using theme feature

    CRM 2013

    Edit: <CrmWebsiteRoot>\_controls\navbar\navbar.css

    background-color: #006600;
    margin: 0;
    z-index: 999;
    float: left;
    width: 100%;
    position: relative;

     Figure: Edit the background color to reflect the environment
     Figure: CRM 2013 with a green navigation bar

    CRM 2011

    Edit <CrmWebsiteRoot>\_static\css\1033\cui.css, locate and modify the section ms-cui-tabBody so that it reads:

    background-color : #ffffff;

    Change color to a suitable color for the environment:

    background-color : #bbffaa; 


    Figure: CRM Ribbon color green to signify production environment

    CRM 4

    Edit, <CrmWebsiteRoot>\_common\styles\global.css.aspx

                    <% if (CrmStyles.IsRightToLeft) { %>
                    <%} %>
                    border-top:1px solid #6893cf;
                /* background-color: #d6e8ff; */
                background-color: #ffff00;
                padding: 4px;
                /* background-repeat: repeat-x;
                background-image: url(/_imgs/app_back.gif);
    Figure: In C:\Inetpub\wwwroot\_common\styles\global.css.aspx comment out and change the reference in yellow so the users know what server they are on
    Color of CRM Development Server
    Figure: Color of CRM Development Server - Red
    Color of CRM Test Server
    Figure: Color of CRM Test Server - Yellow
    Color of CRM Test Server
    Figure: Color of CRM Production Server - Default

    SharePoint online

    Regarding the color codes, we use to differentiate Production to Test with SharePoint online.

    Here is what we change:

    • Site Settings | Change The Look
      • Test – Orange
        Figure: Selecting Orange theme for test
        Figure: orange theme applied
      • Production - Office
        Figure: Selecting Office theme for Production
        Figure: office (blue) theme applied
  71. Do you know how to record a quick and dirty 'Done Video'?

    ​When you've finished a PBI you should record a video to send to your Product Owner and anyone else that is interested. A 'Done' video is much better than a screenshot because you are proving the PBI workflow actually works. Even better, this video can double as documentation or release notes for your users.

    When deciding whether a PBI might be a good contender to record a done video for, consider these factors:

    1. Is it a key piece of functionality that has high business value?
    2. Would it be difficult to quickly demo in the Sprint Review without a video?
    3. Is it UI heavy? i.e. would the video be compelling?

    Here's a quick video describing how to record and edit a quick done video. (Notice how it itself is also in the done video format?)


    Figure: How to make a 'Done Video'

    ​​For a great 'Done Video' here are the key things to remember:
    • Don't just demonstrate your new feature, start by showing the problem you are solving and the pain of why you needed to add the feature
    • Record it in one take. It doesn't matter if you stuff up or something goes wrong, treat it like you're having a conversation with them in the room. If it's super bad, just start again.
    • It's supposed to be quick and easy to make. If you spend too much time, you will be less likely to want to do it again in the future.
    • Be quick and concise, you don't want to waste other peoples' time either!
    • In your browser, remember to hide visible bookmark bars, browser tabs, add-in icons, and taskbar items to make it easier to view.  
    • In your browser, such as Chrome then you should first zoom to 125% ideally. 
    • You want it readable on a mobile phone so record at 1920x1080 (aka 1080p). This gives the best balance of detail to size, for smaller screens.
    • Use as the screen capture software. 
    • Don't edit the video, Don't edit the video, just include your face at the beginning and end, using the fading functionality.
      Tip: If you are using Zoom you do not need to edit the video. Zoom includes your face automatically in the screen capture. Awesome!
    • Do not use headphone and mic combo sets as these are not as good as your webcam's microphone
    • Remember: smile at the beginning and end of the video!

    ​Tip: Some offices have a professional setup.
    E.g. SSW have the Marantz Turret hardware and desktop recording kit. The Turret is an ideal device to record these videos as it has a professional podcasting microphone, built-in light and good quality High Definition video camera. 

    Figure: 'Done' video in progress using a Marantz turret broadcasting kit
    Learn more about the Turret: Product Review: The Marantz Turret — Wistia

    Camtasia - Let's look at an example by Ben Cull

    E.g. SSW TimePRO - Power BI Ad-Hoc Reporting:

    Figure: A real example of a 'Done Video' with Fades

    Tip: Fix the audio before making any cuts to the video

    ​After ​recording your video, you need to do some basic sound processing to make the audio awesome.

    • In the Timeline, select the clip with the audio
    • On the top left panel, click ‘Audio Effects’ and drag the ‘Levelling’ effect onto your clip
    • On the timeline, move the new audio meter up just until the audio waveform is about to hit the top
    • Listen and adjust as necessary​
    Figure: audio effects panel with the compressor

    Tip: Camtasia 9 - How to fade-out and fade-in the video track of your face in Camtasia 9

    1. With the video track of your face selected, click on Animations (1). Track 3 in the image below.
    2. Select the No Opacity (2)  animation effect for the fade-out.
    3. Drag and drop the No Opacity effect (3) to the point in the track where you want to fade-out. Adjust the start and end point of the fade using the handles on the animation arrow.
    4. Select the Full Opacity (4) animation effect for fade-in.
    5. Drag and drop the Full Opacity effect (5)  to the point in the track where you want to fade-in. Adjust the start  and end point of the fade using the handles on the animation arrow.
    fade in and out.png
    Figure: Camtasia - Steps for adding fade-out/fade-in animation to video track of your face in 'Done' video​​​​​​

    Final Step – Export your video  ​

    Follow the steps to export your video:

    1. Click the Share button on the top right of the window
    2. In the new dialog, select custom production settings
    3. In the next window, uncheck the ‘Produce with controller’ option
    4. In the ‘Video settings’ tab, copy these settings:
      - Frame Rate: 30
      - H.264 Profile: High
      - Encoding mode: Quality
          o Increase the quality to 100%
      Figure: Copy these settings
    5. In the ‘Audio settings’ tab, make sure the Bit rate is set to 320 kbps
    6. Click Next and save your file!

    Related rule

  72. Do you know the Best Way to Learn?

    Learning a new technology is something a developer has to do at least every few years. The industry landscape is constantly changing and to keep up and the developer has to really master the art of learning.

    Over the years, SSW has trained thousands of developers and we have found that the best way to learn is through mentorship. Mentorship​ ​is when an experienced developer teaches and codes with their mentee. By working closely together on a regular basis they are able to impart their knowledge and experience into the mentee.

    Of course, there are other ways of learning and the chart below discusses the effectiveness of each.​​

  73. Do you use the brains of your company?

    ​Employees are a company's best resource, but often there is no light shone on their knowledge. A great way of making this happen is to conduct a brainstorming day. Check out this video!

    ​​Employees on the front line often have valuable insights into opportunities for improvement, what is painful, increased efficiency and even entirely new business ideas.​​ Empowering these employees with an annual brainstorming day is a great way to transform their good ideas into valuable solutions, as well as giving them the opportunity to learn and grow from each other. Also, many employees enjoy the opportunity to flex their creative muscles in fun ways that their day-to-day jobs may not always afford them.

    Different companies have different approaches to this. For example:

    • Atlassian - give employees 1 day a year to work on a feature they want
    • Google - employees are allowed to dedicate 20% of their time to 'pet projects' (subject to approval)
    • Microsoft - Scott Guthrie takes senior leadors offsite for 1 week each year
    • SSW - Adam Cogan conducts an annual brainstorming day in each state office

    How an annual brainstorming day works

    At an annual brainstorming day, employees are invited to share their ideas, give feedback, and pick the best one to work on. The benefits of brainstorming are well understood, but in order to focus the productivity on something useful, it is important to have a system for suggesting, voting, and working on ideas.

    Everyone at the company is encouraged to suggest ideas prior.

    The process is broken down into 2 key stages: preparation and participation.

    ​ Preparation​​​​​

    1. Email Attendees

    Start by sending out an email to staff, inviting them to send through their suggestions in advance.

    Hi All,

    I’m really excited about our brainstorming day! I hope you’re all thinking about what you would like to work on.

    To prepare for our Brainstorming day, send Adam and Matt W. something that you would like work on as a group.
    Eg. Our awesome SophieBot project came out of the Melbourne Brainstorming Session last year. ​

    See video on:


    Friday 29th of November 

    9:00am – Meet upstairs in Suite 15
    9:30am – Discuss items to work on & vote
    10am – Start work on your fave tech project (in groups)
    10.30am – Coffee order
    1pm – Lunch
    2pm – Continue work
    ​4pm - Presentations
    6pm – The pub

    ​Good Example: Email template for brainstorming attendees

    2. Setup Trello

    Use Trello to manage and vote on the suggestions, using the voting Power-Up. First add the voting Power-Up, then​ set up your board for the day:

    • ​Create a list called 'Retro - Highlights'
      Add a template card ('[your name] - [your highlight]')
    • ​Create a list called 'Retro - Suggestions'
      Add a template card ('[your name] - [one thing to fix]')
    • ​Create a list called 'Todo - Vote'
    • Create a list called 'Chosen'
    During the session, you will populate these lists with the input from the attendees.

    3. Pre-cooked suggestions

    ​By the time you get to the session, everyone should have emailed you through their suggestions. But it can still be intimidating for some people to be the first person to get up and share their idea with the group. To get the ball rolling, you should have some suggestions prepared in advance, preferrably provided by some of your team. Have them record a short video that 'sells' their idea, ready to show the attendees at the start of the session.​​​ -cover emailed suggestions, ask for new ones, talk about pre-cooked ones


    On the day, follow the agenda set out in your attendee email:

    • Have the Trello board showing on a projector.
    • Send all attendees invitations to the Trello board.

    • 9am: Welcome everyone and thank those that submitted ideas.
    • Call out who the scribe is. (They will update the Trello board in the background).
    • Retro: hearing everybody's top highlight. (The scribe will add these to the list).
    • Suggestions: Hear everyone's top pain (the scribe adds these too).
    • Suggestions: Once you have everyone's highights, share the pre-cooked suggestions you have prepared (hopefully a video or two).
    • Vote: invite attendees to vote via Trello for the suggestion they would most like to see implemented at your company. Depending on the size of your team, you may choose to allow each attendee 3 votes.
      Eg. "Guys, you've got 5 minutes to get your 3 votes in"
    • Vote Results: after the votes are in, you can reveal the top voted suggestions. The attendees then break into smaller groups and set to work building a prototype or proof of concept. 
      TIP: The moderator can decide which suggestions are viable and invite attendees to self-organise
    • 1pm: Give the attendees a break for lunch.
    • 4pm: Attendees come back in, and each group takes turns presenting their work to the rest of the attendees.

    NOTE: The top voted suggestion may not be technical, and the prototype or proof of concept doesn't have to be a technical solution. It coud very well be a protoype applciation or website, but equally could be a new business process or a video.

    Good​ Example: A brainstorming session is like an office party but more productive​
    ​​​​Good Example: A Trello board with the voting power-up allows people to suggest and vote on ideas they would like to work on in the brainstorming session
    ​​Good Example: The selected ideas are moved from the Vote column to the Chosen column and the real fun begins!​