Who Owns the Source Code?

A client had developed an app and asked us to do some minor work on their existing app. I told him that we would need access to the source code so the client went back to the original developer to get the source code only to find that the developer claimed the source code as his intellectual property and refused to provide it. Unfortunately, this is not the first time I’ve seen this source code ownership issue. Here are some of the implications of not having the source code to your app:

• You are forever tied to the developer. Any modification, bug fix, or upgrade has to go through that developer. This is problematic because the developer could raise the price of development and is problematic if that developer becomes sick, busy with other projects, etc.
• Raising funds or selling your project becomes more difficult because there’s a question of who owns the intellectual property.

Common Law

(Disclaimer: I’m not a lawyer; if this is a concern, please get good legal counsel). In general, the author of content owns the copyright. In the case of a software developer, it’s the person physically typing on the key board to create the code. An exception occurs under the “Work for Hire” doctrine where the work is developed by an employee with the scope of their employment. However, when contractors are used, this becomes a little more unclear.

Personal Opinion

If I hire someone to buy a house, at the end of the project, I want the keys to it. In a similar fashion, if I pay someone to develop an app for me, I would expect to have the source code upon completion. At Apptology, this is our general policy. The exception is when we develop an app based off one of our templates. In which case, the template is our intellectual property.

Recommendations

If you are having an app developed by a contractor, have an open discussion about the source code ownership as part of the vetting process. If you don’t agree with their source code policy, move on. If you decide to go with that developer, make sure the ownership of the source code is spelled out in the contract.

[Source]

How much does it cost to make an app?

“How much does it cost to make an app?” As a developer, this is the most common question I am asked. This is like asking “How much does it cost to build a house?” Following the house analogy, are you looking for a mansion or a shack? Do you want a house made of straw, sticks, or brick? Do you want a custom home or a tract home? Just like a house, the variables in developing an app are endless.

Develop a Storyboard

The first place to start is defining what you want your app to do. I normally recommend our clients storyboard their app (the technical term is wireframe). The wireframe is like the blue print in the house analogy. The goal for developing a wireframe (or storyboard) is to capture functionality and flow. This is not the time to worry about the actual aesthetics yet. It’s important to start from the beginning though, when a user first launches your app. Think about what’s the first thing they will see? On the home screen, if they tap the first menu selection, what happens next? And so on.

To create our wireframes, our designers use a design tool called Balsamiq. I send our clients a PowerPoint template where they can either use PowerPoint’s drawing tools or they can even print it out and hand draw it.

Other Factors

Beyond the storyboard, other factors that will impact the development and cost are:

• Integration to an existing backend / Development of backend: Most of the apps we develop now either need to talk to an existing backend or we have to create a backend to support the app.
• Integration to third party vendors: A lot of features that typically used to be expensive to develop can now affordably be added by leveraging third party vendors. Examples are push notifications and mobile commerce.

In addition to the wireframe, if you’re app requires extensive integrations to third party vendors, you may need to put together an architectural diagram.

Getting a Quote

For the most part, a developer should be able to provide you a quote to develop your app based on your wireframe (and architectural diagram). You can find reputable U.S. based developers at iphoneappquotes.com and theymakeapps.com.

You can also find freelancers and offshore teams at elance.com, guru.com, odesk.com; Just beware. I’ve talked to clients that have used developers from these sites and it’s a mixed bag. I’ve talked to a few people that have had good experiences and I’ve heard of some horror stories.

If you feel like your app concept is the next Uber, it’s okay to ask the developer for an NDA (Non-Disclosure Agreement) or to ask them to sign your NDA. When you go through this process, you’ll find a vast range for the quotes. My recommendation is to look at other when selecting a developer.

(Shameless plug – we also would, of course, be happy to provide a quote for your project. Just visit us at Apptology.com)

Alternatives

App development, like most technology has become commoditized to some extent. If you have little budget for app development, you may consider DIY (Do It Yourself) App services like ibuildapp.com or seattlecloud.com. There is also a middle ground where a developer can create a robust but cost effective solution based on templates. Apptology offers a cost effective app development solution using templates (called ReadyBuilt). Mobile Roadie is another developer that uses template. Apps based on templates are primarily used to promote a business or to provide content and are typically a fraction of the cost of developing apps from scratch.

Final Thoughts

My answer to the question, “How much does it cost to develop an app?” is “It depends.” If you are thinking about developing an app, I highly recommend taking a little time to create a storyboard or wireframe. This step will help you flush out your concept and greatly assist a developer in providing a solid quote for your app.

[Source]

Principles behind the Agile Manifesto

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need,
   and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Manifesto for Agile Software Development

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.

10 Tips for Efficient Android Apps Development

The best recipe for becoming a complete flop in Google Play is to release an app that is battery and memory hungry with a slow interface. Most likely, these qualities will ensure negative reviews from users and result in a bad reputation, even if your app has great design and a unique idea.

Every drawback in product efficiency, battery and memory consumption can really affect your app’s success. That’s why it is critical to develop well-optimized, smooth running apps that never make Android system guard against them. We will not speak about efficient coding, since it goes without saying that the code you write should stand any performance test. But even brilliant code takes time to run. In today’s post, we’ll talk about how to minimize this time and make Android apps that users love.

Efficient threading

---

Tip 1: How to off-load operations onto threads in background

Since by default all operations in an app run on the main thread (UI thread) in the foreground, the app responsiveness might be affected, which will imminently result in hangs, freezes and even system errors.

To reinforce responsiveness, you should shift long-running tasks (e.g. network or database operations, complex calculations) from an app's main thread to a separate background thread. The most effective way to accomplish this task is at a class level. You can use AsyncTask class or IntentService class to organize background work. Once you have implemented an IntentService, it starts when needed and handles requests (Intents) using a worker thread.

When using IntentService, you should consider the following limitations:

• This class does not put results to UI, so to show results to users use Activity.
• Only one request is processed at a time.
• Any request processing can not be interrupted.

Tip 2: How to avoid ANR and stay responsive

The same approach of off-loading long-running operations from the UI thread will save your users from the "Application Not Responding" (ANR) dialog. What you need to do is to create a background worker thread by extending AsyncTask and implementing doInBackground() method. Another option is to create a Thread or HandlerThread class of your own. Keep in mind that unless you specify "background" priority for the thread, it will slow down the app since the default thread priority is the same as of the UI thread.

Tip 3: How to initiate queries on separate threads

Displaying data is not immediate, although you can fasten it by using CursorLoader objects, which allows not to distract Activity from interacting with a user while query is processing in the background. Armed with this object your app would initiate a separate background thread for each ContentProvider query and return results to Activity from which the query was called only when the query is finished.

Tip 4: What else you can do

• Use StrictMode to detect potentially lengthy operations you do in the UI thread.
• Use special tools, i.g. Systrace, Traceview, to find bottlenecks in your app responsiveness.
• Show progress to users with a progress bar.
• Display splash screens if initial setup is time-consuming.

Device battery life optimization

---

We cannot blame users for angrily uninstalling applications that abuse battery life. The main threats to battery life are:

• Regular wake-ups for updates
• Data transfer via EDGE and 3G
• Textual data parsing, regex without JIT

Tip 5: How to optimize networking issues

• Make your app skip operations if there is no connection; update only if 3G or WiFi is connected and there is no roaming.
• Choose compact data format, e.g. binary formats that combine text and binary data into one request.
• Use efficient parser; consider choosing stream parsers over tree parsers.
• For faster UX lessen round-trip times to server.
• When possible use framework GZIP libs for text data to make the best use of CPU resources.

Tip 6: How to optimize apps working in foreground

• When designing wakelocks, set the lowest level possible.
• To avoid battery costs caused by potential bugs you might have missed, use specific timeouts.
• Enable android:keepScreenOn.
• In addition to GC (garbage collection) consider recycling Java objects manually, e.g.:
• XmlPullParserFactory and BitmapFactory
• Matcher.reset(newString) for regex
• StringBuilder.setLength(0)
• Mind synchronization issues, although it can be safe when driven by UI thread.
• Recycling strategies are used heavily in ListView.
• Use coarse network location not GPS when possible. Just compare 1mAh for GPS (25 sec. * 140mA) and 0.1mAh for network (2 seconds * 180mA).
• Make sure to unregister as GPS location updates can continue even after onPause(). When all applications unregister, users can enable GPS in Settings without blowing the battery budget.
• Since the calculation of a floating point requires lots of battery power, you might consider using microdegrees for bulk geo math and caching values when performing DPI tasks with DisplayMetrics.

Tip 7: How to optimize apps working in background

• Since each process requires 2MB and might be restarted when foreground apps need memory, make sure the services are short-lived.
• Keep memory usage low.
• Design app to update every 30 minutes but only if device is already awake.
• Services that pall or sleep are bad, that is why you should use AlarmManager or <receiver> manifest elements: stopSelf() when finished. When you start service using AlarmManager, apply the *_WAKEUP flags with caution. Let Android bin your application update together with the rest through setInexactRepeating(). When using <receiver>, enable/disable its components in manifest dynamically, especially when no-ops.

Tip 8: What else you can do

• Check current states of battery and network before launching a full update; wait for better states for bulk transfers.
• Provide users with battery usage options, e.g. update intervals and background behavior.

Implementing UI that leaves minimum memory footprints

---

Tip 9: How to identify layout performance problems

When creating UI sticking solely to basic features of layout managers, you risk to create memory abusing apps with annoying delays in the UI. The first step to implementation of a smooth, memory caring UI is to search your application for potential layout performance bottlenecks with Hierarchy Viewer tool included into Android SDK: <sdk>/tools/. Another great tool for discovering performance issues is Lint. It scans application sources for possible bugs along with view hierarchy optimizations.

Tip 10: How to fix them

If layout performance results reveal certain drawbacks, you might consider to flatten the layout by converting it from LinearLayout class to RelativeLayout class, lowing level hierarchy.

To perfection and beyond

---

Even though each tip mentioned above might seem like a rather small improvement, you might see unexpectedly efficient results if these tips become an essential part of your daily coding. Let Google Play see more brilliant apps that work smoothly, quickly, and consume less battery power, bringing the Android world one more step closer to perfection.

---
This article was originally published on Androidie. [Source]

Agile Development 101

What is Agile Development?

"Agile Development" is an umbrella term for several iterative and incremental software development methodologies. The most popular agile methodologies include Extreme Programming (XP), Scrum, Crystal, Dynamic Systems Development Method (DSDM), Lean Development, and Feature-Driven Development (FDD).

While each of the agile methods is unique in its specific approach, they all share a common vision and core values (see the Agile Manifesto). They all fundamentally incorporate iteration and the continuous feedback that it provides to successively refine and deliver a software system. They all involve continuous planning, continuous testing, continuous integration, and other forms of continuous evolution of both the project and the software. They are all lightweight, especially compared to traditional waterfall-style processes, and inherently adaptable. What is more important about agile methods is that they all focus on empowering people to collaborate and make decisions together quickly and effectively.

The Evolution of Agile Development

Many of the individual principles and practices that are promoted by agile development have been around for years, even decades. As opposed to implementing these best practices piecemeal, agile methodologies have "packaged" various customer, management, and in some cases, engineering practices and principles together in a way that helps guide teams through the process of rapidly planning and delivering working, tested software. Each of the agile methodologies combines both old and new ideas into refinements that are certainly greater than the sums of their parts.

While it is true that many of the practices associated with agile development have been around for quite some time, the average software development team has yet to embrace many of the principles and practices. Even today, the average software team does not iterate, does not deliver software incrementally, and does not practice continuous planning nor automate testing. Now that these practices have been combined in a manner that can more easily be understood and adopted, the trend appears to be rapidly changing for the better, especially during the last several years.

As with any new way of doing business though, Agile methods have generated quite a bit of controversy within the software community. Yet since their emergence, in project after project, they have continued to deliver higher quality software systems in less time than traditional processes. If you are a software development professional, you definitely owe it to yourself to become familiar with the theory and practice of agile development. Hopefully the information presented on this site can assist you in learning what agile is all about.

[Source]

Top 5 requirements for choosing a mobile app development platform

While the strategy formation and vendor selection are always a balance of internal requirements, the companies that “win” have a commonly shared view from both sides of IT and business: this is all about creating business value. Whether that means effecting engagement with your customers or empowering your employees to be more productive, IT and the business must be aligned on objectives in order to advance a truly successful multi-channel strategy.

There are five imperatives that bring the best thinking forward:

1. Mobile devices: they will continue to come.
2. Multi-channel apps: users want a consistent experience.
3. Underlying data sources: how much heavy lifting is involved?
4. Mobile management challenges: protecting the enterprise without messing with Angry Birds.
5. Empowering everywhere: mobilizing the moments of engagement.

These observations are pulled from the hundreds of engagements I’ve been lucky enough to have with prospects and customers building their strategy. Frankly, it’s easy to spot the companies that will have a successful mobile strategy because they ask the right questions.

Often, it’s the business side that will drive the mobile strategy, but the IT group makes recommendations about the options for a mobile vendor. So, how can you ensure that in the end your users get the best possible mobile experience and business creates the most value? Below is a deeper look at the five topics that every selection team should be thinking about. 

Mobile devices: they will continue to come

Over 2 billion mobile devices are sold each year.  That’s a heck of a lot of economic incentive for companies to introduce new and different devices.While Apple and Android smartphones dominate today’s market, Blackberry and Microsoft-powered devices are waiting in the wings. Tablets introduce their own form factors - the current supremacy of the Apple iPad is already under attack.

As you develop your mobile strategy, it’s important to take a multi-channel approach that plans to support multiple new devices.

Multi-channel apps: users want a consistent experience

Moreover, users expect engaging experiences - they aren’t satisfied with miniaturized access to predefined web sites. While mobile web apps are a way to get started, users need task-oriented solutions designed to deliver immediate access to relevant information, direct inputs to enterprise resources, and near real-time updates to one another and to their clientele. These mobile apps run on the devices themselves and leverage integration with GPS, accelerometer, camera, and other sensors.

You should expect to develop multiple native mobile apps, each designed to support specific business tasks and empower targeted groups of users. Invariably, cost becomes a factor. As you mobilize enterprise applications and engage customers, partners, and employees, it’s essential to optimize your firm’s investments in development resources. A good mobile vendor will help ensure that developers can rapidly deliver a continuing stream of native mobile apps. These apps should target the high-value tasks and produce business results.

Underlying data sources: how much heavy lifting is involved?

But native mobile apps are not simply the ends in themselves. Rather, they are the touch points for a larger business context. Mobile apps must communicate with predefined content and data sources to fetch information and return results.

Working with your IT group, you need to identify these data sources, taking into account how frequently you are updating information on the devices and how much data needs to flow across the network. It is important to define the connections between the native mobile apps and the back-end information sources. A good mobile vendor will deliver a flexible and extensible set of connectors to rapidly integrate with your firm’s existing enterprise applications and information sources.

Mobile management challenges: protecting the enterprise without messing with Angry Birds

Finally, there are the inevitable management challenges. How do you best roll out and provision multiple mobile apps to an ever-growing number of users? How do you update the applications and ensure the security of valuable enterprise information stored on the devices, whether they are company assets or employee-owned assets? If need be, how do you restrict the use of the applications to predefined locations and times of day?

A good mobile vendor will match application management capabilities to your organization’s policies and procedures, and enable you to track results.

Empowering everywhere: mobilizing the moments of engagement

As you choose a mobile vendor, be sure to identify the various devices and mobile apps you need to support. But these two factors are only the tip of the iceberg. You also need to pay attention to what is unseen and below the waterline.

These are the three factors related to your overall IT environment: how you integrate with existing applications and information sources, ensure security, and manage the mobile apps across your organization. An integrated SDLC platform like the Kony Multi-Channel Experience Cloud ensures that all of these are covered so you can empower everywhere.

[Source]

Software Process Improvement (SPI) Best Practices

by Scott W. Ambler

1. Be aware of your organization’s current culture. One of the significant forces that affect the success of your process improvement efforts is the culture of your organization. Organizations with cultures that are positive toward process improvement are likely to want to supply a quality product with reasonable business returns, have middle managers that are willing to set and work toward targets of meeting your organization’s needs and business goals, and have senior management leadership that is willing to launch and sustain a long-term change effort.
2. Expect to change your organization’s structure and culture. Process, organizational structure, and corporate culture all go hand-in-hand – change one and you will affect the others. 
3. Keep it simple. A common mistake that organizations make is to over specify the processes that they intend to follow.  Never forget that your goal is to produce working software that meets the needs of your user community and that your staff likely has a pretty good idea of how to do this although they could help with a little guidance from time to time.  Give them just enough guidance for their needs.  An example of a well defined, yet simply defined, process is the Agile Unified Process (AUP).
4. Align your software process with business goals and objectives.  You could have the best process in the world, but if it doesn’t meet your organization’s goals then it doesn’t matter.  Do you intend to build a portfolio of applications that integrate with, and build upon, one another?  If so then portfolio management is important.  Do you intend to sell shrink-wrapped software to be used by millions of users?  If so then architecture may be less important to you in favor of getting a product to market quickly.
5. Regularly hold retrospectives.  A retrospective is a process improvement meeting where you ask four fundamental questions: What did we do well that if we don't discuss we may forget?  What did we learn?  What should we do differently next time?  What still puzzles us?  Retrospectives can be simple 15 minute discussions or formal meetings over a day or two.  The goal is to learn from your experiences.
6. There's a serious difference between "lessons learned" and "lessons indicated".  The result of a retrospective is a collection of lessons indicated, they don't become "learned" until you actually improve your process.  I've been in organizations where we've held a retrospective, sometimes called a post mortem or "lessons learned" session, which resulted in a list of really good process improvement suggestions.  Always one to cause trouble, I then asked if the client had any similar documents from four or five years ago.  Comparing the documents, we've often discovered significant overlap between the lists.
7. Keep the real goal in mind. My experience has been that software processes, when applied intelligently, increase the productivity of developers. My experience has also been that when processes are applied less than intelligently, or when the paper pushers have too much influence within an organization, processes can also decrease your productivity. Organizations that keep the end goal in mind – that of developing, maintaining, and supporting software that fulfills the needs of their user community – will be successful with implementing software processes. Those that follow processes simply for the sake of doing so are likely to fail.
8. Recognize that the fundamentals remain the same, the details vary. Contrary to popular belief, the fundamentals of software development have been known for many years.  You need to perform requirements engineering.  You need to model.  You need to write code.  You need to test.  You need to perform change control.  You get the picture.  Every successful software organization will have a similar set of processes but the way that your organization brings them in and how they implement them will differ.  Your requirements process may be slightly different than your competitors, but you will both have one that will generally do the same sort of thing.
9. You need more than one process.  You wouldn't run a project team of thirty people the same way that you would a team of three people.  Nor would you run an outsourcing project the same way that you're run a project developed by a co-located team.  Nor would you run a data warehouse project the same way that you'd run a .NET application.  You need different processes, or at least different flavors of your process, for different situations.  Use the right process for the job.
10. Run a trailblazer project to validate your new processes. Regardless of how well you define a process, no process is perfect.  Test your new software process using a trailblazer/pilit project, one that is given the extra resources required to try new techniques and to update them appropriately. 
11. Treat process improvement like a project.  Have an experienced project manager, ideally someone with experience in both process-oriented and object-oriented development. Define the requirements for your processes, model them, implement them, test them with a trailblazer project, and then improve the processes.
12. Improve your processes in priority order.  The reality of process improvement is that you cannot make all of the changes that you want to immediately; it is simply too great a change for your organization to absorb at once. This is why we have efforts such as the Software Engineering Institute’s (SEI’s) Capability Maturity Model Integrated (CMMI) efforts and the Software Process Improvement Capability Determination (SPICE) efforts of the International Standards Organization (ISO). Both of these organizations suggest that you prioritize the process improvements that your organization needs to make, expect that it will take several years to make the needed changes, and expect that you will experience difficulties while doing so. There are five maturity levels in the CMMI for a reason: you need to progress in order from level one to level two to level three and so on.  The implication is that by knowing which aspects of a software process map to which CMM maturity levels you have a rough idea of the order in which you should introduce those processes to your staff.  Experience shows that organizations that try to make immediate, large-scale process changes are likely to fail doing so. The reality is that it takes time, often several years, to permanently improve the productivity of your software development efforts. There is not a simple, quick fix to your problems. 
13. Communicate your plan.  It is essential that you let others know what are you doing, why are you doing it, the business case for it, success stories, etc. Keeping them informed on how things are going, even if you are encountering difficulties, will help get them (and keep them) on board. There are various options for this: a newsletter, a web site, periodic emails to key personnel, etc. Trumpet your successes and share your lessons learned with the appropriate people.
14. Accept that the big picture is overwhelming.  Because of the complex nature of software development most developers specialize in one aspect of it and focus solely on that.  This becomes a problem for organizations that wish to tailor a software process for their exact needs because when they put the individual pieces together the overall process becomes very large.  For example, the Rational Unified Process (RUP) is over 3,000 HTML pages in size, and it is only a development process.  Once developers see how large your organization’s software process is they often go into denial, claiming that you can not possibly achieve your goals.  Yet when you ask an individual which part of their process they can simplify they’ll often balk at the idea.  An alternative approach might be something such as the Agile Unified Process (AUP), which is a bit smaller (it's around 30 HTML pages).
15. Democracies do not always work, nor do dictatorships.  Organizations that wish to reach consensus regarding their software process tend to flounder. You’ll never achieve complete agreement on how things should be done, although organizations that dictate processes from above tend to fail as well.  Effective process improvement efforts seek consensus at some points and dictate things at other points.
16. Identify the consumers and suppliers for each process.  Every process has inputs and outputs, and you need to ensure that there is a supplier for each input and a consumer for each output.  Fundamentally, if nobody is going to use an artifact that is produced by a given process then why bother producing it?  You also need to look at collections of processes to see if the artifacts that they produce add value in combination.
17. Defining a process is the easy part. Many organizations are very successful at defining a software process, often producing binders (or web pages) of documentation.  However, when I've revisited these organizations a few months after introducing a new process it will be all but forgotten.  Getting people to accept your new process, and making the changes that go along with it, will take significant time and effort to accomplish.  Writing a process is the easy part, following it is the hard part.
18. Introduce a Software Engineering Process Group (SEPG) to your organization. The sole responsibility of your SEPG is to support the definition and improvement of your organization’s software process. The SEPG should be kept small – as a rule of thumb, we suggest one SEPG member for every one hundred developers in your organization.  SEPG efforts are a component of the EUP's Software Process Improvement (SPI) discipline.
19. Staff your SEPG with actual practitioners.  The people who best understand how to develop software are the people who are very good at developing software.  Yes, that sounds blindingly obvious, but what isn't obvious is that they are usually the best ones suited to define your software process.  Try to staff your SEPG mostly with current practitioners, people who are now managers but had did some COBOL programming 20 years ago are often poor candidates, although include some people with a process background to ensure that they're not reinventing the wheel.
20. Reuse existing process materials.  There is a wealth of process materials out there, you very likely don't need to write your own.
21. Avoid “fire hazard processes". A common mistake is to produce volumes of documentation describing your processes. Your goal is simply to describe your process materials to such a level that they can be given to a professional skilled in the techniques of that process so they can work the processes appropriately.
22. Adopt processes because they make sense.  If a process makes sense to you, and you believe it will add value to your effort, then adopt it.  Otherwise, do not.
23. Hold everyone responsible for process improvement. Senior management must be willing to actively support and sustain process improvement, project managers must be held responsible for ensuring that their teams follow the defined processes, and developers must be held responsible for learning and then following the processes. This is often a difficult task because senior management often demands immediate results, whereas process improvement often takes years. Project managers resent diverting scarce resources from their projects, and developers often resent being told how to do their jobs.
24. Bring in an expert to advise you. Process improvement is a complex and difficult endeavor, one for which you are likely to need help to accomplish. You can increase your chance of success by bringing in a consultant who has both a process background and an OO development background – someone who has been actively involved in a process improvement program and who has worked on large-scale, mission-critical software development projects using OO technology. 
25. Do not think that everyone is on board. There is likely to be a small core of people within your organization who do not want to use object technology for large, mission-critical projects, and these people will actively undermine your efforts. You need to identify these dissenters and work together with them to help them see the advantages of working with object technology and of following a set of defined process patterns to help in the development OO software.
26. A fool with a process is still a fool. For your organization to be successful with a software process your software professionals will need to understand the processes, the concepts, the techniques, and the problem domain. Implementing a new process in your organization involves more than going out and purchasing a couple of new books and development tools.
27. Develop a user guide for your process. You can make it easy for your staff to learn your chosen processes by providing a well-written overview of your process as it is to be implemented in your organization.  In fact, this may be all the process material that you need.
28. Have patience. Progress will be slow at first, slower than you hoped or expected. Introducing a software process into an organization takes time – the required culture shift often takes years to complete.
29. Don’t flounder in bureaucratic requirements.  Too many process efforts run aground because of preconceptions forced on them by senior management, an overly burdensome documentation and review process, or unrealistic requirements to achieve consensus.
30. Define your process early.  The longer you leave process definition the bigger the mess you will have to clean up.  Without direction, developers will typically go and do what they think is right, the only problem being that each person has their own idea of what “right” is.