Manager manage the system, not the people

Here is the article.

Manager should create a system which:

1. People can do their job efficient.
2. People can get and give feedback.
3. People can grow.

How to get property value using spring

Today I read a useful posting regarding using property file.

Article

Agile vs Lean

The 4 principles of Lean Development are:

-Add Nothing But Value (Eliminate Waste)
-Center On The People Who Add Value
-Flow Value From Demand
-Optimize Across Organizations

The Agile Manifesto says:

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

waterfall vs rup vs scrum vs lean

Recently I got a very interesting blog regarding difference between above project methods.

Here’s a VERY simple overview of the main differences between Waterfall Development, Iterative Waterfall Development, Scrum/Agile Development and Lean.

Waterfall Development

‘Waterfall Development’ is another name for the more traditional approach to software development.

It’s called ‘waterfall’ as this type of development is often planned using a Gantt chart – you complete one phase (e.g. planning) before moving on to the next phase (e.g. development).

In Waterfall approaches, you will rarely aim to re-visit a ‘phase’ once it’s completed. As such, you better get whatever you’re doing right the first time!

This approach is highly risky, often more costly and generally less efficient than more Agile approaches.

The main issues with this approach include:

• You don’t realise any value until the end of the project (when you deploy) (See: Self-Funding Projects, a Benefit of Agile Software Development)
• You leave the testing until the end, which means you’re leaving issue discovery until late in the day
• You don’t seek approval from the stakeholders until late in the day – their requirements might have changed
• You’re heavily reliant upon a plan, which you can/will often follow to the detriment of the end result
• You’re heavily reliant upon a project manager driving the way – the power of one

Iterative Waterfall Development

This approach carries less risk than a traditional Waterfall approach but is still far more risky and less efficient than a more Agile approaches.

The focus is on delivering a sprint of work as opposed to a series of valuable/shippable features.

The most commonly occurring issue in this type of scenario (in my experience) is bottle necking.

For example, you deliver loads of code a little bit behind schedule (?) and you leave it until the last minute to test everything. One issue takes longer than expected to resolve, you miss your sprint deadline and you deliver nothing.

Another common symptom of this type of approach is over-commitment. It’s really difficult to estimate the total effort associated with a particular User Story/Feature when approaching delivery in this phased way.

You’re more or less forced to estimate each phase separately (e.g. estimate development separately to testing in this instance) – this doesn’t work as the phases are not separate, they’re totally intertwined.

For example, if you find an issue with the test, you must return to development. The whole team must remain focused on delivering the end goal, not the separate phases.

It’s also worth noting that velocity and burn downs are far less (if at all) useful in this type of environment – you don’t benefit from early-warning-signs as you don’t find out whether you’re on track until the end of the sprint.

Scrum Development

This approach carries far less risk than Waterfall approaches.

We focus on delivering fully-tested, independent, valuable, small features. As such, we diversify our risk – if one feature goes wrong, it should not impact another feature.

With that said, we still plan our work in iterations and we will still release at the end of each iteration.

Lean Development

Lean is very similar to Scrum in the sense that we focus on features as opposed to groups of features – however Lean takes this one step further again.

In Lean Development, you select, plan develop, test and deploy one feature (in its simplest form) before you select, plan, develop, test and deploy the next feature. By doing this, you further isolate risk to a feature-level.

In these environments, you aim to eliminate ‘waste’ wherever possible – you therefore do nothing until you know it’s necessary or relevant.

Why software is expensive

I just read a post from http://itscommonsensestupid.blogspot.com/2009/10/why-software-is-expensive.html, it is very interesting, below it is the points.

1. Software is expensive because there are huge overhead costs associated with software development. Computer equipments are expensive. And the fact that software developers need to stay on the cutting edge of the technology means that they need to always upgrade their hardware. Also, software methodologies and tools change very often, software developers need to invest a lot of time and money to just to keep up with the development so that they can provide better service to their clients next time.
   For those of you who think that hardware cost is "just of small fraction of the total cost", let me tell you that hardware is not cheap in third world countries; a mere acer laptop is costing as much as a programmer's one month salary here in Malaysia.
2. Software is expensive because there are a lot of research going into it. Some express puzzle at software developer apparent "low productivity" (20 lines of code per day). Assuming that you are charging USD 50 per hour, your rate is USD 20/line. This is awfully expensive to the business owners who measure productivity in terms of quantity produced. What they miss out is that programming productivity is all about writing less code to get your job done. A programmer could spend one billable month reinventing the wheel and produce a 10 million line-of-code ORM that is buggy, or spend one non-billable month to look for an open source implementation that is mature and well-developed, and endure the complain of low productivity. The way business owners complain about "research time" is encouraging the wrong type of behavior.
3. Software is expensive because the product owners don't know what they want. Imagine if you go to an architect, asking him to provide a blue print, and after he comes out with that you ask him to change it according to your latest taste-- even though it is contrary to the original specification, and you repeat this process,.. No one would dare to do this, but everyone seems to have no problem asking the software developers to change their code at last minute and expect everything to work just fine and the product ships in time and worse of all, is not willing to pay extra.
4. Software is expensive because it is customized only for you. The reason why Microsoft Office and Windows Vista is so cheap, is because the development cost is spread over million of users. The consequence of this is that there is no competitive advantage associated with the ordinary office or Windows Vista users. Your customized application, on the other hand, is designed especially for you, and you-- and no one else-- can enjoy the returns and benefits bring forth by the application.