⚠️ This page has been archived

✅ New page with updated info: ssw.com.au

Home > decommissioned > [DECOMMISSIONED] SSW Sydney Consulting - Why we exist

[DECOMMISSIONED]

There was an error displaying the testimonials. Please report this error to SSW and include the following text:
- A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

 

1. Why we exist
2. Technical Goals
3. Education
4. Dealing with Customers
5. What to expect from our developers
6. Obligations to other members

  1. Why We exist

    2. People often ask our staff 'why do you work for SSW rather than doing consulting work as an individual?' Certainly each of us should be good enough to make $1000/day w more as an individual consultant. The reason we have banded together so that we can take on the larger and more technical jobs that require more resources and skills! As dedicated developers who love coding, this is a mroe satisfactory arrangement. Also, as a group we are able to provide better support, and add-ons like hosting if needed.

    Software is complicated today and the best solutions come out of teams (the once common scenario of a single developer working with Access has gone...) We work in pairs according to the eXtreme Programming Methodology , which we believe has contributed a large amount to our success. This pair programming means that developers can cover for each other in cases where one may be on leave and support is needed. Customers need to feel that they won't be left on their own if something goes wrong, and that's one of SSW's strong points. We share knowledge, we support each other with complementary expertise and we don't have much tolerance for downtime or failure.

     

  2. Technical Goals

    3. We conform to our own strictly enforced development and coding standards that are commonly accepted 'best practices'. This ensures that we An SSW built application should be:

    • Easy to navigate (see our drop down menu)
    • Fast - i.e. responsive to users
    • Clean
      • Don't bombard users with options they don't need to know about
      • Use wizards when doing complex tasks that you don't do every day
    • Useful (Concentrate on content rather than graphics).  Sexiness doesn't bring business value - although the user must have a positive experience - eg Google doesn't have flash intro screen...
    • Customizable.

     

  3. Education

    4. As well as all being Microsoft Certified Professionals, here at SSW we are happy to educate others people. We are often asked why we publish our standards on our site for the world to copy and use. The reason is that we learn from others peoples responses, and we increase our technical expertise by exposing ourselves and inviting criticism. We:

    • Educate people by building great sites
    • Run the Sydney .NET User Group
    • Regularly deliver custom desigend programming training
    • Run SSW Tech Breakfasts
    • Make the Demo Materials for SSW Products available on the Web for free so that other people can use them to teach face-to-face classes or learn on their own
    • Provide code in our Knowledge Base
    • Maintain KB/CodeBase

     

  4. Dealing with customers

    5. It is our belief that the first principle of good business is that you do not lie to customers. If a service goes down because of something we did wrong and should have known not to do, we tell the customer exactly what we did wrong in as clear language as possible. Even if the customer might not know that this was a stupid thing to do under Unix or Oracle, we explicitly tell them "this was a stupid thing to do." If we slacked off and partied all weekend and didn't finish some work that we promised, we admit it rather than conjuring up mythical technical dragons to slay. We do not take advantage of customer ignorance to hide our mistakes, a practice that is depressingly widespread in our industry.

    • Don't overwhelm customer with technical jargon - explain status to the customer in real terms - "constant communication doesn't solve problems"
    • involve the customer in all steps
    • Never be vague in requirements or contracts
    • "To-do" lists need to be specific - never say "we will fix all these bugs..." *********need a list....**********
    • Always be clear about billable work

     

  5. What to expect from developers

    6. The goal of each each member of SSW is eventually expected to become an internationally famous Web developer capable of managing an entire project from start to finish. That doesn't mean that each person needs to acquire all the skills necessary for a site, but he or she has to understand what skills are necessary and where to get them within SSW.

     

  6. Obligations to other members

    7. We live or die by customer satisfaction. It is safe to assume that the customers' priorities are (1) getting down services back up, and (2) getting new services developed on time.