Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Feed aggregator

What About Cleaning Toilets?

NOOP.NL - Jurgen Appelo - Thu, 07/17/2014 - 16:00
Cleaning toilets

I often promote work-life fusion, quitting jobs that are not fulfilling, and seeking work that is a calling instead of just a career. But, I hear some people think, can this be true for everyone? Is there a great job, somewhere, for every person in the world?

What about cleaning toilets?

How can this work be fulfilling to anyone?

Well, that depends…

The post What About Cleaning Toilets? appeared first on NOOP.NL.

Categories: Project Management

Can I Be A Professional Mobile Developer? (iOS / Android)

Making the Complex Simple - John Sonmez - Thu, 07/17/2014 - 15:00

Yes. Yes, you can. At least I think so. In this video I talk about why.

The post Can I Be A Professional Mobile Developer? (iOS / Android) appeared first on Simple Programmer.

Categories: Programming

How Stand-up Meetings Go Wrong: Team Issues

Bad attitude!

Bad attitude!

The daily stand-up meeting is an easy Agile practice to adopt and an easy process to get wrong.  When an organization or a team gets stand-up meetings wrong the problems tend to stem from either a people or a process problem.  Each category can be broken down into a number of more specific problems, each with different symptoms and solutions. Today we’ll talk about people problems. People problems are really team problems. Teams are made up of the interactions between people pursuing a common goal.  Each person has his or her own motivations, goals and biases.  Because teams are made up of people, teams are complex and chaotic.  Stand-up meetings can be a window into structure and health of any team.  Some typical symptoms seen in stand-up meeting with engagement problems are passive aggressive behavior, poor stand-up attendance, tasking personnel and controlling behavior.

Passive aggressive behavior between individual members  This indirect hostility is sometimes seen as members exchange information during the meeting.  The scrum master/coach should work with the individuals to identify and rectify the behavior.  I generally feel that this type of behavior is difficult to address as a team or in a retrospective because there is often too much personal defensiveness.  If the problem cannot be solved at the team level get a line/HR manager involved, but do this only as a last resort.

Poor attendance  Assuming that there isn’t a scheduling problem, poor attendance reflects how much the team values the stand-up meeting.  If this is a problem, the scrum master/coach should schedule a retrospective to help the team uncover the root cause for the attendance problem.  Attendance problems are generally a reflection of how team members value each other.

Tasking meeting  Stand-ups in which a leader hands out tasks to the team show that the team (or a manager) has not embraced the core Agile principles of self-organized and self-managed teams. In this situation the team either can’t or won’t engage in managing the work.  Start addressing the problem with training and coaching, both at the IT management level and the team level, to drive home how the Agile principles should be practiced.  If an organization or team can’t stop tasking team members, longer-term organizational change is needed. Until that can be accomplished the primary value of Agile is out of reach.

Controlling behavior  Behavior in stand-up meetings often reflects behavior outside the meeting.  Teams generally have a leader, however when a person crosses over the line and becomes dominating, teams can lose the potential advantages of diverse voices. This type of behavior is most common when parts of team are at a power disadvantage. For example, contractors are often placed in subservient position if someone on the team controls their contract renewal.  When this issue is discovered, the scrum master/coach should begin with one-on-coaching change the behavior. Beginning with the specific team members in a problem makes sure no one feels blindsided (this is rarely a conscious behavior). Secondly, I find that after the team members are aware of the problem, it is helpful for the team to address the issue using retrospectives.

A good scrum master/coach needs to look for coachable moments to recognize and confront the problems. Where the issue is more systemic, techniques like retrospectives and training can be brought to bear. In the end everyone involved have to recognize the symptoms, but treat the problems.

Categories: Process Management

The New Roboto

Google Code Blog - Wed, 07/16/2014 - 18:00
By Christian Robertson, Android Visual Designer

Along with the Material Design guidelines we released a new version of the Roboto type family. A lot of things have changed as we tuned the font to work across more screen sizes and conditions, from watches to desktops, televisions to cars. It still keeps much of its character that made it successful for both phones and tablets, but almost every glyph has been tweaked and updated in some way.

We see Roboto as an evolving type family and plan to continue to change and update it as the system evolves. It used to be that a type family was designed once and then used without change for many years. Sometimes an updated version was released with a new name, sometimes by appending a "Neue" or "New". The old model for releasing metal typefaces doesn't make sense for an operating system that is constantly improving. As the system evolves over time, the type should evolve along with it.

The easiest way to identify the new version is to look for the R and K. They were some of the rowdier glyphs from version one and have been completely redrawn. Also check for the dots on the letter i or in the punctuation. We have rounded them out to make the types a little more friendly when you look at them closely. We also rounded out the sides of the upper case characters like O and C which makes the font feel less condensed even though it still has a high character count per line.

Some of the most significant changes are in the rhythm and spacing, especially for the caps. This isn't apparent as you look at individual glyphs, but makes for a better texture on the screen. Some of the more subtle fixes were to balance the weights between the caps and lowercase characters (the caps are slightly heavier in this version) and better correction for the distortions that occur in the obliqued italic characters.

Ultimately the purpose of a typeface is to serve the content and help people to understand it. We think that the new updates to Roboto along with the new Material Design guidelines will help it do more of just that.

Posted by Louis Gray, Googler
Categories: Programming

10 Program Busting Caching Mistakes

While Ten Caching Mistakes that Break your App by Omar Al Zabir is a few years old, it is still a great source of advice on using caches, especially on the differences between using a local in-memory cache and when using a distributed cache.

Here are the top 10 mistakes (summarized):
  1. Relying on a default serializer. Default serializers can use a lot of CPU, especially for complex types. Give some thought to the best serialization and deserialization method for your language and environment.
  2. Storing large objects in a single cache item. Because of serialization and deserialization costs, under concurrent load, frequent access to large object graphs can kill your server's CPU. Instead, break up the larger graph into smaller subgraphs and cache them separately. Retrieve only the smallest unit you need.
  3. Using cache to share objects between threads. Race conditions, when writes are involved, develop if parts of a program are accessing the same cached items simultaneously. Some sort of external locking mechanism is needed. 
  4. Assuming items will be in cache immediately after storing them. Never assume an item will be in a cache, even after it was just written, because a cache can flush items when memory gets tight. Code should always check for a null return value from a cache.
  5. Storing entire collection with nested objects. Storing an entire collection when you need to get a particular item results in poor performance because of the serialization overhead. Cache individual items separately so they can be retrieved separately. 
  6. Storing parent-child objects together and also separately. Sometimes an object will simultaneously be contained in two or more parent objects. To not have the same object stored in two different places in the cache store it on its own under its own key. The parent objects will then read the objects when access is needed.
  7. Caching Configuration settings. Store configuration data in a static variable that is local to your process. Accessing cached data is expensive so you want to avoid that cost when possible.
  8. Caching Live Objects that have open handle to stream, file, registry, or network. Don't cache objects the have references to resources like files, streams, memory, etc. When the cached item is removed from the cache those resources will not be deleted and system resources will leak. 
  9. Storing same item using multiple keys. It can be convenient to access an item by a key and an index number.  This can work when a cache is in-memory because the cache can contain a reference to the same object which means changes to the object will be seen through both access paths. When using a remote cache any updates won't be visible so the objects will get out of sync. 
  10. Not updating or deleting items in cache after updating or deleting them on persistent storage. Items in a remote cache are stored as a copy, so updating an object won't update the cache. The cache must specifically be updated for the changes to be seen by anyone else. With an in-memory cache changes to an object will be seen by everyone. Same for deletion. Deleting an object won't delete it from the cache. It's up to the program make sure cached items are deleted correctly.
Categories: Architecture

The Robotic Jockey

Software Requirements Blog - - Wed, 07/16/2014 - 12:18
In the March 1945 issue of “Radio-Craft”, a bold vision was laid out for the future of horse racing: human jockeys should be replaced by motorized, radio-controlled “Robotic Jockeys”.   Taken from the same article, the author describes how these new jockeys would work: “The “jockey” would consist of a modern radio receiver, with outputs […]
Categories: Requirements

R: Apply a custom function across multiple lists

Mark Needham - Wed, 07/16/2014 - 06:04

In my continued playing around with R I wanted to map a custom function over two lists comparing each item with its corresponding items.

If we just want to use a built in function such as subtraction between two lists it’s quite easy to do:

> c(10,9,8,7,6,5,4,3,2,1) - c(5,4,3,4,3,2,2,1,2,1)
 [1] 5 5 5 3 3 3 2 2 0 0

I wanted to do a slight variation on that where instead of returning the difference I wanted to return a text value representing the difference e.g. ’5 or more’, ’3 to 5′ etc.

I spent a long time trying to figure out how to do that before finding an excellent blog post which describes all the different ‘apply’ functions available in R.

As far as I understand ‘apply’ is the equivalent of ‘map’ in Clojure or other functional languages.

In this case we want the mapply variant which we can use like so:

> mapply(function(x, y) { 
    if((x-y) >= 5) {
        "5 or more"
    } else if((x-y) >= 3) {
        "3 to 5"
    } else {
        "less than 5"
  }, c(10,9,8,7,6,5,4,3,2,1),c(5,4,3,4,3,2,2,1,2,1))
 [1] "5 or more"   "5 or more"   "5 or more"   "3 to 5"      "3 to 5"      "3 to 5"      "less than 5"
 [8] "less than 5" "less than 5" "less than 5"

We could then pull that out into a function if we wanted:

summarisedDifference <- function(one, two) {
  mapply(function(x, y) { 
    if((x-y) >= 5) {
      "5 or more"
    } else if((x-y) >= 3) {
      "3 to 5"
    } else {
      "less than 5"
  }, one, two)

which we could call like so:

> summarisedDifference(c(10,9,8,7,6,5,4,3,2,1),c(5,4,3,4,3,2,2,1,2,1))
 [1] "5 or more"   "5 or more"   "5 or more"   "3 to 5"      "3 to 5"      "3 to 5"      "less than 5"
 [8] "less than 5" "less than 5" "less than 5"

I also wanted to be able to compare a list of items to a single item which was much easier than I expected:

> summarisedDifference(c(10,9,8,7,6,5,4,3,2,1), 1)
 [1] "5 or more"   "5 or more"   "5 or more"   "5 or more"   "5 or more"   "3 to 5"      "3 to 5"     
 [8] "less than 5" "less than 5" "less than 5"

If we wanted to get a summary of the differences between the lists we could plug them into ddply like so:

> library(plyr)
> df = data.frame(x=c(10,9,8,7,6,5,4,3,2,1), y=c(5,4,3,4,3,2,2,1,2,1))
> ddply(df, .(difference=summarisedDifference(x,y)), summarise, count=length(x))
   difference count
1      3 to 5     3
2   5 or more     3
3 less than 5     4
Categories: Programming

Control Systems - Their Misuse and Abuse

Herding Cats - Glen Alleman - Wed, 07/16/2014 - 03:23

Modern Contrrol EngineeringProject Management is a control system, subject to the theory and practice of control systems. The Project Management Control System provides for the management of systems and processes - cost estimating, work scope structuring and authorization, scheduling, performance measurement, reporting, for assessing the progress of spending other peoples money.

The level of formality for these processes varies according to domain and context. From sticky notes on the wall for a 3 person internal warehouse locator website of a plastic shoe manufacture -  to a full DCMA ANSI-748C validated Earned Value Management System (EVMS) on a $1B software development project and everything in between.

The key here is if we're going to say we have a control system it needs to be a Closed Loop control system, not an Open Loop control system. On Open Loop system is called train watching, we sit by the side of the tracks and count the trains going by and report that number. How many trains should go by, could go by? We don't know. That's what's shown in the first picture. We sample the data, we apply that data to the process and it generates an output. There is no corrective action, it's just a signal based on the past performance of the system. Some examples of Open Loop control implemented in the first picture:

  • A light switch. Turn it on the light goes on. Turn it off the light goes off. Turn it on and the light doesn't go on, don't know why. Could be the switch, could be the blub is burned out, could be the power is out in the neighborhood.
  • Same for a faucet, the burned on the stove, a simple cloths dryer when you use the timer rather than the sense cloths are dry feature.
  • The really cool shade we just installed for the upper deck. Push the button and it lowers to a present position, push it again and it goes back to the storage position.

The key attribute of Open Loop Control 

  • It is a non-feedback system, is a type of continuous control system in which the output has no influence or effect on the control action of the input signal.
  • In an open-loop control system the output is neither measured nor fed back for comparison with the input.
  • An open-loop system is expected to faithfully follow its input command or set point regardless of the final result.
  • An open-loop system has no knowledge of the output condition so cannot self-correct any errors it could make when the preset value drifts, even if this results in large deviations from the preset value.

The key disadvantage of open-loop systems is it is poorly equipped to handle disturbances or changes in the conditions which that reduce its ability to complete the desired task. 

A close loop system behaves differently. Here's some example of controllers used in the second picture

  • Thermostat for the furnace or air conditioner - Set a target temperature and it holds that temperature pretty much constant 
  • Refrigerator cold/hot setting - keeps the food in the refrigerator at a preset temperature 
  • Same for the temperature setting for oven.

The key attributes of  Close Loop Control, shown in the second picture

  • Closed-loop systems are designed to automatically achieve and maintain the desired output condition by comparing it with the actual condition.
  • This is done by generating an error signal which is the difference between the output and the reference input.
  • A “closed-loop system” is a fully automatic control system in which its control action being dependent on the output in some way.

Because the closed-loop system has  knowledge of the output condition - in the case of projects the desired cost, schedule, and technical performance, it is  equipped to handle  system disturbances or changes in the conditions which may reduce its ability to complete the desired task.

When we have a target cost - defined on day one by the target budget, a planned need date, and some technical performance target, closed loop control provides the needed feedback to make decisions along the when, when the actual performance is not meeting our planned or needed performance

Open Closed Loop

In the end it comes back to the immutable principle of microeconomics. When we are spending money to produce a value, we need to make decisions about which is the best path to take, which are the best of multiple options to choose. In our to do this we need to know something about the cost, schedule, and performance forecasts from each of the choices. Then we need feedback from the actual performance to compare with our planned performance to create an error signal. With this error signal, we can then DECIDE what corrective actions to take.

Without this error signal, derived from the planned values compared with the actual values there is no information needed to decide. Sure we can measure what happened in the past and decide, just like we can count trains and make some decision. But that decision is not based on a planned outcome, a stated need, or an Estimated Arrival time for example. 

Without that estimated arrival time, we can't tell if the train is late or early, just that it arrived. Same with the project measurements.

  • We need on average 4.5 stories per iteration. How many stories did you need to do to finish the project on the planned day with the planned capabilities.

Open Loop provides no feedback, so you're essentially driving in the rear view mirror, when you should be looking out the windshield deciding where to go next to escape the problem.

Objects are closer3

Related articles Can We Make Decisions Without Feedback? Seven Immutable Activities of Project Success Agile Requires Discipline, In Fact Successful Projects Require Discipline The DCMA 14 Point Schedule Assessment Control system and its classification The Failure of Open Loop Thinking First Comes Theory, Then Comes Practice All Project Numbers are Random Numbers - Act Accordingly
Categories: Project Management

Quote of the Day - Writing SW For Money Is Micro-Economics

Herding Cats - Glen Alleman - Wed, 07/16/2014 - 03:12

We find no sense in talking about something unless we specify how we measure it. A definition by the method of measuring a quantity is the one sure way of avoiding talking nonsense — Sir Hermann Bondi

So when we hear a suggested approach to solving any problem, what are the units of measure of the discussion elements, the inputs to that discussion, and the outcomes?

Micro-economics is defined as

A branch of economics that studies the behavior of individuals and small impacting players in making decisions on the allocation of limited resources. Typically, it applies to markets where goods or services are bought and sold.

Certainly in the software development business, goods are bought and sold. Software is developed in exchange for money. The resulting product is then put to work to generate some monetized value for the buyer. The value exchanged for the cost of that value is usually assessed as the Return on Investment

ROI = (Value - Cost of the Value) / Cost of the Value

Economics of Iterative DevelopmentLet's start with some basic concepts of writing software for money. I'd suggest these are immutable concepts in a for proft business world. The book on the left is a ggod start, but there are other materials about the economics of software development. The one that comes to mind is Software Engineering Economics, Barry Boehm, Prentice Hall. While some has suggested this book is dated and no longer applicable to our modern software development paradigm, that could only be true if our modern paradigm is not subject to the principles of micro-economics. And that is unlikely, so let's proceed with applying the principles of micro-economics to the problem at hand. That problem is

How can we know the cost, schedule, and performance of a software product with sufficient confidence into order to make business (micro-economic) decisions about how to manage the limited resources of the project?

Those resources are of course the variables we are trying to determine. Cost, Schedule, and Performance. Each of which contains resources. Cost in software development is primarily driven by staff. Schedule is driven by the efficacy of that staff's ability to write code. And the performance of the resulting outcomes are driven by the skills and experience of the staff, who is consuming the funds (cost) provided to the project.

So if we look at the basics of the economics of writing software for money, we'll see some simple principles.

If it's a product development effort, someone in the marketing and sales department has a planned release date. This date and the projected revenue from that release is in the sales plan. These are random numbers of course -  so I won't repeat that, but all numbers in business are random numnbers until they get entered into the General Ledger.

  • These projected revenue numbers are based on releasing the product with the features needed for customers to buy it.
  • The cost to develop that product is subtracted from the revenue - usually in some complex manner - to produce the retained earnings attributed to the product. 
  • This of course is the simple formula
    • Earnings = Revenue - Cost 
    • Where cost is categorized in many ways, some attributable to the development of the product, some to overhead, benefits, fringe, and other indirect costs (ODC).
    • Revenue recognition is a continuously evolving issue with taxes and performance reporting in actual firms
    • But for the purposes here, the simple formula will do. Managerial Finance, Brigham and Weston is a good place to look for the details.

If it's a service effort, the customer has engaged the firm to perform some work in writing software, doing consulting around that software, integrating existing software or some combination of these and other software related services. Managing the Professional Services Firm, was mandatory reading along wioth other internal company written books when I worked for a large Professional Services (PS) firm. With our small firm now, we still refer to that book.

  • Some type of problem needs to be solved involving a solution that uses software (and maybe hardware), processes, and people.
  • The cost, schedule, and capabilities of the solution need to be worked out in some way in order to know what DONE looks like. Any one subscribing to this Blog know the Knowing What Done Looks Like is a critical success factor for any effort.
  • But in the case of a services solution, this knowing is a bit more difficult than the product solution, since the customer may not know themselves. 
  • This is the golden opportunity for incremental and itertaive development.
  • But in the end the PS customer still needs to know the cost, schedule, and what will be delivered, because that person has a similar ROI calculation to do for those funding the PS work.
Related articles Earning Value from Earned Value How To Assure Your Project Will Fail Why Johnny Can't Estimate or the Dystopia of Poor Estimating Practices The Value of Information
Categories: Project Management

When Don’t Daily Stand-up Meetings Make Sense

Superman probably does not need a stand-up meeting but Clark Kent is another story!

Superman probably does not need a stand-up meeting but Clark Kent is another story!

The daily stand-up meeting has become a nearly ubiquitous feature of Agile projects and also can be found in Kanban (lean), support projects and even in some waterfall projects.  Proliferation of the stand-up meeting shouldn’t be surprising – the meeting is simple, typically short and easy(ish) to implement.  However, there are a few circumstances where daily stand-up meetings, as we defined them, should not be used.  These circumstances revolve around two general areas, team size (too small and too big) and team/organizational culture.

The guidelines generally quoted for the size of Scrum teams is 7 members plus or minus 2 (5 to 9 people).  This is because of the number of possible combinations of communication channels between team members.  Smaller project teams don’t have all of the skills needed to bring a typical corporate IT project to fruition.  However smaller team can and do exist.  My general recommendation is that stand-up meetings make sense for any team that has more than one team member. A single person doing a stand-up by himself using the classic format is just strange; they should do daily planning.  The same argument could be made for a team of two that does pair development, however taking a few minutes to review what is done and plan the day is the essence of a stand-up meeting.  Larger Scrum teams have just as gray a limit as small teams, however we can all agree that as team size grows, it takes substantially more effort for everyone to stay connected. As team size grows, sub-teams form around specific functions or technical specialties. In other words, the team naturally breaks into smaller teams that communicate more freely.  As teams get bigger than 10 members I find that stand-up meetings begin taking longer (30 minutes instead of 15), generally have to chaired by the Scrum master or an authority figure and become status meetings rather than planning meetings.  I have even seen pseudo stand-up meetings with published agendas. These types of meeting may be occasionally necessary, but I can state categorically that they are not stand-up meetings.

The extremes project-team size aside, the other major reason for not doing stand-up meetings is an environment that does not support the concept of self-organization and self-managing teams. Stand-up meetings, by design, are planning meetings in which team members communicate plans to their peers, solicit and provide support for each other and identify roadblocks to further progress.  The stand-up meeting won’t work in organizations or teams where that type of behavior is not considered appropriate or where managers must gather statuses and dispense work.  Other types of daily tasking or status meetings might be appropriate, but those meetings even if every stands up are NOT stand-up meetings in the Agile sense.  Agile stand-up meetings provide just-in-time planning for teams, and just as importantly empower the team to solve the business problems as a team. Without the planning component, they are merely status meetings.

There are very few good reasons not to leverage daily stand-up meetings.  The extremes of team size, large or small, makes the logistics of a stand-up difficult. Single person projects probably don’t need stand-up meetings; instead I find that reflecting on what I accomplished the day before and what I am going to do today when I run highly effective.  Teams that are too large, probably need to be broken up into smaller teams that can more effectively communicate.  Organizations that don’t embrace the 12 Agile principles ought to put off using stand-up meetings and consider changing their culture first.  But that is a topic for another day.

Categories: Process Management

Noto: A CJK Font That is Complete, Beautiful and Right for Your Language and Region

Google Code Blog - Tue, 07/15/2014 - 23:00
By Xiangye Xiao, Stuart Gill, and Jungshik Shin,
Google Text and Font Team, Internationalization Engineering

Chinese, Japanese and Korean (CJK) readers represent approximately one quarter of the world’s population. Google’s mission is to organize the world’s information and make it universally accessible to all users no matter what language they use. To that end, Google, in cooperation with our partner Adobe, has released a free, high-quality Pan-CJK font family: Noto Sans CJK. These fonts are intended to provide a richer and more beautiful reading experience to the East Asian community in many OSes and software applications.

Noto Sans CJK comprehensively covers Simplified Chinese, Traditional Chinese, Japanese, and Korean in a unified font family and yet conveys the expected aesthetic preferences of each language. Noto Sans CJK is a sans serif typeface designed as an intermediate style between the modern and traditional. It is intended to be a multi-purpose digital font for user interface designs, digital content, reading on laptops, mobile devices, and electronic books. Noto Sans CJK is provided in seven weights: Thin, Light, DemiLight, Regular, Medium, Bold, and Black.

Fully supporting CJK requires tens of thousands of characters—these languages share the majority of ideographic characters, but there are also characters that are unique to only one language or to a subset of the languages. One of the primary design goals of Noto Sans CJK is that each script should retain its own distinctive look, which follows regional conventions, while remaining harmonious with the others.

Chinese ideographic characters are not only used by Simplified and Traditional Chinese, where they are called hanzi, but also by Japanese (kanji) and Korean (hanja). Although all originated from ancient Chinese forms, in each region and language they evolved independently. As a result, the same character can vary in shape across the different languages. For example, the image below shows variants of the same character (骨 - bone) designed for Simplified Chinese, Traditional Chinese, Japanese, and Korean. Look at how the inner top part and inner bottom part are different. Noto Sans CJK is designed to take these variations into account. In addition to ideographic characters, Noto Sans CJK also supports Japanese kana and Korean Hangeul—both contemporary and archaic.

Google and Adobe partnered to develop this free high-quality Pan-CJK typeface. Google will release it as Noto Sans CJK as part of Google's Noto font family. Adobe will release it as Source Han Sans as a part of Adobe's Source family. Adobe holds the copyright to the typeface design, and the fonts are released under the Apache License, version 2.0 which makes them freely available to all without restriction.

About this partnership: Google contributed significant input into project direction, helped to define requirements, provided in-country testing resources and expertise, and provided funding that made this project possible. Adobe brought strong design and technical prowess to the table, along with proven in-country type design experience, massive coordination, and automation. In addition, three leading East Asian type foundries were also brought in to design and draw a bulk of the glyphs—Changzhou SinoType Technology, Iwata Corporation, and Sandoll Communication—due to the sheer size of the project and their local expertise.

Building Noto Sans CJK font is a major step towards our mission to make the reading experience beautiful for all users on all devices. Noto Sans CJK is the newest member of the Noto font family, which aims to support all languages in the world. The entire Noto font family, including Noto Sans CJK, is free and open. Visit the Noto homepage to download Noto Sans CJK and other Noto fonts.

Xiangye Xiao is a Product Manager at Google Inc. where she works on fonts and text input.
Stuart Gill is the Tech Lead and Manager of Google’s Text and Font team.

Jungshik Shin is the Noto visionary and is a Software Engineer in Google’s Internationalization Engineering team working on Text and Fonts as well as on Chrome.

Posted by Louis Gray, Googler
Categories: Programming

Learn to Think Like an Android Developer

Android Developers Blog - Tue, 07/15/2014 - 19:57

By Reto Meier, Head of Scalable Developer Advocacy

Today I’m proud to announce the latest resource for learning to develop Android apps: Developing Android Apps: Android Fundamentals.

Android Fundamentals is an online training course featuring Google Developer Advocates Reto Meier, Dan Galpin, and Katherine Kuan, working with the team at Udacity that’s advanced and technical enough for experienced developers who are new to Android — maybe even new to mobile — but not new to programming.

The course offers step-by-step training in which you’ll build an Android app, and learn best practices of mobile development in general and Android development in particular.

The full course materials — all the videos, quizzes, and forums — are available for free for all students by selecting “View Courseware”. Personalized ongoing feedback and guidance from Coaches is also available to anyone who chooses to enroll in Udacity’s guided program.

This guided course, along with UX Design for Mobile Developers and Mobile Web Development, complement our existing material—including documentation, samples, and videos — to offer a solid grounding in developing great experiences for people using mobile devices. Check out the trailer below for an overview of what's in the course.

Mobile devices are the platform that will bring the next five billion people online. With Android expanding rapidly into emerging markets, and growing beyond phones and tablets into wearables, auto, and TV, learning the fundamentals behind Android development represents an opportunity to affect and improve the lives of billions of people.

We look forward to seeing what the next wave of Android developers build, and we’ll keep exploring new ways to help you become better developers.

Join the discussion on
+Android Developers

Categories: Programming

Whitepaper on Getting QA and Developers To Work Together and Upcoming Webinar

Making the Complex Simple - John Sonmez - Tue, 07/15/2014 - 16:43

Just wanted to do a short post to talk about a whitepaper I wrote for one of the companies that has been a big supporter of this blog, Zephyr, and also invite you to check out a webinar I’ll be doing next week on “How trying to learn too much may actually be hurting you–and […]

The post Whitepaper on Getting QA and Developers To Work Together and Upcoming Webinar appeared first on Simple Programmer.

Categories: Programming

The Power of Misattributed and Misquoted Quotes

Herding Cats - Glen Alleman - Tue, 07/15/2014 - 15:30

Warning this is an Opinion Piece.

In a conversation this week the quote Insanity is doing everything the same way and expecting a different outcome. Or some variant of that. Attributed to Einstein. As if attributing it to Einstein makes it somehow more credible, than attributing it to Dagwood Bumstead.

Well it turns out it is not a quote from dear olde Albert. It is also mis-attributed to Ben Franklin, Confucius, and a Chinese proverb.

The first printed record of this quote is in the 1981 Narcotics Anonymous approval version of their handbook. No other printed record is found. 

Why is this Seemingly Trival Point Important

We toss around platitudes, quotes, and similar phrases in the weak and useless attempt to establish credibility of an idea by referencing some other work. Like quoting a 34 year old software report from NATO, when only mainframes and FORTRAN 77 were used, to show the software crisis and try to convince people it's the same today. Or use un-vetted, un-reviewed, charts and graphs from an opinion piece in popular techncial magazine as the basis of statistical analysis of self-selected data

Is it world shaking news? No. Is the balanced of the universe disrupted? Hardly. 

But is shows a lack of mental discipline that leaks into the next level of thought process. It's always the little things that count, get those right and the big things follow. That is a quote from somewhere. But it also shows laziness of thought, use of platitudes in place of the hard work to solve nearly intractable problems, and all around disdain for working on those hard problems. It's a sign of our modern world - look for the fun stuff, the easy stuff, and the stuff we don't really want to be held accountable for if it goes wrong

I will use the Edwin Land quote though, that is properly attributed to him

Don't undertake a project unless it is manifestly important and nearly impossible. 

That doesn't sound like much fun, let's work on small, simple, and easy projects and tell everyone how those successful processes we developed can be scaled to the manifestly important and nearly impossible ones.

Related articles Resources for Moving Beyond the "Estimating Fallacy" How to Deal With Complexity In Software Projects? 50 Common Misquotations, but no Howard Thurman Fake quotes flood social media 31 Famous Quotations You've Been Getting Wrong 6 Famous Misquotes & Where They Came From (Mis)quoting Neil Armstrong
Categories: Project Management

Simplify Prioritization into “Now” and “Not Now”

Mike Cohn's Blog - Tue, 07/15/2014 - 15:00

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

I think I’d like to buy a big-screen plasma television. And maybe after that, a new amplifier for my home theater.

I’ve also noticed that our home dishwasher doesn’t dry as well as it used to. For some reason, this doesn’t bother my wife, Laura, but it annoys me. So I’d like to replace the dishwasher.

The clothes washer is doing fine, but the dryer isn’t working too well. I think we’ve had it 14 years, and I sometimes have to run the drying cycle three times before clothes are fully dried. So, I’ll probably want to buy a clothes dryer, too. I’ve also lately become irritated by the toaster. It’s great and works well, but bread doesn’t fit. I have to angle the bread, with part sticking out of the toaster – so, I get partially toasted bread. Or, I flip the bread midway and then get the middle of the bread overly toasted. So, add a new toaster to the list.

After all that, a new car might be nice.

What is this list? Well, my personal Things to Buy Backlog, of course. It’s a prioritized sequenced list of things I plan to buy. To facilitate long-term planning it includes everything I plan to buy for the next 12 months:

  1. Groceries
  2. Tickets to movies that haven’t been released yet
  3. A magazine that I’ll buy in Newark airport next October because I’ll find a cover story intriguing
  4. A new pair of shoes
  5. Big-screen plasma TV
  6. Home theater amplifier
  7. Dishwasher
  8. Clothes dryer
  9. Toaster
  10. Car

Don’t you have a list like this, with that level of detail? Of course not. Neither do I. We don’t make lists like this because such a list is unnecessary. In everyday life, we don’t map out the equivalent of a product backlog.

Instead, we make our purchase decisions in a much simpler fashion: “Now” or “not now.” Do I want that big television now, or not now? And this amount of prioritization is good enough.

In many cases, it is also good enough for our product development projects.

Sure, you’ll always need to know what you’re going to build this sprint. But what you build next sprint will likely depend on what the team delivers this sprint, and on how customers respond to it.

That means you might want to forgo prioritizing any further ahead unless you are in an environment that requires it, such as contract development.

Prioritizing features in a “now/not now” manner streamlines your planning process, allows learning to be incorporated into the planning process, and better matches how we prioritize outside the workplace.

Many projects will find this a very valuable shift.

In next month’s newsletter, I’ll write about how to do this within the context of establishing a longer-term vision for a product.

Don’t Begin UAT Until…

Software Requirements Blog - - Tue, 07/15/2014 - 12:20
As projects run long and budgets get tight, the first thing that gets squeezed is testing. Even with the best of intentions, the planning, design, and development phases often go longer than expected. In order to meet that precious target rollout date, testing can get rushed. However, it is really important that testing is done […]
Categories: Requirements

Daily Stand-Up Meetings: The Most Ubiquitous Agile Practice

Preparing for a Daily Stand Up

Preparing for a Daily Stand-Up

The daily stand-up meeting easiest Agile practice to adopt and the easiest to get wrong.  In order to get it right, we need to understand the basic process and the most common variants. These include interacting with task lists/boards and distributed team members. The basic process is blindingly simple.

  1. The team gathers on a daily basis.
  2. Each team member answers three basic questions:
    1. What tasks did I complete since the last meeting;
    2. What tasks do I intend to complete before the next meeting and
    3. What are the issues blocking my progress.
  3. The meeting ends team members’ return to work OR discuss other items.

This is the barest bones version of stand-up meeting.  The meeting is typically attended by the whole team, which includes the scrum master/coach, the product owner and all other team members.  Arguably while the product owner is not a required participant based on the published Scrum guidelines, their central role makes them an important contributor to the meeting when questions about direction come up. I advise team members to discuss whether the product owner will participate (highly recommended) when they develop the Agile team charter and add participation to the team norms.

The most common process addition is the inclusion of a task list/board, either as a physical list often found on the wall of a team room or virtually through the use of a software tool. The team will use the board to guide the discussion.  The tasks they talk about should be on the wall or in the tool.  A rule that is sometimes adopted is that team members do not work on items not on the wall (or tool). The task list focuses the team and provides visual feedback as tasks change status.

You will need to add the following steps to the process when using a list or board:

  1. Ensure that all participants can see and interact with the list during the stand-up and throughout the day.
  2. Update the board or tool in as close to real time as possible.

Lists and boards can get out of sync with reality.  Out of sync tools deliver bad information and can lead to work failing through the cracks.  When tools or task list are used they must be kept up to-date. Each team member must keep his or her tasks up-to-date.  This is not the scrum master/coaches role; they not project administrators.

Distributed teams, teams where one or more team members are in a different location, present several challenges, including time zones, accents, organization affiliation and sometimes language. In general, the stand-up meeting should be basically the same, regardless of the participant’s location. What typically does change are the tools needed to make the meeting effective. Videoconference or good teleconference equipment is an absolute must, as is access to the task list (a virtual tool is useful).

You will need to add the following steps to the process when the team is distributed:

  1. Ensure that everyone on the team can see and hear each other.  This typically means securing or scheduling video or teleconferencing facilities.
  2. Ensure that all participants can see and interact with the list during the stand-up and throughout the day.
  3. Update the board or tool in as close to real time as possible.

The stand-up meeting is a simple meeting that Agile teams hold on a daily basis to plan and synchronize activities.  Adding lists and tools can make the meeting more effective by focusing team effort, BUT adding lists and tools means that the team needs to keep them up to date and use them!  If we add complications such as distributing the team, virtual tools become a necessity. I have had to ask more than one team what value they were getting from a stand-up if part of the team couldn’t hear and participate.

Categories: Process Management

Measuring Coverage at Google

Google Testing Blog - Mon, 07/14/2014 - 20:45
By Marko Ivanković, Google Zürich

Code coverage is a very interesting metric, covered by a large body of research that reaches somewhat contradictory results. Some people think it is an extremely useful metric and that a certain percentage of coverage should be enforced on all code. Some think it is a useful tool to identify areas that need more testing but don’t necessarily trust that covered code is truly well tested. Others yet think that measuring coverage is actively harmful because it provides a false sense of security.

Our team’s mission was to collect coverage related data then develop and champion code coverage practices across Google. We designed an opt-in system where engineers could enable two different types of coverage measurements for their projects: daily and per-commit. With daily coverage, we run all tests for their project, where as with per-commit coverage we run only the tests affected by the commit. The two measurements are independent and many projects opted into both.

While we did experiment with branch, function and statement coverage, we ended up focusing mostly on statement coverage because of its relative simplicity and ease of visualization.

How we measured
Our job was made significantly easier by the wonderful Google build system whose parallelism and flexibility allowed us to simply scale our measurements to Google scale. The build system had integrated various language-specific open source coverage measurement tools like Gcov (C++), Emma / JaCoCo (Java) and (Python), and we provided a central system where teams could sign up for coverage measurement.

For daily whole project coverage measurements, each team was provided with a simple cronjob that would run all tests across the project’s codebase. The results of these runs were available to the teams in a centralized dashboard that displays charts showing coverage over time and allows daily / weekly / quarterly / yearly aggregations and per-language slicing. On this dashboard teams can also compare their project (or projects) with any other project, or Google as a whole.

For per-commit measurement, we hook into the Google code review process (briefly explained in this article) and display the data visually to both the commit author and the reviewers. We display the data on two levels: color coded lines right next to the color coded diff and a total aggregate number for the entire commit.

Displayed above is a screenshot of the code review tool. The green line coloring is the standard diff coloring for added lines. The orange and lighter green coloring on the line numbers is the coverage information. We use light green for covered lines, orange for non-covered lines and white for non-instrumented lines.

It’s important to note that we surface the coverage information before the commit is submitted to the codebase, because this is the time when engineers are most likely to be interested in improving it.

One of the main benefits of working at Google is the scale at which we operate. We have been running the coverage measurement system for some time now and we have collected data for more than 650 different projects, spanning 100,000+ commits. We have a significant amount of data for C++, Java, Python, Go and JavaScript code.

I am happy to say that we can share some preliminary results with you today:

The chart above is the histogram of average values of measured absolute coverage across Google. The median (50th percentile) code coverage is 78%, the 75th percentile 85% and 90th percentile 90%. We believe that these numbers represent a very healthy codebase.

We have also found it very interesting that there are significant differences between languages:


The table above shows the total coverage of all analyzed code for each language, averaged over the past quarter. We believe that the large difference is due to structural, paradigm and best practice differences between languages and the more precise ability to measure coverage in certain languages.

Note that these numbers should not be interpreted as guidelines for a particular language, the aggregation method used is too simple for that. Instead this finding is simply a data point for any future research that analyzes samples from a single programming language.

The feedback from our fellow engineers was overwhelmingly positive. The most loved feature was surfacing the coverage information during code review time. This early surfacing of coverage had a statistically significant impact: our initial analysis suggests that it increased coverage by 10% (averaged across all commits).

Future work
We are aware that there are a few problems with the dataset we collected. In particular, the individual tools we use to measure coverage are not perfect. Large integration tests, end to end tests and UI tests are difficult to instrument, so large parts of code exercised by such tests can be misreported as non-covered.

We are working on improving the tools, but also analyzing the impact of unit tests, integration tests and other types of tests individually.

In addition to languages, we will also investigate other factors that might influence coverage, such as platforms and frameworks, to allow all future research to account for their effect.

We will be publishing more of our findings in the future, so stay tuned.

And if this sounds like something you would like to work on, why not apply on our job site?

Categories: Testing & QA

Bitly: Lessons Learned Building a Distributed System that Handles 6 Billion Clicks a Month

Have you ever wondered how bitly makes money? A URL shortener can’t be that hard to write, right? Sean O'Connor, Lead Application Developer at bitly, answers the how can bitly possibly make money question immediately in a talk he gave on bitly at the Bacon conference.

Writing a URL shortner that works is easy, says Sean, writing one that scales and is highly available, is not so easy.

Bitly doesn’t make money with a Shortening as a Service service, bitly makes money on an analytics product that mashes URL click data with with data they crawl from the web to help customers understand what people are paying attention to on the web. 

Analytics products began as a backend service that crawled web server logs. Logs contained data from annotated links along with cookie data to indicate where on a page a link was clicked, who clicked it, what the link was, etc. But the links all went back to the domain of the web site. The idea of making links go to a different domain than your own so that a 3rd party can do the analytics is a scary proposition, but it’s also kind of genius.

While this talk is not on bitly’s architecture, it is a thoughtful exploration on the nature of distributed systems and how you can solve bigger than one box problems with them.

Perhaps my favorite lesson from his talk is this one (my gloss):

SOA + queues + async messaging is really powerful. This approach isolates components, lets work happen concurrently, lets boxes fail independently, while still having components be easy to reason about.

I also really like his explanation for why event style messages are better than command style messages. I’ve never heard it put that way before.

Sean talks from a place of authentic experience. If you are trying to make a jump from a single box mindset to a multibox way of thinking, this talk is well worth watching. 

So let’s see what Sean has to say about distributed systems...

Categories: Architecture

The 4 Levels of Freedom For Software Developers

Making the Complex Simple - John Sonmez - Mon, 07/14/2014 - 16:00

For quite some time now I’ve been putting together, in my mind, what I think are the four distinct levels that software developers can go through in trying to gain their “freedom.” For most of my software development career, when I worked for a company, as an employee, I had the dream of someday being […]

The post The 4 Levels of Freedom For Software Developers appeared first on Simple Programmer.

Categories: Programming