159 posts
From the land of GOLD and FREEDOM and HERITAGE and CULTURE! No one in the west actually thought of the east when we were running into the industrial 20th century. But by the end of the century and the begining of 21st century everyone got startled and things changed and they changed for good. An new word was re-invented for the resource-and-cost-saving-hungry information technology world - OUTSOURCING.
What's the ideal path to outsource? The best way to go is outsource those efforts that are clearly defined and not abstract. Outsourcing is all about following a more formal approach to software development.
How much do you agree with the statement "Learning takes place in a realm of experience, not from a flip chart"?
So Posterous got acquired, and now it seems that they have better things to do at Twitter. So it's dead. It's kinda sad, but that's the order I guess with startups getting acquired. It's about talent, and less about technology and way less about the product conceived which got them there in the first place.
For a successful project manager, there lies a dire need of project specific leadership. And it holds true in all sort of projects, be it small, mid-sized or large. In my recent experience, I tried different hats, being a worker, a leader, a management person, and focused mainly on working with the team, listening to the team, and thinking through them. It helped me getting a good rapport with my team; but in scenarios where the upper management doesn’t feel that this is the way the PM should work then it’s not worth the effort. Hence, in order to make a stand in front of ones those who have more power than the PM and are also seated in the higher chairs it would be worthwhile first to win the consensus across the board.
I'm getting a bit lazy in posting. Ah! too much work!
As a publisher it is important to understand the lay of the land and worry about the distribution, sales, the work effort that goes into building a crafty book, the hard work in followups, contracts, etc. etc. Traditionally, these were and have been and will continue to be the focus items for any publisher, and to add to their woes, the digital content and the digital distribution is here to stay.
My personal favorite:
There is a great deal of progress in the past two decades in Software Development Management, in terms of improving software quality, development productivity and overall development process. The progress over the last two decades specified what to do with the programs like Sourcecode Configuration Management (ClearCase, CVS, etc.) and Defect Tracking System. On the other hand, the techniques learned are impossible to put into a program.
The biggest problem faced by business today is not learning but forgetting. And as Tom Peter quotes "Forgetting is the key activity...the primary activity...these days." Forget it!
Agile coaches must be involved in the client's Agile process. Those who have the impression that coaching can be done from the sidelines are mistaken, for coaches must get their hands dirty if they want to bring about successful Agile adoption. To better explain why Agile coaches cannot be observers, I will provide details about the possible mayhem within the Agile landscape, some twisted thoughts about coaching, and the high-level transition plans that Agile coaches should set in motion for their clients.
Steve Jobs will be missed forever, in today's digital world, and tomorrow's whatever world comes into being - dominated by a brilliant company "Apple" that he built, succeeded and dedicated his life to. May his soul rest in peace, and god bless.
[RFID: Is it soup yet? | Newsmakers | CNET News.com](http://news.com.com/RFID Is it soup yet/2008-1013_3-5205486.html?tag=ac.hed) "Working with the results--and many of the same people from MIT's [Auto-ID Center](/MIT winds down radio tag activity/2100-1008_3-5095957.html?tag=nl "MIT winds down radio tag activity -- Thursday, Oct 23, 2003")--EPCglobal is now pushing to create RFID standards using existing communications network infrastructure and the electronic product code, a system for assigning unique identification numbers to items."
In light of building a contemporary digital experience and social engagement, the rise of the Chatbots is quite an advent when combined with the latest tools & technologies. We have clearly seen a growth in digital concierge services from Apple (Siri), Google (GoogleNow), and Amazon (Echo) in past coupled of years if not more - the use of common language and communication with digital devices is increasingly becoming a standard. As Dion Hinchcliffe explicitly references, IRC Bots, Eliza, & Zork - the latter, command line programs from 80's, and the former Internet Relay Chat (IRC) that used to perform automated functions to control the IRC Channels back in the day when I was in high school working on dial-ups.
One of the biggest misconceptions about Agile is that architecture is not required in the Agile development. ‘We‘re Agile; we don’t need architecture’–is something that everybody involved in Agile has heard at least once. Let’s start by establishing a common understanding of what the software architecture is, to which everyone can agree. The definition of architecture is quite broad, and the roles and responsibilities of software architects vary dramatically from company to company. Here is how Martin Fowler identifies architecture in Patterns of Enterprise Application Architecture: "Architecture" is a term that lots of people try to define, with little agreement. There are two common elements: one is the highest-level breakdown of a system into its parts; the other–decisions that are hard to change.” I find that we all can agree on those two common elements. Do we need the highest-level system break down? Absolutely. Do we need huge documents and long design stages? No. Agile is not against the architecture–it’s against useless, bulky documentation that nobody reads anyway. From the perspective of change, the role of architecture in Agile development becomes quite clear - A good architecture is responsive and will support agility; a poor architecture will resist it and reduce it. And, since one of the benefits of adopting Agile is a better response to changes in the requirements, it’s obvious that flexible and extendable architecture is a key to this. The biggest issue that I’ve noticed is the very thin line between architectural design and software design. I’ve seen companies where the different implementations of the following practice were used: Architects created design documentation and developers were responsible for writing the code. This introduced a myriad of problems, starting with developers feeling that they were not fully trusted. This also gave developers an excuse not to really think about the design. ‘We’re just coders, not responsible for the design and we do only what we are told to do.’ is a common attitude that I have witnessed. In Agile, the developer is responsible for the code he writes (and unit tests) as well as the design since nobody else will provide him with it. Ideally, the high-level software architecture is completed before coding starts. And I really have to be careful here - completed doesn’t mean written in stone; it can change, but with an understanding “this is the best of what we know right now.” This doesn’t necessarily include a database design or class diagram, and the level of details really depends on the approach you will be taking moving forward. I found that for certain systems the Domain Drive Design (DDD) is extremely useful and has made my life far easier. Therefore, I like to have a domain model and a basic set of domain classes and their relations defined, but not to the level of methods and attributes. Personally, I prefer projects to have a design stage; this is when the high-level business domain model and user stories are created. At this stage the main architectural decisions are made – the technology that will be used, the database server, the application type (for example, Mobile, rich client, or service), the architecture style (client server, layered architecture, SOA) is selected, and the architectural frame that will be applied is selected as well. The document created during this phase is not solely architectural effort, it is a collaborative effort of business analysts, developers, and network administrators. The output of this design stage is not only a high-level architectural document. (This is not an attempt to make fixed predictions of the future or create a detailed software design upfront as this approach places all the significant decisions at the point of least knowledge in a project's lifecycle). This is simply a way of getting and sharing the common understanding of the system we are all about to develop. This is an excerpt from the forthcoming book, The Art of Being Agile. [Image Courtesy: Flickr/Helix/Philip Gunkel]
I've been keeping myself busy (hence, no posts in past three weeks) with RoR development on a small project which I've taken along with my three person team. Its been fun so far; and working with Ruby on Rails (RoR) is an added bonus. The rapid development approach of RoR really drives the agility through the project. It reminds me of words like agile, rapid, RAD, scrum, etc. Its fantastic. But there is a learning curve especially when you aren't so familiar with the underlying scripting language such as 'Ruby'.
I think some of the challenges which any enterprise company faces today are typical release cycles (program compliance), integration and regression testing (audit compliance), trace logs for transactions (SOX compliance), authentication integration (SOX/Federal/Compliance), data security (compliance), etc. A SaaS based application sounds nice and all from a ease-of-mind-perspective (and especially for small and medium size businesses) but has its own nightmares and bottlenecks. Its rightly pointed out in the write-up from Prof. James Morris about the development cycle for a communuty based/involved software development. But to an enterprise, especially large ones, its almost an impossible sell on SaaS.