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

SPaMCAST 301- Technical Debt Essay

Software Process and Measurement Cast - Sun, 08/03/2014 - 22:00

Software Process and Measurement Cast number 301 features our essay on technical debt. Technical debt is the work not done or the shortcuts taken when delivering a product. We all take shortcuts, but at what cost? The essay begins:

Technical debt is a term coined by Ward Cunningham to represent the work not done or the shortcuts taken when delivering a product. In almost every circumstance there are multiple paths than can be taken to deliver a functional product.  For example, when documenting the code you are writing there is a difference between explaining exactly what the code does in detail and being terse and a bit oblique (I can hear the rationalization, “they can just read the code”). The code runs, but if there is ever a problem it will take longer to diagnose the problem. Whether fixing a defect or rewriting the code, if there is a delay caused by figuring out the code, that represents the 'debt' of technical debt.  Technical debt is applied to software, but the phrase can be extended to any deliverable or product.  The work that is not done may or may not be fixed in the future.  Until the technical debt is paid back, the debt accrues interest.  Whether or not that interest is important depends on your situation.

Listen to the rest on the Software Process and Measurement Cast 301

 

Next

Software Process and Measurement Cast number 302 will our interview with Larry Maccherone of Rally Software. We talked about Agile and metrics.  Can you combine Agile and metrics without creating an oxymoron?

Upcoming Events

I will be presenting at the International Conference on Software Quality and Test Management in San Diego, CA on October 1.  I have a great discount code!!!! Contact me if you are interested!

I will be presenting at the North East Quality Council 60th Conference October 21st and 22nd in Springfield, MA.

More on all of these great events in the near future! I look forward to seeing all SPaMCAST readers and listeners that attend these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

Categories: Process Management

How Employees Lost Empathy for their Work, for the Customer, and for the Final Product

“In most cases being a good boss means hiring talented people and then getting out of their way.” -- Tina Fey

The Digital Revolution marked the beginning of the Information Age.

The Information Age, or Digital Age, or New Media Age, is a shift away from the industrial revolution to an economy based on information computerization.  Some would say, along with this shift, we are now in a Knowledge Economy or a Digital Economy. 

This opens the door to new ways of working and a new world of work to generate new business value and customer impact.

But what did the Industrial Age do to employees and what paradigms could limit us in this new world?

In the book The Future of Management, Gary Hamel walks through how industrialization and large Enterprises have created a disconnect between employees and their customers, their final product, and the big financial picture.  And in the process, he argues, this had led to disengaged employees, crippled innovation, and inflexible organizations.

If you don’t know Gary Hamel, he’s been ranked the #1 influential business thinker by the Wall Street Journal.

According to Hamel, what we traded for scale and efficiencies created gaps between workers and employees and gaps between employees and their customers, the product, the financial impact, and … a diminished sense of responsibility for quality and efficiency.

Maybe We Have Managers Because We Have Employees

Do managers exist because employees do?

Via The Future of Management:

“Here's a thought.  Maybe we need 'managers' because we have 'employees.'  (Be patient, this is not as tautological as it sounds.)  Think about the way computers are dependent on software.  PCs aren't smart enough to write their own operating instructions, and they sit idle until a user sets them to work.  Perhaps the same is true for employees.”

Did We Manufacture a Need for Managers?

When we manufactured employees, did we manufacture a need for managers?

Via The Future of Management:

“Earlier, I talked about the invention of 'the employee.' What happened in this process, at the dawn of the 20th century?  How did work life change as individuals left their farms and workshops to be absorbed into large-scale organizations?  In manufacturing employees, did we manufacture a need for managers as well?  I think so.  If we understood how this came about, we will gain clues into how we might learn to manage without managers -- or, at least, with a lot fewer of them.”

Disconnected from the Customer

As the size and scale of industrial organizations grew, so did the disconnect between employees and their final customers.

Via The Future of Management:

“In pre-industrial times, farmers and artisans enjoyed an intimate relationship with their customers.  The feedback they received each day from their patrons was timely and unfiltered.  Yet as industrial organizations grew in size and scale, millions of employees found themselves disconnected from the final customer.  Robbed of direct feedback, they were compelled to rely on others who were closer to the customer to calibrate the effectiveness of their efforts and to tell them how they could better please their clients.”

A Diminished Sense of Responsibility for Producer Quality and Efficiency

Without a connection to the customer, employees lose empathy for their work, for the customer, and for the final product.

Via The Future of Management:

“As companies divided themselves into departments and functions, employees also became disconnected from the final product.  As tasks became narrower and more specialized, employees lost their emotional bond with the end product.  The result? A diminished sense of responsibility for producer quality and efficiency.  No longer were workers product craftsmen, now they were cogs in an industrial machine over which they had little control.”

Employees No Longer Have a System Wide View of the Production Process

It’s hard to make changes to the system when you no longer have a system wide view.

Via The Future of Management:

“Size and scale also separate employees from their coworkers.  Working in semi-isolated departments, they no longer had a system wide view of the production process.  If that system was suboptimal, they had no way of knowing it and now way of correcting it.”

The Gap Widens Between Workers and Owners

People at the top don’t hear from the people at the bottom.

Via The Future of Management:

“Industrialization also enlarged the gulf between workers and owners.  While a 19th-century apprentice would have had the ear of the proprietor, most 20th-century employees reported to low-level supervisors.  In a large enterprise a junior employee could work for decades and never have the chance to speak one-on-one with someone empowered to make important policy decisions.”

The Scoreboard is Contrived

Scoreboards tell employees how they are doing their jobs, but not how the company is doing overall.

Via The Future of Management:

“In addition, growing operational complexity fractured the information that was available to employees.  In a small proprietorship, the financial scoreboard was simple and real time; there was little mystery about how the firm was doing.  In a big industrial company, employees had a scoreboard but it was contrived.  It told workers how they were doing their jobs, but little about how the company was doing overall.  With no more than a knothole view of the company's financial model, and only a sliver of responsibility for results, it was difficult for an employee to feel a genuine burden for the company's performance.”

Industrialization Disconnects Employees from Their Own Creativity

Standardizing jobs and processes limits innovation in the jobs and processes.  They are at odds.

Via The Future of Management:

“Finally, and worst of all, industrialization disconnected employees from their own creativity.  In the industrial world, work methods and procedures were defined by experts and, once defined, were not easily altered.  No matter how creative an employee might be, the scope for exercising that gift was severely truncated.”

The Pursuit of Scale and Efficiency Advantages Disconnected Workers from Their Essential Inputs

With the disconnect between employees and their inputs, there was a natural need for the management class.

Via The Future of Management:

“To put it simply, the pursuit of scale and efficiency advantages disconnected workers from the essential inputs that had, in earlier times, allowed them to be (largely) self-managing -- and in so doing, it made the growth on an expansive managerial class inevitable.”

Employees Don’t Lack Wisdom and Experience

Employees don’t lack wisdom and experience.  They just lack information and context.

Via The Future of Management:

“To a large extent, employees need managers for the same reason 13-year-olds need parents: they are incapable of self-regulation.  Adolescents, with their hormone-addled brains and limited lie experience, lack the discernment to make consistently wise choices.  Employees on the other hand, aren't short of wisdom and experience, but they do lack information and context -- since they are so often disconnected from customers, associates, end products, owners, and the big financial picture.  Deprived of the ability to exercise control from within, employees must accept control from above.  The result: disaffection.  It turns out that employees enjoy being treated like 13-year-olds even less than 13-year-olds.”

Disengaged Employees, Hamstrung Innovation, and Inflexible Organizations

What is the result of all this disconnect?   Stifled innovation, rigid organizations, and disinterested employees.

Via The Future of Management:

“Disengaged employees.  Hamstrung innovation.  Inflexible organizations.  Although we are living in a new century, we are still plagued by the side effects of a management model that invented roughly a hundred years ago.  Yet history doesn't have to be destiny -- not if you are willing to go back and reassess the time-forgotten choices that so many others still take for granted.  With the benefit of hindsight, you can ask: How have circumstances changed? Are new approaches possible? Must we be bound by the shackles of the past?  These are essential questions for every management innovator.”

Does history have to be destiny?

We’re writing new chapters of history each and every day.

In all of my experience, where I’ve seen productivity thrive, people shine, and innovation unleashed, it’s when employees are connected with customers, they are empowered and encouraged to make changes to processes and products, and they are part of a learning organization with rapid feedback loops.

You Might Also Like

Ability to Execute

Business Value Generation is the New Bottleneck

Customer-Connected Development

How We Adhered to the Agile Manifesto on the Microsoft patterns & practices Team

Why So Many Ideas Die or Don’t Get Adopted

Categories: Architecture, Programming

Free ebook: Building Cloud Apps with Microsoft Azure

ScottGu's Blog - Scott Guthrie - Sun, 08/03/2014 - 03:20

9780735695658f Last week MS Press published a free ebook based on the Building Real-World Apps using Azure talks I gave at the NDC and TechEd conferences.  The talks + book walks through a patterns-based approach to building real world cloud solutions, and help make it easier to understand how to be successful with cloud development. Videos of the Talks You can watch a video recording of the talks I gave here:

 Part 1: Building Real World Cloud Apps with Azure

 Part 2: Building Real World Cloud Apps with Azure

eBook Downloads

You can now download a completely free PDF, Mobi or ePub version of the ebook based on the talks using the links below:

Download the PDF (6.35 MB)  

Download the EPUB file (12.3 MB)  

Download the Mobi for Kindle file (22.7 MB)

Hope this helps,

Scott

Categories: Architecture, Programming

Seven Deadly Sins of Metrics Programs: Pride

Can't see forest for the trees

Can’t see forest for the trees

The first deadly sin is pride. In the cannon of deadly sins, pride is the sin from which all other spring. In the world of metrics programs, the sin of pride is when a metrics program settles on a single metric that is used to reflect the value or well-being of a project, a group or organization. Examples of abound of metrics programs that fixated on cost or productivity to the exclusion of a broader palette of metrics and work attributes.  Most metrics professionals quickly learn that one metric cannot be used for all projects.  If you can’t easily answer the question, “Does this relate?” each time you use a metric and for each metric you use, the information generated through measurement and analysis will provide little or no value.  The goal is to understand the differences between groups of work so that when comparisons are made, you can discern what is driving the difference (or even if there is a difference).  Comparing package implementations, hardware intensive projects or custom development is rational only if you understand that there will be differences and what those differences mean.   The bottom line is that rarely does a single metric deliver that deep level of understanding that generates value from measurement.

Another example of the single metric syndrome generated by the sin of pride occurs when an organization uses a single metric to value performance in a contractual arrangement.  While entire contracts are rarely stipulated on a single metric, it easy for a single metric to be given disproportional weight due to the framers’ lack of understanding or a disconnect between the framers and the people that administer the contract.  Poor understanding of the relationship between the numbers and the concepts they represent is akin to failure in punctuation when writing.  The resulting meaning can be garbled as the contract is negotiated, implemented and managed.  We won’t get into an existential argument over whether something is a sin if it is inadvertent; the result is the same. Garbled concepts can lead to a single metric focus which once discovered will beg to be taken advantage of.  This usually causes an overemphasis on a specific portion of the value chain, such as productivity being emphasized over time-to-market, quality or cost.


Categories: Process Management

Code Golf

Phil Trelford's Array - Sat, 08/02/2014 - 19:22

Last month Grant Crofton popped down from Leeds to the F#unctional Londoners meetup at Skills Matter to run a fun hands on code golf session. The idea of code golf is to implement a specific algorithm in the fewest possible characters. This is not the kind of thing you should be doing in enterprise code, but it is fun, and an interesting way of exploring features in a programming language.

On the night we attempted condensed versions of FizzBuzz and 99 bottles of beer, with Ross and I winning the first challenge and Simon & Adrian the second.

FizzBuzz Score99 Bottles Score

Thanks again to Grant for a really fun session.

F# FizzBuzz

A while back I strived to squeeze an F# implementation of FizzBuzz into a tweet, and with white space removed it weighs in at 104 characters (excluding line breaks):

for n=1 to 100 do 
 printfn"%s"
  (match n%3,n%5 with 0,0->"FizzBuzz"|0,_->"Fizz"|_,0->"Buzz"|_,_->string n)

The implementation, although quite clear, requires a fair number of characters for the pattern matching portion.

After some head scratching we came up with the idea of using a lookup to select the string to display:

N %3 N % 5 Index Output 0 0 0 N >0 0 1 “Fizz” 0 >0 2 “Buzz” >0 >0 3 “FizzBuzz”

This took the implementation down to 89 characters (without line breaks):

for i=1 to 100 do
 printfn"%s"["FizzBuzz";"Buzz";"Fizz";string i].[sign(i%5)*2+sign(i%3)]

Another trick is to abuse the sign function, to get 1 if the result of the modulus is above 0 and 0 otherwise.

The lookup trick can be used in other languages, and here’s a few examples, just for fun.

VB.Net FizzBuzz

VB.Net has a reputation for being a little verbose, but using the lookup trick it was possible to it get down to 96 characters (excluding line breaks):

For i=1 To 100:
Console.WriteLine({i,"Fizz","Buzz","FizzBuzz"}(-(i Mod 3=0)-(i Mod 5=0)*2))
:Next

In VB.Net true values translate to –1 and false to 0. This allowed me to simply negate the result of i % N = 0 to compute an index.

Python FizzBuzz

Using a similar trick in Python, where true translates to 1 and 0 to false, I was able to get to a very respectable 79 characters (excluding line breaks):

for x in range(1,101):
 print([x,"Fizz","Buzz","FizzBuzz"][(x%3==0)+2*(x%5==0)])

Python’s simple print function also helped to keep the character count down.

Amanda FizzBuzz

Amanda is a variant of David Turner’s quintessential functional programming language Miranda. Amanda runs on Windows, and is used for teaching FP at some universities.

Using a list comprehension it was possible to squeeze in to a mere 67 characters:

[["FizzBuzz","Buzz","Fizz",itoa x]!(min[1,x%3]+min[1,x%5]*2)|x<-[1..100]]

Note: this is cheating a little as we are not explicitly writing to the console.

APL FizzBuzz

APL is a very mature language, dating back to the 1960s, and is still used commercially today. It also wins hands down in code golf with just 54 characters:

⍪{'FizzBuzz' 'Buzz' 'Fizz'⍵[1+(2×1⌊5|⍵)+1⌊3|⍵]}¨⍳100

APL is particularly strong at matrix processing and provides single character representations for common operations:

Notation Name MeaningB Index generator Creates a list from 1 to B ¨ Each for each loop ⍪ Table Produces a one column matrix ⌊B Floor Greatest integer less than or equal to B

Try APL in your browser now.

Challenge

Can you beat the APL implementation of FizzBuzz?

Have fun!

Categories: Programming

Seven Deadly Sins of Metrics Programs

3216110254_15d4a00bf2_b

In Christianity, the seven deadly sins are the root of all other sins. This concept has been used as an analogy for the ills or risks for many professions.  The analogy fits as well for software metrics; focusing attention on the behaviors that could sap your program’s integrity, effectiveness and lifespan. Here we will look at the deadly sins from the point of view of a person or group that is creating or managing a metrics program. As with many things in life, forewarned is forearmed, and knowledge is a step towards avoidance.

Here are the seven deadly sins of metrics programs:

  • Pride – Believing that a single number/metric is more important than any other factor.
  • Envy – Instituting measures that facilitate the insatiable desire for another team’s people, tools or applications.
  • Wrath – Using measures to create friction between groups or teams.
  • Sloth – Unwillingness to act on or care about the measures you create.
  • Greed – Allowing metrics to be used as a tool to game the system for gain.
  • Gluttony – Application of an excess of metrics.
  • Lust – Pursuit of the number rather than the business goal.

All of the deadly sins have an impact on the value a metrics program can deliver.  Whether anyone sin is more detrimental than another is often a reflection of where a metrics program is in it’s life cycle. For instance, pride, the belief that one number is more important than all other factors, is more detrimental than sloth or a lack of motivation as a program begins whereas sloth becomes more of an issue as a program matures.  These are two very different issues with two very different impacts, however neither should be sneezed at if you value the long-term health of a metrics program. Pride can lead to overestimating your capabilities and sloth can lead to not using those you have in the end self-knowledge is the greatest antidote.

Over the next few days we will visit the seven deadly sins of metrics!


Categories: Process Management

Can Enterprise Agile Be Bottom Up?

Herding Cats - Glen Alleman - Fri, 08/01/2014 - 20:48

Much of the objection to SAFe comes from its seemingly Top Down paradigm. Many agile voices object that this approach is not agile, in the way they define agile - individual teams making their own decisions about what to do with their customer.

The domain of this bottom up approach is usually not well defined, other than the classic eXtreme Programming or the Agile Spectrum of  where Co-Hacking is on the left, where the developers live by the pure agile manifesto. 

But what happens when agile is applied to an enterprise development effort. One where the business needs define the capabilities that are not emergent, but rather they are needed to fulfill the business strategy or the mission of the organization. Then another paradigm emerges. One where higher order questions, frameworks, framing assumptions, governance, and other externalities trump the needs of the individual team.

Here's one approach that has served us well over time. 

Critical Success Factors for ERP from Glen Alleman   So when we hear about critisms of SAFe like:
  • The structure and teaching of SAFe is relentlessly top down. All the important stuff is figured out up in Portfolio. All the features are figured out up in Program. Now you guys Build and Test that.

The  statement is a bit off, since it's the Capabilities that are defined by the business. These capabilities are then turned into requirements, which may in fact emerge, which themselves are turned into working software. Starting with the capabilities, an enterprise software development effort means re-looking at the agile manifesto statements.

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

    • It certaintly is the highest priority to satisfy the customer with valuable software.
    • The delivery in the enterprise needed to be planned at the absorption rate and business rhythm. 
    • The units of measure of value need to be connected to the business strategy. This is usually to role  of Balanced Scorecard, which defines the value in the 4 perspectives of the business. 
      • Financial
      • Customer
      • Internal business processes
      • Learning and Growth
      • Here's how to develop your BSC for enterprise software development.
    • Releasing software in the enterprise means integrating with the business processes, customer processes, product release process - all defined by the rhythm of how the business works
    • Imagine updating the point of sale terminals across 10,000 users on a daily basis, adding new features, changing possibly for the better how they work.
    • The training, Tier 1 support, transaction formatting, and other enterprise actiities woudl alos have to change.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

    • This is one of those untested statements.
    • Imagine changing how ICD-10 claims are processed late in the development cycle.
    • Other enterprise systems are based on ICD-10 formats, now they're changing as we approach "go live." 
    • We need look no further than the ACA roll out to see how nonsensical this is.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

    • For the enterprise, the business rhythm defines the frequency of software release. 
    • For example, the flight navigation systems for an aircraft have many other processes beyond just writing code. 
    • Full Information Assurance, DO-178 validation, Digital Flight Bag integration, PCI
    • For health care SP-600 for HIPPA verification and validation.
    • Or for the IT Enterprise ISACA.
    • Externalities drive business rhythm. Having the developers decide this rhythm ignores these externalities. If there are no externalities, then the project is likely perfect for the agile manifesto.
  • Business people and developers must work together daily throughout the project.

    • This works when the business people don't have day jobs.
    • If they have day jobs, some proxy of the needed capabilities, and requirements is needed.
    • This is the role of documentation and models. Both developed concurrently with developers and business people.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

    • Can't go wrong here.
    • Remember thought, trust but verify.
    • The value at risk needs to be considered. What happens if what the developers say turns out not to be the case. How much are you willing to risk that the trust was misplaced?
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

    • Back to the availability issue. 
    • Geography is another issue. Many teams are distributed.
    • Face to Face needs a proxy.
  • Working software is the primary measure of progress.

    • Correct, this is basis of Earned Value Management's Physical Percent Complete.
    • Working needs a definition. Measures of Effectiveness, Measures of Performance, Key Performance Parameters, Technical Performance Measures are all mechanisms to assess the workingness of the software in the enterprise domain.
  • Agile processes promote sustainable development. 

    • All work processes should be sustainable, nit just agile.
    • Knowing the capacity for work is the starting point.
    • This means not only knowing the capacity, but planning the work around this capacity with the needed margin to provide for sustainability.
  • The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

    • Yes, good business and engineering practice.
    • Requires capacity planning
    • Cost, Schedule, and Technical margin.
    • Measures of performance to make steering adjustment and needs a control system to connect the dots between the desired outcome, and actual performance, and the corrective actions needed to sustain this needed performance.
  • Continuous attention to technical excellence and good design enhances agility.

    • This is a platitude that is used in all engineering domains.
    • rarely if ever are product build with low technical excellence and good design practices.
    • Exactly how this enhances agility is untested outside of anecdotes.
    • But certainly changeability in response to external factors is measurable as robustness of the design.
  • Simplicity - the art of maximizing the amount of work not done - is essential.

    • Another platitude, without any actionable suggestions.
    • But what are the units of measure of simplicity.
    • Everyone should read Synthesis of Form, Christopher Alexander.
    • Then the practice for enterprise projects, The Art of Systems Architecting, 2nd Edition, Mark W. Maier and Eberhardt Rechtin.
    • And followed by Systems Engineering: Coping with Complexity, Richard Stevens, et al.
    • These three books address the platitude and replace it with actionable steps to maximize value produced with minimal work.
  • The best architectures, requirements, and designs emerge from self-organizing teams.

    • In the enterprise domain this is a non-starter.
    • Architecture is the glue to holds the systems integration together.
    • Emerging architectures means, all the other systems in the enterprise will be constantly changing as the architecture of the system under development changes.
    • Those self-organizing teams may or may not have the skills, experience, and even ability to be  systems architects.
    • Read the systems engineering books above. Join www.incose.org to learn how complex enterprise systems are defined, developed, deployed, and maintained.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

    • This is standard good engineering practice, not unique to agile.

So What Does All This Mean?

Without a domain, hard to assess the applicability and appropriateness of much of anything.

What this really means of Scaled Agile Framework is the place to start for the enterprise.

Related articles Agile Requires Discipline, In Fact Successful Projects Require Discipline Agile and the Federal Government The Agile Architecture Mind Map Capabilities Based Planning and Development Agile in the enterprise: To succeed, avoid the fundamentalists How To Create Confusion About Root Causes Agile Paradigm The Myth of Incremental Development An Agile Estimating Story Agile as a Systems Engineering Paradigm
Categories: Project Management

Stuff The Internet Says On Scalability For August 1st, 2014

Hey, it's HighScalability time:


From Systems Performance: Enterprise and the Cloud.
  • Quotable Quotes:
    • @shanselman: Wife: "How was your day?" Me: "I'm using Grunt to automate NuGet creation for AngularJS." Wife: "But will that scale?" Me: "Well played."
    • John Hagel: winners in the concentrating parts of the economy are increasingly determined by the ability to connect with, and build strong relationships with, the participants who are operating in fragmenting parts of the economy.
    • Jack Clark: This means that although Amazon still grew at a respectable rate, its actual revenues were clipped by the heightened competition. This is what happens when you sell goods with deflationary pricing, it seems.

  • Taxi app Hailo on Scaling micro-services Architecture on AWS: Micro-services + Containers + Scheduling on AWS will be a dominant architecture pattern in the next few years.

  • Netflix. Revisiting 1 Million Writes per second. How will Cassandra perform on AWS's new instance types? There's no big reveal so you'll have to decide for yourself. Good discussion on reddit and Hacker News.

  • TrueTime in Google's Spanner was one of its most buzzworthy innovations. Who doesn't like atomic clocks as a way to time-stamp transactions anywhere in the world? What if you don't have spare atomic clocks? Hybrid Logical Clocks: HLC captures the causality relationship like LC, and enables easy identification of consistent snapshots in distributed systems. Dually, HLC can be used in lieu of PT clocks since it maintains its logical clock to be always close to the PT clock.

  • Vertical integration for the win. Apple is building out their own CDN with many terabits of capacity. Capable of handling traffic bursts from software downloads. Or maybe something else? More from Dan Rayburn in Apple’s CDN Now Live: Has Paid Deals With ISPs, Massive Capacity In Place

  • Clouds make a lot of money on their network pricing. Chris Swan explores this marketing magic in Cloud Price Wars – What about the network?: there haven’t been any major shifts in network pricing.

  • Scaling with Microservices and Vertical Decomposition: The architecture of otto.de is based on the concept of vertical decomposition: the whole system is vertically split into several loosely coupled applications. Every “vertical” is responsible for a single business domain such as “Order”, “Search & Navigation”, “Product”, etc. It has its own presentation layer, persistence layer and a separate database. From the development perspective, every vertical is implemented by exactly one team and no code is shared between the different systems.

Don't miss all that the Internet has to say on Scalability, click below and become eventually consistent with all scalability knowledge (which means this post has many more items to read so please keep on reading)...

Categories: Architecture

Playing around with Yo

Xebia Blog - Fri, 08/01/2014 - 13:09

Yo has been quite a bit in the news lately. Mainly because it got a lot of investment, which surprised and shocked some people because it all seems too simple. Yo only allows you to send a Yo notification to other users. However, it has a lot of potential to become big while staying that simple.

Screenshot 2014-08-01 14.23.48

After reading Why A Stupid App Like Yo May Have Billion-Dollar Platform Potential a few days ago I felt it was time to play around a bit with Yo and it's API.

I came up with 3 very simple use cases that should be simple to solve with Yo:

  • Get a Yo when it's time to have lunch when I'm at work
  • Get a Yo when I forgot to check out from my parking App
  • Get a Yo when a new blog post is published here on the Xebia Blog

Time to register a couple of Yo developer usernames. The Yo API is, just like Yo itself, very simple. You register a username from which you want to receive notifications at http://yoapi.justyo.co after which you'll receive an API token for that username. Once you have that, people can subscribe to that username with the Yo app. Then you can send a Yo to either all subscribers or to a single subscribe with a simple POST request and the token. All this is explained at https://medium.com/@YoAppStatus/e7f2f0ec5c3c in more detail.

Let's start with our lunch notifications. I created the TIME2LUNCH username for this. I want my notifications at 12:00pm, since that's the time I go to lunch. So all I need is some service that sends the POST request every day at 12:00pm (for now I don't care about getting one in the weekend as well and I only care about my own time zone, Central European Time). Using NodeJS, it's just a single line of code to do such a request:

require('request')
  .post('http://api.justyo.co/yoall/', 
    {
      form: {api_token: 'my_secret_api_token'}
    }
  );

Now we need to have a scheduler that executes it every day at 12:00pm. Luckily Heroku has a scheduler that can do exactly that:

Screenshot 2014-07-31 17.43.51

So after deploying our javascript file with a single line of code and creating our scheduled job we will receive our daily Yo from TIME2LUNCH. Not bad for a first attempt.

Usually my co-workers will remind me when it's time to go to lunch so let's do something that's actually a bit less useless.

To park my car near the office I always use the Parkmobile service. At the end of the day I have to check out to avoid paying too much. Unfortunately it's an easy thing to forget. Parkmobile knows this and can send sms alerts at a specific time or after parking a certain amount of hours. Unfortunately they charge € 0.25 per sms. They also send e-mails, but they're easier to miss. It would be nice to get a Yo instead, for free of course.

What we need is to send the Yo POST request each time we receive the Parkmobile e-mails. Sounds like we might be able to use IFTTT (if this then that) to accomplish this. When browsing for channels and recipes on IFTTT I saw that they already support Yo as a channel. I thought I was gonna be done fast. Unfortunately it's only possible to use Yo as a trigger (if Yo then that) and not as an action (if this then Yo). So we need another solution here. I couldn't find a way to send a cURL request directly from IFTTT, but when Googling for a solution I found a webhook project: https://github.com/captn3m0/ifttt-webhook. The ifttt-webhook works by acting as a WordPress site, which is something that can act as an action of IFTTT. It then allows us to send a POST request to a specific URL. Not exactly the POST requests that are accepted by the Yo API though. But we already made some NodeJS code to send a Yo request so I'm sure we can add some code to accept a request from the ifttt-webhook and then pass it on to something that Yo does understand.

If we follow the instructions on the Github page and set our username to our Yo username and use our API token as password, then the webhook will send a POST request with a JSON body that looks something like this:

{ user: 'MYUSERNAME', pass: 'ab1234-1234-abcd-1234-abcd1234abcd', title: '' }

We can handle that in NodeJS like this:

var express = require('express');
var bodyParser = require('body-parser')
var app = express();
var request = require('request');

app.use(bodyParser.json());
app.post('/api/yo', function (req, res) {
  var user = req.body.user;
  var apiToken = req.body.pass;
  request.post('http://api.justyo.co/yo/',
    {
      form: {
        api_token: apiToken,
        username: user
      }
    });
});

var port = Number(process.env.PORT || 5000);
app.listen(port, function() {
  console.log('Listening on ' + port);
});

This is just a simple express web server that listens for POST calls on /api/yo and then uses the user and pass fields from the body to send a POST request to the Yo API.

This is deployed at http://youser.herokuapp.com/ so everyone can use it as a IFTTT to Yo action.

We can now create our IFTTT recipe. Creating the this step is easy. I receive the e-mails from Parkmobile in my Gmail and their e-mail address is norepy@parkmobile.com. So the rule becomes to trigger each time when I receive an email from them. Then in the that step I activate the WordPress channel with the Yo username and api token and in the body I set the http://youser.herokuapp.com/api/yo URL.

Here is the recipe:

Screenshot 2014-07-31 18.32.12

The last use case I had is to send a Yo each time a new blog post was posted on this blog. For that I registered the XEBIABLOG username (so make sure to subscribe to that in your Yo app if you want to get Yo'd as well for each new blog post).

Since this blog has an RSS feed, I figured I could poll that once in a while to check for new posts. We also already used the Heroku scheduler, so we might as well use that again. I found a little node library called feed-read that makes reading RSS feeds easy. So here is our little app that runs every hour:

var feed = require("feed-read");
var request = require('request');
var ONE_HOUR = 60 * 60 * 1000;

feed("http://blog.xebia.com/feed/", function(err, articles) {
  if (err) throw err;

  var lastArticle = articles[0];
  if ((new Date() - lastArticle.published) < ONE_HOUR) {
    console.log('Sending Yo for ' + lastArticle.title);
    request.post('http://api.justyo.co/yoall/',
      {
        form: {
          api_token: 'my_secret_token'
        }
      });
  }
});

We now have completed our 3 little use cases. Not the most useful things but nice non nonetheless. When looking back on them, we can imagine a couple of improvements. For example for the TIME2LUNCH it would be possible to make a little service where people could register and set their timezone at which they want to receive their notification. We could create a little database that store Yo usernames and the zone. But at this moment it's not possible to verify that USERX is really USERX. Yo doesn't support third party authentication like Facebook and Twitter have with OAuth. Perhaps that's something they will add in the future to make platform more useable for user specific notifications.

13 Business Models for Book Authors

NOOP.NL - Jurgen Appelo - Fri, 08/01/2014 - 11:03
Business Models for Book Authors

It’s such a great time to write books!

The publishing world is transforming rapidly and smart authors–with a sense of business–will thrive on opportunities that didn’t exist until a few years ago.

It appears that almost one-third of all e-books sold on Amazon are published by indie authors. This is great news for everyone who loves freedom and independence (including yours truly). On the other hand, income for book writers seems to be declining steadily. This will only get worse now that Amazon has started offering subscriptions to read unlimited numbers of e-books, thereby moving in the same direction as Netflix (for movies) and Spotify (for music), further reducing the income for authors along the way.

The post 13 Business Models for Book Authors appeared first on NOOP.NL.

Categories: Project Management

Learn How UX Design can Make Your App More Successful

Android Developers Blog - Fri, 08/01/2014 - 02:39

By Nazmul Idris, a Developer Advocate at Google who's passionate about Android and UX design

As a mobile developer, how do you create 5-star apps that your users will not just download, but love to use every single day? How do you get your app noticed, and how do you drive engagement? One way is to focus on excellence in design — from visual and interaction design to user research, in other words: UX design.

If you’re new to the world of UX design but want to embrace it to improve your apps, we've created a new online course just for you. The UX Design for Mobile Developers course teaches you how to put your designer hat on, in addition to your developer hat, as you think about your apps' ideal user and how to meet their needs.

The course is divided into a series of lessons, each of which gives you practical takeaways that you can apply immediately to start seeing the benefits of good UX design.

Without jargon or buzzwords, the course teaches you where you should focus your attention, to bring in new users, keep existing users engaged, and increase your app's ratings. You'll learn how to optimize your app, rather than optimizing login/signup forms, and how to use low-resolution wireframing.

After you take the course, you'll "level up" from being an excellent developer to becoming an excellent design-minded developer.

Check out the video below to get a taste of what the course is like, and click through this short deck for an overview of the learning plan.

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.

If that’s not enough, for even more about UX design from a developer's perspective, check out our YouTube UXD series, on the AndroidDevelopers channel: http://bit.ly/uxdplaylist.


Android Developers
at Udacity

Join the discussion on
+Android Developers


Categories: Programming

Agile 2014: My Retrospective

photo

The Agile 2014 Conference is much like a symphony with many individual movements that form a whole, like the Agile movement in general. 4 of the 5 days included 15 planned tracks with at least 4 presentations per track (Friday has a much smaller number of presentations). The variety of presentations and topics reflected the range of related, but different movements classified as Agile. Topics ranged from the social sciences of psychology and sociology targeted at coaching teams and organizational change to highly technically topics such as pair programming and DevOps.  The conference attracted 3,000+ attendees and speakers. For anyone interested in Agile this is conference that not allows but almost insists on an Agile immersion experience.

Several attendees that have attended in years past suggested that this year’s attendees reflect a subtle shift. There were more decision-makers than developers/practitioners in attendance. The theme of scaled Agile was also more prevalent than in past years.

Many of the early Agile thinkers were in attendance and involved not only in presenting, but shaping the conference. None of the early thinkers have lost their particular fire. For example, one speaker from this cohort publicly lamented that sponsors were monetizing the conference. Ken Schwaber even suggested turning the branded lanyards over to hide the branding. From my perspective, picking on the vendors is an easy target that could have negative consequences. The vibrant vendor community present was a positive and provided the sponsorship needed to hold great special events that made the conference more than just a fire hose of information. Agile 2014 was also a social experience.

If continual presentations and interactive workshops are not to your liking, there were plenty of less structured events. The conference had constant hallways talks, lean coffees every morning, Open Jams, coaching clinics and space provided for one-on-one conversations. There was no shortage of ideas, nor any shortage of space to discuss those ideas outside of the formal agenda.

This conference is large enough to hit some of your important topics one day and then to explore topics outside of your comfort zone the next and then have time to switch back and forth on the third, fourth or fifth days. I overhead folks discussing an interesting strategy; spending a day attending sessions that were exactly opposite of those you would typically attend to make sure you were exposed to new ideas.

Conversations with in the hall suggest that attendees that have been part of the Agile movement for more than a few years feel that innovation experimentation by Agile practitioners is slowing.  That the cycle of inspecting how Agile practices are performed by organizations and teams are being codified and in some cases being practiced as cannon and orthodoxy.  Hallway conversations suggest that the hardening of the rules that some groups are exhibiting is being noticed.  Leading voices are beginning to reemphasize learning and experimentation. One of the reflections of the slowing in evolution of Agile  is a suggestion from a few people that I chatted with that unless you are new or in the business of Agile consulting that attending the conference every two years and reading blogs is enough to keep current. I am not convinced that this suggestion is 100% accurate yet but it maybe soon unless innovation accelerates again.

There were very few negatives.  One downside worth mentioning was that many speakers that I went to see ran out of time. It seemed almost a badge of honor for speakers to announce they were out of time even though they were not done with the material they intended to cover. This included one of the two keynote speakers. Many of the offending parties I would consider professional speakers and know better. Not the end of the world, the ones I really want to know the rest of the story I will track down and interview on the podcast.

As Ernest Hemingway said, “It is good to have an end to journey toward; but it is the journey that matters, in the end.” Agile 2014 is part of my journey of enlightenment.


Categories: Process Management

All Project Work is Probabilistic Work

Herding Cats - Glen Alleman - Thu, 07/31/2014 - 23:55

When we hear about new and possibly innovative ways of improving the probability of success of project work, ask this simple question...

How Do I Make Your Suggestion Actionable on My Project?

With the answer to that question in some unit of measure meanigful to the decision maker (you), the suggestion may be an interesting personal ancedote or observation, but it is not actionable. Let's start with a notion that we can determine what needs to be done to deliver value to the customer. Here's a typical agile view of what Done looks like. More formal descriptions can be found in Intergated Master Schedules or other planning tools, but the Scrum approach is a good start.

Project-kanban-004

So there are a few questions:

  • What's the capacity for work of the team?
  • What's the actual probability each of those stories can be completed in the planned sprint, for the planned release, inside the planned Epic, so the customer start to book the value on the balance sheet to start earning back the cost of that development?
  • What's the estimated cost of all those stories and features, so the customer can be assured the inverstment of the all-on project cost will be earned back on or before the planned break even date for the project?

If we don't have the answers to these questions and others, I'd suggest we're in the co-hacking mode according to Guy Strelitz, where we don't really care about the questions above. If that's your domain, what follows is of little value.

But if your customer is not in the co-hacking domain, there is likely a need to know the answers to the five immutable principles of project success:

  1. What does done look like?
  2. What's the plan to get to done?
  3. Do we have all the resources neded to reach done as planned?
  4. What impediments will we encounter along the way to done and how are we going to handle them?
  5. How are we going to measure physical progress to plan?

The answers to each of these needs to be in units of measure meanigful to the dedcision maker. Without these answers, the probability of success is going to be low.

Related articles 5 Questions That Need Answers for Project Success Can Agile Be Integrated with Governance Based Development Processes? We Can Know the Business Value of What We Build Fit for Purpose, Fit for Use
Categories: Project Management

Grow with Google Play: Scaled Publishing and New App Insights

Android Developers Blog - Thu, 07/31/2014 - 23:55

By Kobi Glick, Google Play team

If you're growing your business on Google Play, the Google Play Developer Console is one of the most important tools at your disposal. At Google I/O, we introduced a number of new changes that give you valuable insight into how your app is performing. Here's an overview of some of the improvements you can now take advantage of.

Publishing API for scaling your app operations

Today we're happy to announce that the Google Play Developer Publishing API is now available to all developers. The API will let you upload APKs to Beta testing, Staged rollout and Production, and integrate publishing operations with your release processes and toolchain. The Publishing API also makes it easier for you to manage your in-app products catalog, provide tablet-specific screenshots, and localize your store listing text and graphics. The Publishing API will help you focus on your core business, with less time managing your releases, even as your business grows to more apps and markets.

Actionable insights at the right time Email notifications for alerts

Recently, we added Alerts in the Developer Console to let you know when there are sudden changes in important stats like app installs, ratings, and crashes. You can now turn on email notifications for Alerts so that, even while you’re not in the Developer Console, you’ll be informed of relevant events before they can have a broader effect on your app. You can turn on email notifications for one or more of your apps under Email Preferences in the Developer Console settings.

New Optimization Tips

You’ll now see new Optimization Tips with instructions when we detect opportunities to improve your app. For example, we’ll let you know when updated versions of APIs you use are available — such as new Google Play in-app billing or Google Maps APIs. For games developers, we’ll also surface opportunities to use Google Play game services that can help improve users’ gaming experience and drive engagement. To see what tips we suggest for you, go to your app in the Developer Console and click on Optimization Tips.

Better data to inform your business decisions Enhanced revenue statistics

To help you better understand your commercial success, we’ve enhanced revenue statistics in the Finance section of the Developer Console. We now let you see the average revenue per paying user (ARPPU) and give you more ways to analyse buyer data, such as comparing returning buyers (i.e., those who also made purchases in the past) to new buyers.

Bulk export of reviews

You can already engage with your users by reading and replying to reviews in the Developer Console and we’ve now added bulk export of reviews so you can download and analyze your app’s reviews en masse. This is particularly useful if you receive a large volume of reviews and want to perform your own sentiment analysis.

Improved stats for beta releases and staged rollouts

Since last year’s launch, you’ve used beta testing to release alpha and beta versions of your app, and staged rollout to gradually launch your app to production. To help you make the most of this feature, we’re now improving the way alpha, beta and staged rollout specific stats are displayed. When viewing your app and crash statistics you can now filter the app version by alpha, beta, or staged rollout to better understand the impact of your testing.

Improved reporting of native crashes

If you develop in native code, we’ve improved the reporting and presentation specifically for native crashes, with better grouping of similar crashes and summarizing of relevant information.

Deep-linking to help drive engagement

Finally, we’ve also added website verification in the Developer Console, to enable deep-linking to your app from search results. Deep-linking helps remind users about the apps they already have. It is available through search for all apps that implement app indexing. For example, if a user with the Walmart Android app searches for “Chromecast where to buy”, they’ll go directly to the Chromecast page in the Walmart app. The new App Indexing API is now open to all Android developers, globally. Get started now.

We hope you find these features useful and take advantage of them so that you can continue to grow your user base and improve your users’ experience. If you're interested in some other great tools for distributing your apps, check out this blog post, or any of the sessions which have now been posted to the Google Developers Channel.
Join the discussion on
+Android Developers


Categories: Programming

Testing on the Toilet: Don't Put Logic in Tests

Google Testing Blog - Thu, 07/31/2014 - 17:59
by Erik Kuefler

This article was adapted from a Google Testing on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office.

Programming languages give us a lot of expressive power. Concepts like operators and conditionals are important tools that allow us to write programs that handle a wide range of inputs. But this flexibility comes at the cost of increased complexity, which makes our programs harder to understand.

Unlike production code, simplicity is more important than flexibility in tests. Most unit tests verify that a single, known input produces a single, known output. Tests can avoid complexity by stating their inputs and outputs directly rather than computing them. Otherwise it's easy for tests to develop their own bugs.

Let's take a look at a simple example. Does this test look correct to you?

@Test public void shouldNavigateToPhotosPage() {
String baseUrl = "http://plus.google.com/";
Navigator nav = new Navigator(baseUrl);
nav.goToPhotosPage();
assertEquals(baseUrl + "/u/0/photos", nav.getCurrentUrl());
}

The author is trying to avoid duplication by storing a shared prefix in a variable. Performing a single string concatenation doesn't seem too bad, but what happens if we simplify the test by inlining the variable?

@Test public void shouldNavigateToPhotosPage() {
Navigator nav = new Navigator("http://plus.google.com/");
nav.goToPhotosPage();
assertEquals("http://plus.google.com//u/0/photos", nav.getCurrentUrl()); // Oops!
}

After eliminating the unnecessary computation from the test, the bug is obvious—we're expecting two slashes in the URL! This test will either fail or (even worse) incorrectly pass if the production code has the same bug. We never would have written this if we stated our inputs and outputs directly instead of trying to compute them. And this is a very simple example—when a test adds more operators or includes loops and conditionals, it becomes increasingly difficult to be confident that it is correct.

Another way of saying this is that, whereas production code describes a general strategy for computing outputs given inputs, tests are concrete examples of input/output pairs (where output might include side effects like verifying interactions with other classes). It's usually easy to tell whether an input/output pair is correct or not, even if the logic required to compute it is very complex. For instance, it's hard to picture the exact DOM that would be created by a Javascript function for a given server response. So the ideal test for such a function would just compare against a string containing the expected output HTML.

When tests do need their own logic, such logic should often be moved out of the test bodies and into utilities and helper functions. Since such helpers can get quite complex, it's usually a good idea for any nontrivial test utility to have its own tests.

Categories: Testing & QA

Data Flow Diagram (DFD) Tutorial: Texas Hold ‘Em

Software Requirements Blog - Seilevel.com - Thu, 07/31/2014 - 17:11
The data flow diagram is a useful, low-level data model that can show how data is transformed and manipulated through processes. This model does NOT show decisions, nor does it show a sequence of processes. This tutorial will take a commonly understood real-world scenario, a round of Texas Hold ‘Em, and provide step-by-step instructions for […]
Categories: Requirements

Paper: ZooKeeper: Wait-free coordination for Internet-scale systems

Do you really need to roll your own? ZooKeeper: Wait-free coordination for Internet-scale systems: In this paper, we describe ZooKeeper, a service for coordinating processes of distributed applications. Since ZooKeeper is part of critical infrastructure, ZooKeeper aims to provide a simple and high performance kernel for building more complex coordination primitives at the client. It incorporates elements from group messaging, shared registers, and distributed lock services in a replicated, centralized service. The interface exposed by Zoo-Keeper has the wait-free aspects of shared registers with an event-driven mechanism similar to cache invalidations of distributed file systems to provide a simple, yet powerful coordination service.

 

The ZooKeeper interface enables a high-performance service implementation. In addition to the wait-free property, ZooKeeper provides a per client guarantee of FIFO execution of requests and linearizability for all requests that change the ZooKeeper state. These design decisions enable the implementation of a high performance processing pipeline with read requests being satisfied byvlocal servers. We show for the target workloads, 2:1 to 100:1 read to write ratio, that ZooKeeper can handle tens to hundreds of thousands of transactions per second. This performance allows ZooKeeper to be used extensively by client applications.

ZooKeeper achieves throughput values of hundreds of thousands of operations per second for read-dominant workloads by using fast reads with watches, both of which served by local replicas. Although our consistency guarantees for reads and watches appear to be weak, we have shown with our use cases that this combination allows us to implement efficient and sophisticated coordination protocols at the client even though reads are not precedence-ordered and the implementation of data objects is wait-free. The wait-free property has proved to be essential for high performance.

Although we have described only a few applications, there are many others using ZooKeeper. We believe such a success is due to its simple interface and the powerful abstractions that one can implement through this interface. Further, because of the high-throughput of ZooKeeper, applications can make extensive use of it, not only course-grained locking.

Related Articles
Categories: Architecture

Quote of the Day

Herding Cats - Glen Alleman - Thu, 07/31/2014 - 15:31

“Everything has been said before, but since nobody listens we have to keep going back and beginning all over again.” — Andre Gide 1869–1951

It worth repeating, Rudyard Kipling’s Six Trusted Friends

  • What – to do?
  • When – to do it?
  • Where – is it appropriate to do it?
  • Who – should do it?
  • How – to do it?
  • Why – should we do it?

If you're looking for a set of phrases useful for all project work, these are them. Ask them, repeat them, don't take I don't know for an answer.

Related articles Making Improvements Requires Discipline The Calculus of Writing Software for Money
Categories: Project Management

What Is The Difference Between A Schedule and A Plan?

A schedule is not a plan but a plan might have a schedule in it!

A schedule is not a plan but a plan might have a schedule in it!

The first two organizations I worked for called the project schedule the ‘project plan’. A little later when I went to work for an organization that approached project management more formally, I was initially confused when a Gantt chart stopped being a project plan and my trusty plan was replaced by a document indicating how things would be approached rather than what would be done. I still occasionally conflate the concept of a project schedule with a project plan. While the two tools are related, they are different and serve different purposes.

A project plan is a deliverable used to document planning assumptions and as a vehicle to communicate the approved of scope, cost and schedule. Some form of a schedule is typically included in the plan. Inclusion of an early schedule establishes a link between the two deliverables. The Project Management Institute (PMI) indicates that the project plan is a formal, approved document. Formal project plans can include a wide array of sub-plans, including a risk management plan, quality plan or communication plan. Formal, classic project plans can be quite significant documents requiring a lot of effort to prepare. A plan and all of the sub-plans provide a platform for a project manager and stakeholders to develop a common understanding of how a project will be approached and establish roles. Many Agile projects use the Agile Team Charter to set expectations for how the project will be approached at the team level.

A cautionary note: writing and getting a plan signed-off does not ensure that all parties have developed a common understanding. Interaction and conversation are critical steps to developing a common language for the project.

Project schedules come in many forms ranging from simple approaches, such activity lists and time tables, to highly complex forms that include task network-based schedules and Critical Path Methods (CPM). A common thread in most schedules is that features, tasks and activities (or some subset) are documented and connected as a tool to guide the team and communicate progress. Agile teams use prioritized backlogs and release plans as schedules and while other methods use techniques such as milestone charts, task lists, Gantt chats and/or CPM (this only scratches the surface). Schedules act as tools to guide activities in a project, to answer the “when” questions and to help answer the “how much will this cost” questions.

Plans are a mechanism to help teams and project leaders consider how the project will be approached, to define roles and to begin to establish a common understanding between everyone involved. Project schedules reflect how the work will get done and when it will get done. Schedules reflect tactical planning, while plans take a more strategic view. Like planning, all projects use some form of scheduling technique. Team charters, backlogs, release plans, iteration backlogs, task lists or Kanban boards or project plan documents and detailed project schedules, reflect the difference in our approach and philosophy.


Categories: Process Management

Google I/O 2014 App Source Code Now Available

Android Developers Blog - Wed, 07/30/2014 - 22:24

By Bruno Oliveira, Tech Lead of the I/O app project

The source code for the 2014 version of the Google I/O app is now available. Since its first release on Google Play a few weeks before the conference, the I/O app was downloaded by hundreds of thousands of people, including on-site attendees, I/O Extended event participants and users tuning in from home. If one of the goals of the app is to be useful to conference attendees, the other primary goal is to serve as a practical example of best practices for Android app design and development.

In addition to showing how to implement a wide variety of features that are useful for most Android apps, such as Fragments, Loaders, Services, Broadcast Receivers, alarms, notifications, SQLite databases, Content Providers, Action Bar and the Navigation Drawer, the I/O app source code also shows how to integrate with several Google products and services, from the Google Drive API to Google Cloud Messaging. It uses the material design approach, the Android L Preview APIs and full Android Wear integration with a packaged wearable app for sending session feedback.

To simplify the process of reusing and customizing the source code to build apps for other conferences, we rewrote the entire sync adapter to work with plain JSON files instead of requiring a server with a specific API. These files can be hosted on any web server of the developer's choice, and their format is fully documented.

Storing and syncing the user's data (that is, the personalized schedule) is crucial part of the app. The source code shows how user data can be stored in the Application Data folder of the user's own Google Drive account and kept in sync across multiple devices, and how to use Google Cloud Messaging to trigger syncs when necessary to ensure the data is always fresh.

The project includes the source code to the App Engine app that can be reused to send GCM messages to devices to trigger syncs, as well as a module (called Updater) that can be adapted to read conference data from other backends to produce the JSON files that are consumed by the I/O app.

We are excited to share this source code with the developer community today, and we hope it will serve as a learning tool, a source of reusable snippets and a useful example of Android app development in general. In the coming weeks we will post a few technical articles with more detailed information about the IOSched source code to help bring some insight into the app development process. We will continue to update the app in the coming months, and as always, your pull requests are very welcome!


Join the discussion on
+Android Developers


Categories: Programming