Common code smells!

· Duplicated code: identical or very similar code exists in more than one location.
· Long method: a method, function, or procedure that has grown too large.
· Large class: a class that has grown too large. See God object.
· Too many parameters: a long list of parameters in a procedure or function make readability and code quality worse.
· Feature envy: a class that uses methods of another class excessively.
· Inappropriate intimacy: a class that has dependencies on implementation details of another class.
· Refused bequest: a class that overrides a method of a base class in such a way that the contract of the base class is not honored by the derived class. See Liskov substitution principle.
· Lazy class / Freeloader: a class that does too little.
· Contrived complexity: forced usage of overly complicated design patterns where simpler design would suffice.
· Excessively long identifiers: in particular, the use of naming conventions to provide disambiguation that should be implicit in the software architecture.
· Excessively short identifiers: the name of a variable should reflect its function unless the function is obvious.
· Excessive use of literals: these should be coded as named constants, to improve readability and to avoid programming errors. Additionally, literals can and should be externalized into resource files/scripts where possible, to facilitate localization of software if it is intended to be deployed in different regions.
· Ubercallback: a callback that is trying to do everything
· Complex conditionals: branches that check lots of unrelated conditions and edge cases that don't seem to capture the meaning of a block of code.

How is Kanban different from Scrum?

Both Kanban and Scrum focus on releasing software early and often. Both require highly-collaborative and self-managed teams. There are, however, differences between the approaches:

Kanban		Scrum
No prescribed roles		Pre-defined roles of Scrum master, Product owner and team member
Continuous Delivery		Timeboxed sprints
Work is ‘pulled’ through the system (single piece flow)		Work is ‘pulled’ through the system in batches (the sprint backlog)
Changes can be made at any time		No changes allowed mid-sprint
Cycle time		Velocity
More appropriate in operational environments with a high degree of variability in priority		More appropriate in situations where work can be prioritized in batches that can be left alone

Organization, culture and team dynamics often determine which method is the best fit.

Coding Standards as per Microsoft

Dan Rigsby says it all for me....
Coding standards are usually not well liked and can be met with some resistance.  However, when they are properly defined and enforced they can yield a number of benefits:
1)     Standards can help reduce the cost of development.  Since code is easier to maintain and read, less time needs to be spent on these activities thereby decreasing the cost.

2)     Standards can also help make code more homogeneous.  Developers usually dislike working with code written by others because of the various coding tendencies or the lack of any standards.  Homogenization helps reduce the difficulty of working with code developed.  Some developers who work with code from another developer will often spend time refactoring and reworking the code so that it fits to his/her own personal tastes.  Some code may be reworked over and over again by different developers wanting to make the code feel more familiar to them.  Having standards helps avoid this.

3)     Standards can also help reduce the number of bugs and the bugs that do exist are easier to find in fix.  While the code will not be bug-free, it will help elevate a lot of issues.

The debate is not whether or not standards are useful.  It’s more about how they should be implemented, what standards should be in place, and how closely they must be followed. The purpose of this document is to layout the standards that should be used, however these are only suggestions.  Modifications will be made to this document to keep up with developer input as well as new technologies.

The view I take on IT...

Choose one of the following:
1). GOOD service CHEAP, won't be FAST.
2). GOOD service FAST, won't be CHEAP.
3). FAST serivce CHEAP, won't be GOOD.

So after all that: CHEAP is DEAR and DEAR is CHEAP