Tuesday, January 19, 2010

Refactoring for sale


Among the technical list given by Mikael Boman in his post dedicated to product owners, "Practice #4: Refactoring" is for sure, the most difficult to agree with. Version control system, Continuous integration, Automated testing are concepts around tools, consequently their deployment has a visual, understandable, palpable result, so there is no worry justifying their costs.

If you don't get the Practice #6: Collective code ownership, wait for a few years until developers leave your company and then you will get it.

Simple design:
While the indicated article focuses on product owners, the simple design concept is obvious to many of us, but developers could feel it as a bridling of their creativity. While we all need to establish a software knowledge culture, where ideas around code design and patterns are understood, we face a dilemma when it comes to asking for simple creation. I didn't find a good way to recommend, but practices like pair programming and code review can mitigate the ugly and the glittery code. A developer conversation while looking at the code, will free the product from the lack of conception or avoid the all "design patterns" in one "software product" idea.

Refactoring:
Previous to entering into the agile/lean world, I didn't find a proper solution to justify a moment to improve the code. Then, based on Lean concepts, I felt desperate because spending time on refreshing the code could be understood like a waste. But the only reality resides in understanding the technical debt and the product complexity.
Some people will argue the refactoring must be embedded in the development tasks and will state that concerned developers will perform this activity by themselves. But such behaviour could hide the iceberg from the product owner or give him a great argument to play the ostrich.
Refactoring must be understood, and the product owner must commit to spring cleaning the code.
If some tasks related to code refactoring are present in the product backlog, it means:
  • Developers have an understanding of the code, so the concerned component is not something anybody would touch anymore due to its ugliness, but only a huge number of code lines that smell bad.
  • Product owner has stepped back, understood the complexity of the component and admitted the technical debt must be lightened,
  • The regression linked with the refactoring will be mitigated by guardrails, like unit tests or user scenario rechecks by testers. Because the testers will have to valid the refactoring tasks, they would have discussed the impact and the use cases affected by this work with the developers. They will not discover the regression nightmare later after a refactoring decided by the developer on his own.
Sources:
Pragmaticmarketing: Six technical practices you should know about
Scrumalliance: The top six technical practices every Product Owner must know about
Wikipedia: Code refactoring
Wikipedia: Design pattern
Martinfowle: MF Bliki: refactoring
Theagileexecutive: Technical Debt: Refactoring vis-a-vis Starting Afresh « The Agile Executive
Infoq: Refactoring is a Necessary Waste
Agileinaflash : Agile: In A Flash

Wednesday, January 6, 2010

Enterprise social software


Last century, I used to send to my colleagues a constant flow of emails with links I considered relevant to our work. Experience has shown me that pushing information to people doesn't mean they assimilate the essence of the content. Worse, if you send too many messages they will get ignored and after filling up your colleagues' mailboxes, they will tend to automatically bin them. Pushing information is definitively a waste of time for both the sender and the receivers.

While the enterprise's knowledge is supported by the enterprise content management, the availability of web tools has led many organisations toward Enterprise social software.

A blog for a project, for a service or for the general news, are surprisingly adopted without an effort of persuasion, where the traditional content management tools have failed. Easy to use, and effective with a small amount of writing are the main characteristics of this technology.

A wiki is a group of web pages that people can edit just by clicking on a button. Current wikis have a WYSIWYG interface that most users are comfortable with, a good improvement from the first wiki.

But wikis are the best for collaboration. Watch the following picture directly copied from the wikinomics blog and you see which waste has been eliminated.



















Wiki adoption in the Enterprise is something different from the uptake of blogs. If you want to succeed in deployment of wikis, you will need to step back, get the good people and avoid classic mistakes and that's what you'll find on the wikipatterns website.

Sources:
Wikipedia: Enterprise social software -
Wikipedia : Knowledge management
Wikipedia: Enterprise content management
Wikipedia : Wiki
C2.com : Wiki History
Wikipatterns.com : Wikipatterns - Wiki Patterns

Sunday, January 3, 2010

Happy new year 2010




Happy new year 2010 and don't forget to watch the apple product line strategy video here below. A good resource to prepare your product strategy.



Thanks to David Ha for this summary.

Sources :
Wikipedia : Apple Inc. - Wikipedia, the free encyclopedia