15 Useful Project Management Tools

There is a huge variety of project management applications out there. Most are general purpose apps, not aimed at any one industry. But there is a growing number of project management apps aimed specifically at one industry or another. Applications geared to creative types are becoming more readily available, and some of the offerings are really quite good.

Many of these project management apps have built-in code repositories and subversion browsers (or are built around them). A few have built-in bug and issue tracking. Others include more than just basic project management. All of them can help you keep track of activities and team members. There are both free and paid options. Some have very slick interfaces, and some are modeled more after desktop applications. All are relatively easy to use and easy to set up.

Below are 15 useful project management applications, almost all of which are targeted directly at Web developers, designers (both Web and print) and other creative types. The last one is not geared specifically to creative types but is the most unique project management application I’ve found and is included on that basis as well as because of its potential usefulness for designers and developers.

Read the article here

(Source: Cameron Chapman from smashingmagazine.com)

45+ Very Functional Javascript Sliders and Scrollers

Every web developer needs to use Javascript in creating web applications, and when it comes to displaying multiple items on a page with a focus on a single item Sliders and Scrollers comes in handy. You can use Javascript Sliders and Scrollers with news, images or products to display data in an organized and user friendly way. In this article there is a list of 46 Very Functional Javascript Sliders and Scrollers for you to use in developing web applications.


Check out the Sliders and Scrollers here

(Source: Ahmad Hania from 1stwebdesigner.com)

Nuggets from the book - The Checklist Manifesto

I have listening to the audio-book - The Checklist Manifesto: How to Get Things Right  by Atul Gawande. I definitely recommend the book, as it is a fascinating read.


In the book Gawande says “The checklist gets the dumb stuff out of the way, the routines your brain shouldn’t have to occupy itself with, and lets it rise above to focus on the hard stuff…” 

In other words, a checklist can help you

• work smarter
• get all necessary tasks completed, 
• avoid overlooking the little things that can unravel an entire project, and 
• ensure that you’ve got key information available, 
• remind you to communicate with all key stakeholders. 

The Checklist Manifesto looks at the use of checklists in surgery, construction, investment banking, and aviation. Gawande provides some very compelling arguments for using checklists from the simple to the most complex of situations.


DEVELOPING A CHECKLIST 

• Decide whether the situation calls for a DO-CONFIRM checklist or a READ-DO checklist 
• Outline all the steps in a process that need to be followed 
• Review situations that went wrong, identify overlooked steps and ensure those are included on the checklist 
• Ensure the right people are reviewing and approving the checklist components 
• Include a publication date on the checklist, as it will be revised often 
• Add “pause points” at which you or the team must pause and run through a set of checks before moving onto your next steps 
• Especially pertains to a DO-CONFIRM checklist type, where one distinct group of critical steps have to be completed before another set of tasks should be undertaken 
• Include a ‘communication’ check to ensure that at necessary points in a process key stakeholders are communicating about the project status, next steps, and so forth 
• Keep checklists simple, to one page, and with an easy to read font type 
• As needed, get leadership onboard with embracing and promoting the use of checklists 
• Test the checklist in actual, real-life situations 
• Refine and test the checklist until it succeeds at consistently improving the process and outcomes for which it is being applied 
• Schedule a regular checklist review schedule 
• Determine if using the checklist in one business unit or team will require other process changes to be implemented elsewhere in the company (and make a checklist for them!)

Golden Nuggest from the book - PeopleWare (By Tom DeMarco and Timothy Lister)

Summed up in one sentence, Peopleware: Productive Projects and Teams (Second Edition)
say: Give smart people physical space, intellectual responsibility and strategic direction


DeMarco and Lister advocate: 

• private offices and windows. 
• creating teams with aligned goals and limited non-team work. 
• managers finding good staff and putting their fate in the hands of those staff
• The manager's function is not to make people work but to make it possible for people to work
• managers should help programmers, designers, writers and other brainworkers to reach a state that psychologists call "flow" - an almost meditative condition where people can achieve important leaps towards solving complex problems

The best way to describe this book would be as an Anti-Dilbert Manifesto

DeMarco and Lister attack cubicles, dress codes, telephones, hiring policies, and company core hours and demonstrate how managers who are not insecure about their positions, who shelter their employees from corporate politics, who, in short, make it possible for people to work are the ones who complete projects and whose employees have fun doing so.

Programming languages come and go with an occasional paradigm shift thrown in. However, the thought processes and the mental gyrations needed to complete large software projects remain largely unchanged

Top Ten Idea Killers in Software Development

Software engineers start out as being curious, enthusiastic and gung-ho about getting things done. Somewhere along the way, they butt heads against a world that doesn't understand software development: systems that count engineers by numbers, productivity by lines of code and quality by process; a world where software development is a "risk-management" bureaucracy rather than a creative endeavor that can solve customer problems.

Unfortunately, many engineers consider this a wake-up call to shed their energy and adopt those bureaucratic ways, convinced that they have stepped into a new, adult world of "management". Some who manage to resist that misstep become disillusioned and don the garbs of martyrdom, ascribing every failure to something that management did or did not do.   

If you are a software engineer, or an engineering manager, here's a list to help you identify if you still retain your software development genes or have morphed into someone that brings out a worn out list of cliches to robotically throw into every meeting, killing every idea and the morale behind it:

10. "This is good enough" : The fact is that nothing is ever good enough, least of all software. It may be good enough for today, or this release, but if your product has had the same problem for the last decade ¹, some other company has already taken your customer away because of this feature. Fix it before you reach the point where you cannot.²

9. "This is how it was always done": This is an anachronism in any competitive, rapidly changing field but particularly in software. Software companies are not like automobile companies that can set an assembly line in place and forget about it for a hundred years. Oh, wait-a-minute! Even automobile companies cannot do that anymore! Today's problems require a new set of solutions because in an industry fantastically bound to Moore's Law, machines, along with people's expectations from them, set a terrific pace of change.

8. "There isn't enough time to do it right": This is how you get into Technical Debt; some of it may be inevitable due to business pressures or working with a new piece of hardware or technology. As long as you repay this debt in the immediate future, this is part of the process; but if this is how you avoid making the right decision and the responsibility that goes with it, you are not being true to your engineering origins.

7. "This requires core architectural changes": What doesn't? Ideally, a well-designed piece of software should be flexible and amenable to changes as the product develops. But as we've said, demands on software change rapidly and every piece of software written will need to be rewritten. This is the nature of the work, not an anomaly to be used as an excuse!

6. "Management has not prioritized it": I always want to ask: what exactly hasn't management prioritized -- making a good product? writing error-free code? reducing bugs in the field? making the customer happy? Agreed that sometimes we inherit legacy code and there is juggling to be done between fixing what exists versus writing new code but this is a specious argument as we will see below. Suffice it to say that engineering needs to set and execute its own priorities, however small, every day, instead of waiting for some giant, magical mandate from above, because that's never going to happen.

5. "There is already a lot on our plate": This is one of those nonsense tautologies that add nothing to the discussion. The focus is no longer the idea or how it should be executed but some longstanding grouse about 'having no resources' or some customer's bug list. Of course you have a lot on your plate! You are being paid to have that stuff on your plate -- start chowing down!

If an idea is worth executing, its adoption should not depend on whether you have a lot on your plate; if you fill your plate at the buffet with junk and decide you can't have a desired dish because your plate is full, you have done two things wrong: you chose the wrong things to begin with and then haven't done the simple math that you have to throw the junk off your plate to get what you want. You don't kill the idea, you clean your plate.

4. "Our software is very complex; we have to be careful about making changes": Check another nonsense tautology off the list. What enterprise software isn't complex? Are you saying you are usually not careful when writing code? You are a software engineer -- you are expected to deal with complexity and be careful about making changes -- that's a basic requirement. If this is a reason we as engineers cannot execute an idea, we need to go back to relearn the basics.

3. "No one is asking for it": This reminds me of Henry Ford's wry comment "If I’d asked people what they wanted, they would have said 'a faster horse'." Human beings are incredibly adaptable -- they will live with anything, including, as Ford observed, horse manure. If you give your customers a substandard product, they will live with it. But remember that humans are incredibly fickle, too; an idea you kill will only bloom in another company's garden. Being sloppy just because our software is "sticky" -- short for "the customer hates us but can't change because it's too much work" -- is setting the bar at a level that's not worthy of a true engineer.

2. "We have to have consensus": This is at number two for a reason -- it's a seemingly innocuous statement with noble intent that is insidious and on closer inspection, meaningless in the software context. Consensus is given undue importance in everything from design meetings, SRS/SDS³ reviews, documentation, QA practices etc. Software development is an expertise-driven exercise. Someone has spent years studying, learning and working in a specific field, and to not defer to that person for the final decision is to waste all that expertise, not to mention deliver a bad product, demoralize the expert, adopt the safest and most timid way and most insidious of all, diffuse accountability.

A group decision is a way to duck responsibility for the outcome. "We all decided together" is a way of saying "No one is responsible". We have a presidential system instead of a parliamentary system for a reason: the congress advises the president but the president makes the decision. Unless the decision is so obviously horrendous that 2/3rds of congress decides to override the decision, the president's decision stands. This is the only way the buck can stop at the president's desk.

And the #1 idea killer in software development is

1. "It can't be done": There is nothing that cannot be done in software. Non-engineers kid around with "It's only software, right?" as a way to gently provoke engineers but it's true! It is indeed only software. Engineers should respond with specifics of what it takes to implement rather than say something cannot be done. A statement like "It will take 15 engineers, with individual licenses for software xyz, with 30 Model ABC machines, each with 2 TB of storage with at least 250GB in SSD storage and 5 QA personnel for a period of 1 year to deliver this software" instead of "it can't be done."

Everything can be done; let's get into that mindset first. The rest will fall into place.

Footnotes

1. Anyone who has worked on enterprise software can give you a long list of "known bugs" that have been around for more than a decade

2. Sometimes you cannot because too much code has grown around the defect and changing it is just too darn difficult at this point; or because the software died under the burden of too many such defects; or you no longer have a job because the company folded. It happens.

3. Software Requirements Specification/Software Design Specification

Source: Navneeth Mandavilli @ computer.org

Navneeth Mandavilli is a senior technologist and innovator with experience ranging from hands-on development to the management of multi-national engineering teams building enterprise applications and system software. His most recent focus has been on helping others build development organizations that can successfully innovate, creating incubation teams that select projects based more on the promise of technology than proof. His approach has resulted in ground-breaking solutions, valuable acquisitions, and interesting failures.

Navneeth believes a successful career is rooted in two words: Know Thyself. He hopes that sharing his thoughts on what he learned about himself as he succeeded, and failed, in his career is helpful to the readers of this blog. He currently works in the Office of the CTO for EMC Corporation and is based in Santa Clara, California.

Follow Navneeth on Twitter @nmandavilli.

Viral Marketing Via Social Media

Found a good article around Viral Marketing...

Read the article - Viral Marketing Via Social Media

SOA'izing MSMQ with WCF

Microsoft Message Queuing’s (MSMQ) integration with the Windows Communication Foundation (WCF) is extremely powerful. It enables MSMQ developers to write fault-tolerant, service-oriented applications and provides a robust extensibility model developers can use to improve any system’s capabilities – including MSMQ’s. In this video and corresponding sample we'll convert a System.Messaging application into a WCF Queuing application, enable that application to overcome MSMQ’s 4mb message size limitation with a prototype chunking channel, and integrate it seamlessly with existing MSMQ applications.

More here...

BizTalk 2010 Recipes : Importing Schemas

To import an existing XML schema into another schema...

You can use the XSD Import method within the BizTalk Editor to reuse an existing common XML object structure within another, as opposed to manually creating an entire schema. As an example, assume you have two simple XML structures, Customer and Address:

<Customer>
  <FirstName> </FirstName>
  <LastName> </LastName>
  <MiddleInit> </MiddleInit>
  <Age></Age>
</Customer>

<Address>
  <AddrLine1> </AddrLine1>
  <AddrLine2> </AddrLine2>
  <AddrLine3> </AddrLine3>
  <Zip> </Zip>
  <State> </State>
  <Country> </Country>
</Address>

To use the XSD Import method to allow this scenario within BizTalk, follow these steps:

1. Open the project that contains the existing schema (in this case, the Customer schema).
2. Double-click the Customer schema to open it.
3. Right-click the root node of the Customer schema, and select Properties.
4. In the Properties window, click the ellipsis next to Imports to open the Imports dialog box, which is shown in Figure 1. 
5. Select XSD Import as the import type, and click the Add button.
6. In the BizTalk Type Picker dialog box, select the Schemas tree node, and select the Address schema.

Figure 1. Imports dialog box

NOTE

In this example, the Address schema is within the current BizTalk project. If the schema existed outside the BizTalk project, the schema could be imported by selecting the Reference tree node.

The preceding procedure imports the Address schema into the Customer schema. To use the Address schema, follow these steps:

1. Click the Customer node in the Customer schema.
2. Right-click and select Insert Child Record.
3. Click the newly created child record.
4. In the Properties window, click the Data Structure Type drop-down list, and select the Address reference.

The Customer schema is now referencing and using the Address schema via the Imports schema method within the BizTalk tool set.

3. How It Works

Within the BizTalk tool set, there are a variety of ways in which you can construct XML schemas. The choices revolve around common architecture principles such as reuse, development best practices for schema organization, and fundamental development preferences.

This example illustrated using the Imports method for referencing schema. The Imports dialog box offers three choices for achieving the schema reference activity (step 5 of the recipe):

Include: This method physically includes a schema definition within another. The common usage would be to create a static reference of a schema during the schema build process. This choice could be used to leverage previously defined XSD schema (for example, publicly available schema). The include schema must be the same target namespace of the schema you are including. Alternatively, the target namespace of the include schema can be blank.

Import: The most commonly used import method within BizTalk, the Import option includes XSD Imports statements within the source schema definition. By using this option, namespaces and XSD object structures within the target schema are available for use within the source schema in read-only fashion. The practical application for this choice revolves around common reuse, such as reuse of an existing schema artifact or use of a publicly available XML schema.

Redefine: The least-common import method within BizTalk, the Redefine option, like the Import option, allows namespaces and XSD object references to be used within the source definition. However, the Redefine option allows objects and data structures to be overridden within the source definition. Common uses could be to create an inheritance model or to reuse and customize an existing XSD structure.

This example demonstrated referencing other schemas within the BizTalk tool set. However, while BizTalk provides and implements standard XSD instructions to achieve this functionality, common architecture usage and choices should not be ignored to ensure the correct schema reference method is selected.

Tips for WCF Tools

Here are some tips for using WCF Tools in VS2008 SP1

http://blogs.msdn.com/b/wcftoolsteamblog/archive/2008/08/28/tips-for-wcf-tools-in-vs2008-sp1.aspx

Best Web Hosting Sites - iPage vs BlueHost

iPage

---

Bluehost

49 Ideas For Awesome Lenses

Are you ready to make a lens or two?

How about 5 or 10 or 100?! It's pretty easy, non-techy, and of course, free. Right? Right. Sure, to make your lens a real knockout it takes some time, but the point of this lens is to share some ideas for getting started, not for being perfect. This is just a short list of different lenses worth making. Just to get you thinking. There are a gaggle of other ideas you should absolutely make lenses about.

P.S. If this isn't enough to get you going, try stopping by The Squidoodlr: A lens idea generator.

http://www.squidoo.com/lensbrainstorm

Video - BizTalk Server, SOA and the Shift to the Cloud

In the session Richard Seroter discusses the continued relevance of SOA and how to apply SOA principles when designing and exposing services from BizTalk Server. (View session 2)

Richard Seroter is a solutions architect for an industry-leading biotechnology company, a Microsoft MVP for BizTalk Server, and a Microsoft Connected Technology Advisor. He has spent the majority of his career consulting with customers as they planned and implemented their enterprise software solutions. Richard worked first for two global IT consulting firms, which gave him exposure to a diverse range of industries, technologies, and business challenges. Richard then joined Microsoft as a SOA/BPM technology specialist where his sole objective was to educate and collaborate with customers as they considered, designed, and architected BizTalk solutions. One of those customers liked him enough to bring him onboard full time as an architect after they committed to using BizTalk Server as their enterprise service bus. Once the BizTalk environment was successfully established, Richard transitioned into a solutions architect role where he now helps identify enterprise best practices and applies good architectural principles to a wide set of IT initiatives. Richard maintains a semi-popular blog of his exploits, pitfalls, and musings with BizTalk Server, SOA and enterprise architecture at http://seroter.wordpress.com/.

Presented by Richard Seroter.

Length: 52 minutes 01 seconds

Videos: WMV (Zip) | WMV | iPod | MP4 | 3GP | Zune | PSP

Audio: AAC | WMA | MP2 | MP3 | MP4

Exposing BizTalk Applications on the Cloud using AppFabric Connect for Services

With the advent of the cloud and enterprises building cloud-based applications, enterprises will still want to use their existing on-premise applications. Thus, one of the key requirements in building hybrid cloud-based applications across on-premise and on-cloud environments is the ability to use pre-existing on-premise applications. The BizTalk Server 2010 AppFabric Connect for Services feature now allows BizTalk users to expose their on-premise BizTalk Applications as WCF Services on the cloud, by adding Windows Azure AppFabric Service Bus endpoints. These Service Bus endpoints can subsequently be consumed by clients residing outside the enterprise’s organizational firewall.

Before we go deeper into details of exposing BizTalk Applications to the cloud, let us clarify how cloud related technologies have impacted application and service deployment. We can divide the application and service deployment scenarios into two broad categories:

• On-premises deployment: An application or service that runs within an organization’s firewall and is typically accessed by clients that are within the firewall.
• On-cloud deployment: An application or service that runs within an organizational firewall and can be accessed by clients inside or outside the firewall through a Service Bus endpoint exposed in the cloud. The services still run locally in IIS. Only the endpoints are exposed in the cloud.

Windows Azure AppFabric Service Bus provides the capability to take on-premise web services and extend their reach to external clients. Windows Azure AppFabric Service Bus supports this on-cloud scenario with a relay service that can listen to external clients on behalf of the on-premise web service at a given public address and relay messages between both parties.

Windows Azure AppFabric Service Bus provides the platform where developers expose the Service Bus endpoints for their on-premises services. AppFabric Connect for Services enhances the capabilities of theBizTalk WCF Service Publishing Wizard to enable developers to expose on-premise BizTalk application operations to external clients as WCF services via the Windows Azure AppFabric Service Bus relay service.

What does the BizTalk WCF Service Publishing Wizard do?

The BizTalk WCF Service Publishing Wizard essentially exposes the operations in BizTalk Applications as WCF services. AppFabric Connect for Services enhances the wizard to support the relay service provided by Azure AppFabric Service Bus. The wizard enables you to select the operations that you want to expose as services and then creates the following:

• A local endpoint for the WCF service.
• A Service Bus endpoint for the WCF service.
• A Service Bus endpoint for metadata exchange with the WCF service (if configured).
• Receive ports in the BizTalk Application, which are used to bind to the desired operations.

Security Considerations when Exposing Services on Cloud

Security becomes a paramount concern when organizations expose mission critical data and operations to services outside an organization’s protected environment. To address these concerns, organizations can follow certain security best-practices to ensure that only authenticated clients get access to the service.

• Client authentication by the Service Bus Relay Service. All the Service Bus relay bindings expose a binding property, ‘RelayClientAuthenticationType’, that controls whether the client consuming the service is required to present an authentication token to the relay service. This property can be set to either ‘None’ or ‘RelayAccessToken’. If the property is set to ‘RelayAccessToken’, the client must provide an authentication token to the Service Bus. The authentication token must be communicated separately to the client, for example, as an e-mail message by the organization hosting the service. In addition to implementing security, setting ‘RelayClientAuthenticationType’ is also a cost-effective solution for the organization hosting the service. If there is no authentication from the Service Bus, any client would be able to hit the service endpoint even if it is eventually denied by the service. As a result, the organization would incur a chargeback even though there was no business operation that resulted.
• Message-level and transport-level security. WCF inherently provides message-level and transport-level security for services. For more information on message- and transport-level security, seehttp://msdn.microsoft.com/en-us/library/ms733137.aspx.

Tip: It’s not essentially a security setting, but organizations can also secure the services which are exposed on the cloud by not making the endpoints publicly discoverable. Service Bus provides an ATOM feed which lists all the publicly discoverable endpoints under a given Service Namespace. Making the endpoints discoverable is controlled through the “DiscoveryMode” attribute of an endpoint's behavior in the "ServiceRegistrySetting". This can be set using the BizTalk WCF Adapter Publishing wizard. The disadvantage of not making the endpoints publicly discoverable is that if you have a large number of clients that would be using the service you hosted, you will have to communicate the endpoint URL to each of those clients.

Who Should Read This Whitepaper?

This whitepaper assumes some familiarity with Microsoft BizTalk Server, Windows Azure AppFabric Service Bus, Windows Azure AppFabric Access Control Service (ACS), and Windows Communication Foundation (WCF). This whitepaper is intended for the following users:

• Organizations that want to extend the reach of their on-premises BizTalk applications to the cloud by exposing them as WCF Services with endpoints in Windows Azure AppFabric Service Bus.
• Users that want to consume the web service that is extended to the cloud, to perform operations implemented in BizTalk Application that are deployed inside an organization’s firewall.

Read the rest of the post @ technet.microsoft.com...

Important Tips for New Programmers / software developers

Here's a small list of tips for new programmers.

1. Read new books on software

   Browse the local bookstore's software section. See what's new. Don't just read the latest Cookbooks on how to use technology, but peruse theory books.

2. Watch Important Blogs

   Blogs like Eric Gunnerson's for C#, Martin Fowler's and the TheServerSide for general info. Visit software web sites likepragmaticprogrammer.

3. Be an active member in a local user/professional organization.

   Join the local Java User's Group and .Net groups. You'll meet new and interesting, sometimes scary, people.

4. Keep a daily record of major events during the day in a file.

   Things like the phone numbers of people you talk with, significant bug fixes, code snippets, URLs, email addresses. It is important to keep it in a file and not just on paper, so that it can searched, transferred and backed up easily.

5. Keep a library of interesting code that you've written and things you've learned.

   The best way is to just publish this on the web somewhere. That way you can always locate it and your knowledge can help others.

6. Remember - It's all about people

   It's easy to forget during the crush of time pressures of a particular project that your relationship with your coworkers is the single most important long term issue. Don't ruin relationships just to get a single project done. Those same people are critical to the success of your next project. Besides, those people give you recommendations and job offers after your current company folds.

7. As you code, think of maintenance.

   Try to downgrade the skills needed to maintain your system. For example, to change a parameter use an init file instead of a java class, so someone with only text editing skills can update your program.

8. When you finally track down that hard to find bug, don't fix it immediately.

   Write a unit test that exposes the error. Change your code so that the error message is more descriptive. Then related bugs will be easier to find and fix. For example, if your servlet fails and the only indication is the " page cannot be displayed" message on a browser, change it so that it writes a page to the browser explaining the error, "Cannot find the file 'Config/Messages-en-US.txt'". Test your error message page, and then fix the original bug.

9. Don't try to make your code modules reusable for some future mythical system.

   To make a module reusable takes three times as long as for single use. The odds of you, or your friends, reusing the module is really low. Don't waster your employers money doing something that may never be used. If you find a use for that module later on, then make it reusable if it makes sense.

10. Don't spend time optimizing before all is working:

    "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." - Donald Knuth

11. Realize methodologies are just guidelines.

    Don't follow methodologies blindly. Just because Object Oriented Programming is a great methodology, it doesn't imply you should always follow it. In rare cases speed or memory constraints force a good programmer to go against OOP.

    The same with Domain Driven Design. It is not appropriate for very small applications.

    "More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity." - W.A. Wulf

12. Constantly improve your skill level.

    Always be learning. Talk to other software people about their problems and solutions. Be alert, the next software revolution often happens with very little warning.

13. Testing

    I like this quote from a Rational brochure: "Continuous, automated testing that covers the entire development life cycle. It's the only way to manage the constant flow of changes, errors and general chaos."

    Invest in a high level of automated testing. I like JUnit for Java and NUnit for .Net. If possible, write your tests so that the input is an XML description of objects. This way your testers can write your tests, instead of programmers.

14. Post-Installation Test for Enterprise Software

    In the administration portion of your application have an "installation test" section where all the major components get exercised. Have a link to test that the databases are connected, any web services, and that key configuration items have values. Installation is such a pain and you can relieve some of that with good tests and explanations when something is not quite cricket.

15. OHIO/DRY

    Remember what Ray Ozzie calls the OHIO principle (Only Handle Information Once.) "If information must be entered in two places, it won't be."
    (AKA 'DRY' Principle: Don't Repeat Yourself).

16. Push Complexity Down

    You should push complexity down to lower objects and not clutter the higher objects with details.

17. Push Complexity To Smaller Objects

    If all things are equal, put new complexity in the smaller objects.

18. Command Query Separation (CQS)

    Bertrand Meyer presented it as:

    "every method should either be a command that performs an action, or a query that returns data to the caller, but not both. In other words, asking a question should not change the answer" -Wikipedia
19. Your biggest enemy professionally is your pride

    Don't be afraid to say "Hmmm. David, I've never heard about that before; what is it?", or "Hey Frank, could you look over this code and see if there's a better way to do this.". Don't assume you know the best way to design or code something. We can all learn from each other in this voyage called life. Don't fear constructive criticism. "Faithful are the wounds of a friend."

20. Coding Tidbits
    1. Write your methods to be testable.

       Instead of having a method like,

         public string DBCalculation(int ID) {  int k = databasemethod1(ID); int i = databasemethod2(ID);  if(k > 2) k = k/2; if(i < 10) i = i+20; if(i + k > 20) { i = 1; k = 20; }  return Math.Atan(double(k),double(i*2);  } 

       which would really be hard to test with dozens of values of k and i, because you have to feed the database input values. Instead, break up the code into more modules that can be driven with data.

         public string DBCalculation(int ID) { int k = databasemethod1(ID); int i = databasemethod2(ID);  return Calculation(k,i); }  public string Calculation(int k, int i) { if(k > 2) k = k/2; if(i < 10) i = i+20; if(i + k > 20) { i = 1; k = 20; } return Math.Atan(double(k),double(i*2); } 

       
       

       the method "Calculation" can be tested easily with xUnit (and would hopefully reveal the flaw in this method).

    2. Methods that take an object

       If a method takes an object for its argument, it may mean that method really belongs on that object.

         int numberOfTires = HelperClass.CountTires(Car car); 

       "CountTires()" would really be much happier in the Car object.

         int numberOfTires = car.CountTires(); 

    3. 'Declarative Testing' - Use XML data files to feed xUnit tests.

       For the above example, instead of doing the following in code

         Assertion.AssertEquals(12, Calculation(3,4)); Assertion.AssertEquals(0, Calculation(6,1)); Assertion.AssertEquals(4, Calculation(2,12)); 

       Use Declarative Testing by employing XML files which are more flexible and can be written by testers.

       <Tests> <Calculation i='3' k='4' result='12' /> <Calculation i='6' k='1' result='0' /> <Calculation i='2' k='12' result='4' /> Tests> 

    4. Always check for errors

       Don't assume you know all values that will ever possibly come into your routine. Handle the cases you expect and always throw an exception for anything else

       public bool Walk() {  switch(val) {   case '&': return left.Walk() && right.Walk();   case '|': return left.Walk() || right.Walk();   case 't': return true;   case 'f': return false;   default:    throw new Exception("KQParserCore.Walk() encountered  a val that was not '|', '&', 't', or 't'.  It was '"+val+"'");  } } 

    5. In boolean conditions for C and C++, put the constants on the left side

       if( 0 == currentRecordNumber ) 

       That way if the second '=' is forgotten, the compiler will tell you.

       if( 0 = currentRecordNumber ) 

    6. Don't name a major class the same as a SQL keyword like "Group" or "Order". It can bite you later.
    7. With the exception of 0 and 1, don't use integers in your code - use constants.

       //bad   int[] accounts = new int[5];    const int NUMBER_OF_ACCOUNT_TYPES = 5; int[] accounts = new int[NUMBER_OF_ACCOUNT_TYPES]; 

    8. Don't ever repeat key/index strings - use constants.

       //using "lastname" as a key opens possible spelling errors later. //what if someone accidently capitalizes "lastname" or puts a space in it? //you will get a silent error. Hashtable hashtable = new Hashtable(); hashtable.Add("lastname", "smith"); string name = (string)hashtable["lastname"]; Console.Out.WriteLine(name);  //better to always use string constants - typos will be caught by the compiler //and you get a handy reference list of all your keys/indexes used const string LAST_NAME = "Lastname"; hashtable.Add(LAST_NAME, "jones"); name = (string)hashtable[LAST_NAME]; Console.Out.WriteLine(name); 

21. My Favorite Quotes about Programming
    1. "The only proof of working software is working software." - James McGovern
    2. "Everything knows nothing about anything." - a perfectly object-oriented system.
    3. "Every line of code is a liability." - Taka Muraoka
    4. "Software has the shelf life of bannanas." - Scott McNealy
    5. "It might be that the key to Ant's success is that it didn't try to be successful. It was a simple solution to an obvious problem that many people were having." -James Duncan Davidson, the creator of Ant .

       At our local Java Users Group James said if he had done a full requirements analysis and tried to build the perfect tool for everyone's need, he probably would have failed. Instead he just built a little tool for himself and gradually added features that his friends really wanted right then.

    6. "It has been said that the great scientific disciplines are examples of giants standing on the shoulders of other giants. It has also been said that the software industry is an example of midgets standing on the toes of other midgets." -Alan Cooper, About Face
    7. "Measuring programming progress by lines of code is like measuring aircraft building progress by weight." -Bill Gates
    8. "The most amazing achievement of the computer software industry is its continuing cancellation of the steady and staggering gains made by the computer hardware industry." - Henry Petroski
    9. "If I had asked people what they wanted, they would have said faster horses." vaguely attributed to Henry Ford
    10. "There is nothing so useless as doing efficiently that which should not be done at all." - Peter Drucker