Manifesto to agile software development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

http://agilemanifesto.org/

About DTOs

The use of DTOs in conjunction with BOs (Business Entities or Domain Entities) is one of those topics that can trigger an endless, and sort of pointless, discussion within a team.

The theory suggests that DTOs are used in all cases to reduce coupling between layers and to lend the system greater formal neatness.

The practice, though, often reminds us that complexity is generally high enough that we should avoid any unnecessary additions.

As a practical rule, we suggest that when you deal with a model of a few hundred business objects, you probably don't want to double the number of classes just to be neater in your implementation. In this case, a DTO might likely be the same as a BO.

From Microsoft .NET: Architecting Applications for the Enterprise

Design Guidelines for Developing Class Libraries

http://msdn.microsoft.com/en-us/library/ms229042.aspx

Examples of Antipatterns

An anti-pattern is devious and insidious and adds more trouble than it removes. In the old days, we used to just call these bad ideas. The new name is much more diplomatic.

The Architecture-As-Requirements anti-pattern refers to situations where a prominent and influential member of the design team has a pet technology or product and absolutely wants to use it in the project—even when there is no clear evidence of its usefulness and applicability in the customer's context.

The Test-By-Release anti-pattern refers to releasing a software product without paying much attention to all those boring and time-consuming chores related to unit and integration testing. Are users the final recipients of the product? Great, let's give them the last word on whether the software works or not.

Know the business well to be in the business

Many years ago, when talking about choosing what to do when growing up, my father said to me “Find something you like to do, be good at it and figure out a way to make some money out of it.” With that advice I chosen software development as my career path and went with it for decades.

Come to think about it one needs to know the business (well) to be in the business. It is true to an architect, it  is true to a programmer. It is also true to a project manager. extend it to a larger Scale, it is also true to a company.

 

Is starting over a solution?

Even with the best intentions of everyone involved and regardless of their efforts, the design of a system at some point can head down a slippery slope. The deterioration of a good design is generally a slow process that occurs over a relatively long period of time. It happens by continually studding your classes with hacks and workarounds, making a large share of the code harder and harder to maintain and evolve. At a certain point, you find yourself in serious trouble.

Managers (and/or architects) might be tempted to call for a complete redesign (reboot), but redesigning an evolving system is like trying to catch a runaway chicken. You need to be in a very good shape to do it. But is the team really in shape at that point?  Have you ever seen the movie Rocky? Do you remember the scene where Rocky, the boxer, finally catches the chicken, thus providing evidence that he's ready for the match? During the movie, Rocky attempts several times to get the chicken, but he gets the chicken only when he has trained well enough.

From Microsoft .NET: Architecting Applications for the Enterprise

Object-Oriented Design Principles

Find Pertinent Objects First

Favor Low Coupling- Program to an interface, not an implementation

Favor Code Reuse

The Open/Closed Principle : A module should be open for extension but closed for modification

Dependency Inversion Principle : inversion of control (IoC). Dependency injection

Design principles

A principle that is helpful to achieving high cohesion and low coupling is separation of concerns (SoC).

KISS: Keep It Simple, Stupid (Keep it as simple as possible, but no simpler)

DRY: Don't Repeat Yourself

OAOO: Once and Only Once

YAGNI: You Aren't Going to Need It

Every line of code you write can and will be used against you in a code review session.

Cyclomatic Complexity myth in software development

From time to time, I heard people saying something like “Our system is very complex, so it is understandable that the cyclomatic complexity of our system is high”. That is a myth; no matter how complex the business process is, as long as we design and program it right, we still can maintain the cyclomatic complexity < 25 for all members of all classes in the system. The real question is how good or how committed we are as a programmer or a software manufacture.

SQL Programming Guidelines

http://peterlusql.blogspot.com/

Make them happy

Happy hens produce more and better eggs.

Happy cows produce more and better milk.

Happy programmers produce more and better code.

Start a trip with a punched tire and start a software development project without maintainability in mind

The common characteristic of them is you  can get somewhere, but not too far; sometime you may never reach your destination.

Maintainability

A code base that can be easily searched for bugs, and in which fixing bugs is not problematic for anyone, is open to any sort of improvements at any time, including extensibility and scalability. Thus, maintainability is the quality characteristic you should give the highest priority when you design a system.

From “Microsoft .NET: Architecting Applications for the Enterprise”

Who Architect is

One school thinks that architects live on the upper floor, maybe in an attic. Architects then step down to the developers' floor just for the time it takes them to illustrate, using UML diagrams, what they have thought about the system. After this, they take the elevator up, collect their things, and go out to play golf. When on the course, they switch off their cell phones and focus on the game. When done, if they missed a call or two, they call back and explain to dummy developers what was so clear in the diagram that nobody on the developers' floor could understand. According to this school of thought, architects never, ever dirty their hands with even the simplest C# statement. C#? Oh no, the latest language they've been exposed to is probably Pascal while in college and Borland Turbo Pascal at home.

Another school of thought thinks, instead, that every architect is a born developer. To take the metaphor one step further, we could say that the class Architect inherits from the class Developer and adds some new methods (skills) while overriding (specializing) a few others. Becoming an architect is the natural evolution in the career of some developers. The basic differences between an architect and a developer are experience and education. You gain experience by spending time on the job; you earn your education from studying good books and taking the right classes. In addition, an architect has the ability to focus her vision of the system from a higher level than an average developer. Furthermore, an architect has good customer-handling skills.

An architect might not write much production code. But she writes a lot of code; she practices with code every day; she knows about programming languages, coding techniques, libraries, products, tools, Community Technology Previews (CTPs); and she uses the latest version of Visual Studio or Team Foundation Server. In certain areas of programming, an architect knows even more than many developers. An architect might be able to write tools and utilities to help developers be more productive. And, more often than you might think at first, the architect is just a member of the development team. For example, an architect writing production code is an absolutely normal occurrence in an agile context. It is also a normal occurrence in small companies regardless of the methodology. At the same time, an architect who writes production code might be an absolutely weird occurrence in some large-company scenarios, especially if a traditional and non-agile methodology is used.

We just have been denied access to the first school of thought.... As we see things, an architect is, among other things, a better and more experienced developer. We don't believe there's value in having architects who just speak in UML and Visio and leave any implementation details to developers. At least, we've never found it easy to work with these people when we've crossed paths with them.

From “Microsoft .NET: Architecting Applications for the Enterprise”

An Architect's Responsibilities

Acknowledging the requirements

Breaking down the system

Identifying and evaluating technologies

Formulating specifications

From “Microsoft .NET: Architecting Applications for the Enterprise”

Movie making and software development

It takes a good script writer, a good producer, a good director and a few good key actors with a common goal to make a good movie. The partnership between the producer and the director is the most important factor to the success.

It takes some good business analysts to come out with good requirement, a good architect to come out with good architectural design, a few lead developers , a good project manager and a good QA team with a common goal to make a good software product.

The partnership between the architect and the project manager is the most important factor of the success"

Role mapping

Script writer : business analysts
producer: project manager
actors:  developers

Good programmers write code that humans can understand

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

—Martin Fowler

Everything is there for reasons

In technology world, everything is there for reasons. Whether it a button on a remote control, or it is a language feature in a specific programming language, or functionality in a database engine.

Because these are man-made features, these features need to be justifiable to be included by the manufactures in the first place.

From consumer point of view, instead of a matter of “do we or do we not to use it”, rather a matter “when, where and how to use it”.  Simply say no to them as a guideline, we are excluding ourselves from be benefitted from utilizing these features. Sometime, by doing so, we make our live more complicated otherwise could be simpler.

This is true to “static method” or Exception handling in .Net; This is also true to “Trigger” in SQL/Server.  Use them right, it will make your live much easier.

Simplicity is the ultimate sophistication, especially true for 4GL like SQL

Many years ago, when I apply for a lead developer position in IT department of a regional bank, I was given a stored procedure printed on 5 pages of letter size paper with font size of 8.

I start to read it, very soon I became confused, I could not figure out what the stored procedure was doing and could not associate its code to its name…. then I asked “Is this kind of stored procedure common in your system? How this kind of stored procedure be maintained”. The answer I got was “You go it! that’s the point. The stored procedure should not be that complicated.  It should do one thing and one thing only and the name should indicate so clearly. Here you are a good one.” With that, the interviewers handled me a simplified version of the same stored procedure that is a half-page only.

I still remember the name of the manager at the interview was Sarah (could not remember her last name), and the database developer lead was Brian Mincey. (You can find him at my facebook friend).

Ask ourselves, do we write stored procedures 500 lines in size and do lots of stuff that are not reflected in its name?  Think about this,  you are not the only one who needs to work on this stored procerure. there are many others need to. and there would be many others need to work on it in years to come. ( if the system you are working on makes its way to production).  My manager at HP has this line in his email signture "Simplicity is the ultimate sophistication". I think it carrries lots of wisdom. Our life is complicated enough, make it simple when you can.

What we have learned from .com bubbles in 90s

For those in IT industry for more than a decade, I am sure they miss the good old days in early 90s, especially if you were working in Silicon valley during that period of time.

Well, starting late 90s to early 2000’s, it is considered as “.com bubble busting period”.  Lucky enough for me, I was working in Silicon valley from November 99 to November 2000.  Every Saturday morning, if you pick up the classified ads in the newspaper, you will be able to pick up lots of bargains from computer servers to office furniture. Many start-ups were closing down after burning off all cash they can find.

Recently, I came across an article which brought up an interesting aspect on why so many companies gone under during that period of time.   It said that it was caused by decisions (management decision, technical decisions or otherwise) made by those software companies got themselves in trouble.   It continues with its theory by saying the following:

Many newly formed companies start up with some wonderful ideas. In order to realize these wonderful ideas they reached out to VC market. In order to convince the VCs to open their wallets, they need to present the idea in most realistic fashion. Under the financial pressure, the company made decisions to rush into software product development. They short cut product architecture quality, programming quality, they short cut human resource qualification. All they care about is in a shortest possible period of time with lowest possible cost they have something to show or something that allow them to push to the market, even if there are significant flaws in the system. Among programmers, it is commonly referred as “junk code is all over the place”.

Under this approach, the maintainability, extendibility and reliability of the product are greatly compromised. So much so that it affects the sustainability of the business to continue to carry the software product they have produced. 
 

What have we learned from the history of .com bubbles as an industry? How much do we care about the non-functional quality of the software product or software system?  As software development manager, application architect, how much time we spend to get some real sense on what kind of program code been put into the system?  Some simple questions could be asked “when was the last time you open up the code in the same IDE your developers are using and try to read the code or build the code?”, “How much time you spend with the programmers to understand their code and to help them in writing better code?”, “Are we capable or willing to do so?”

If we failed to learn from the history, the history would repeat in our lives. Sustainability is at the line. I am sure those in leadership position with the wisdom will prevail.  

Bernard Madoff

Another  “Bernard Madoff” case ? are you sure?
what do you mean? am I sure it is or it is not?

 

It was orginally posted on face book on April 19th 2012.

To be a valuable individual

Anybody in any organization works in collaboration with others. One should ask himself or herself these questions:

What is my value to the one I am working for?

What is my value to the ones working for me?

What is my value to the ones working with me?

You want to be a valuable individual to all of them.

Leadership and judgment

For these at leadership position, they may not need to be able to come out with some kind of brilliant ideas. What they need is to be able to understand and choose one proposal from a few presented to him or her. This is what we call “judgment”.

For these at leadership position, they may not need to be very knowledgeable in the area they are leading, what they need is to be able to identify those who are. This is what we call “judgment”

we are running out of time

A few friends decided to take a trip to New York City during the weekend.

Since there are a few of them, they thought to take one car to drive there is more economic than taking a flight.

They plan to hit the road 8:00 in the morning and planned a Broadway show at 8:00PM with the thinking that 12 hours should be enough to reach NYC.

Well, they did hit the road 8:00AM, and after  10 hours driving, they found they have lost. One suggested that “let’s stop somewhere and figure out where we are and get the drive direction established and we continue.” Said another voice “No, no, we cannot stop, we are running out of time, we got to be hurry.”

What would you say if you were in the car?