Warning: Table './devblogsdb/cache_page' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_page WHERE cid = 'http://www.softdevblogs.com/?q=aggregator&page=3' in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc on line 135

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 729

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 730

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 731

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 732
Software Development Blogs: Programming, Software Testing, Agile, Project Management
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
warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/common.inc on line 153.

SE-Radio Episode 267: J√ľrgen H√∂ller on Reactive Spring and Spring 5.0

Eberhard Wolff talks with J√ľrgen H√∂ller about Reactive Spring. Reactive programming is a hot topic, but adoption has been slow in the enterprise. Spring 5 incorporates Reactor and the RxJava API to help Java developers build scalable high-performance web applications. The discussion explores architectural challenges, transactions, porting existing applications, and increased code complexity. Venue GOTOcon […]
Categories: Programming

SE-Radio Episode 267: J√ľrgen H√∂ller on Reactive Spring and Spring 5.0

Eberhard Wolff talks with J√ľrgen H√∂ller about Reactive Spring. Reactive programming is a hot topic, but adoption has been slow in the enterprise. Spring 5 incorporates Reactor and the RxJava API to help Java developers build scalable high-performance web applications. The discussion explores architectural challenges, transactions, porting existing applications, and increased code complexity. Venue GOTOcon […]
Categories: Programming

Making Decisions in the Presence of Uncertainty

Herding Cats - Glen Alleman - Tue, 09/06/2016 - 16:49

All project work is uncertain. This uncertainty comes in two forms - Aleatory and Epistemic. Aleatory Uncertainty is irreducible, Epistemic uncertainty is reducible. More can be found on this in Both Aleatory and Epistemic Uncertainty Create Risk. 

But now what to do about it. Here's a collection of papers that has served me well in defining the processes needed to make decisions in the presence of uncertainty when managing projects using other people's money:

So when you hear about making decisions in the presence of uncertainty without estimating the outcomes of those decisions, you'll have a basis of knowledge to realize that is completely bogus, a violation of the principles of microeconomics, and a violation of the principles of managerial finance. 

 

Categories: Project Management

What Is a Product?

Mike Cohn's Blog - Tue, 09/06/2016 - 15:00

If you work on a Scrum team, you undoubtedly know you should have a product backlog and product owner. But what, exactly, is a product?

For some teams, this can be a rather fundamental question. After all, an organization cannot identify appropriate product owners, teams and roles without first knowing what its products are. And if there is to be one product backlog per product, we need to know what our products are before creating a product backlog for each.

In most cases, it would seem straightforward to identify an organization’s products. For example, a watch manufacturer might think of each item they sell as a product. But even that could be oversimplifying things. And, some organizations have a much harder time identifying products.

What Are an Airline’s Products?

Take for example, an airline. A few years back, I was doing some work with an airline when the question of what is a product came up. Some people in the company argued that an airline does only one thing: move people from one location to another. They argued, therefore, that despite the company having over 40,000 employees, there should be only one product.

Others argued that there were many products within the airline. For example, they had a passenger-facing website that could be used to do things like make reservations, check in for a flight or check a flight’s status. They also had a system for monitoring and scheduling aircraft maintenance. And another that allowed crew members to select the flights they wished to work based on seniority.

Were these also products?

A Definition of Product and Examples

I define a product as something (physical or not) that is created through a process and that provides benefits to a market.

From that, a chair would be a product. Microsoft Office would be a product. Agile consulting services would be a product. A painting would be a product. A product can be a something physical (the chair). It can be a digital product (Microsoft Office, an ebook or streaming videos). It also can be a service (consulting on how to adopt agile).

A product can even just be an idea (a patentable algorithm or the secret to getting more right swipes on Tinder).

Each of these is created through a process or, more generally, one or more activities. Someone milled and assembled the chair. Microsoft Office was designed, coded and tested. The process that creates a product does not need to be formal or defined. The creators may not even be aware of the process. But some form of activity goes into creating every product.

Products Can Be Defined Recursively

A product can exist within another product. A pen, for example, may have replaceable ink cartridges. The pen is a product. But so are the ink cartridges within the pen.

There are even subproducts within a chair. The company manufacturing and selling the chair may have purchased fully milled legs from another company. Chair legs would then be a product.

Products can be defined recursively. A lumber company harvested trees to make wood—a product in its own right. Next, a milling company used that wood to make chair legs. Another company then took those pre-milled chair legs, and used them to assemble chairs of their own design. So products can exist inside other products.

Products Provide Benefits to a Market

When we identify subproducts within a larger product, we need to be careful that each subproduct provides benefits to a market. The definition above does not say that something must be purchased for it to be a product. But, to be considered a product, the item must satisfy a need or desire.

This is true of pre-milled legs for a chair and replacement ink cartridges for a pen. When defining products--and, therefore, product owners and product backlogs in Scrum--it will be important to define each product such that it provides benefits to a market.

Applying this Definition to the Airline Example

So if products are created through some process and benefit some market, are software components products?

To help answer that question, consider the airline company example from earlier. How would knowing that a product is something that is created through a process and that provides benefits to a market help an airline company identify its products?

First of all, it is easy to see that transporting people from one place to another is a product. That activity provides value to a market of people who gladly pay for the ability to fly to a location.

But what about the system for monitoring and scheduling aircraft maintenance? I claim that, too, is a product.

It is created through a process and is also something that provides benefits to a market. What market?

Well, we could go all the way and say that passengers benefit from well-maintained and safe aircraft. But, even closer to the product’s development, we can say that the airline employees benefit from having maintenance monitoring and scheduling computerized rather than needing to do that manually with paper.

The same could be said of the airline’s website, which enables passengers to make flight reservations. There is a market for that.

So, yes our airline has one big product—and it also has many subproducts. Anything within that company that can be thought of as delivering value to a market is a product.

Applying this Definition to Software Components

With that in mind, consider a software component. If one team develops software used by other teams, can that be thought of as a product? Consider the example of a team building a calendar widget. It provides value to a market: the other teams that will use the widget. I would say, then, that a component built for multiple teams is a product.

I would draw the line, though, with a calendar widget (or any component) that is used by only one team. Yes, technically a market can exist with only one customer. A painting, for example, is sold to one person.

But, when talking about product development (as with agile), it can be dangerous to think of something as a product if it is used by only one person or group. It could lead, for example, to thinking of code as a product that is delivered to a market of testers. That is not only a step backward into sequential (or phased) development, it’s also a form of suboptimization.

Avoiding Suboptimizing Products

According to San Jose State University Economics professor Thayer Watkins, suboptimization “refers to the practice of focusing on one component of a total and making changes intended to improve that one component … ignoring the effects on the other components.”

While organizations do want to define all of their products in order to best manage the work, they do not want to narrow their focus to the degree that they fail to see the whole because they are fixated on the individual parts. As such, organizations want to define each product as broadly as possible.

That being said, as we saw earlier with the airline company, there is such a thing as too broad when it comes to identifying products. When a product is so large that it serves multiple markets, I often prefer to think of it as multiple products each serving a unique market.

For example, it would be quite easy to think of Microsoft Office as a single product. Yet, Office is a suite of products, each providing different features and serving slightly different (but overlapping) markets.

Because of that, I’d want to think of Word, Excel, PowerPoint and so on each as its own product. Each would have its own product owner and product backlog.

With a product as large as Office, it is quite likely there also would be products based on shared functionality across things like Word, Excel and PowerPoint. Thinking of the spell checker, for example, as a product could make sense. The spell checker provides benefits to a market (the other teams who do not need to write their own spell checker from scratch).

I would not, however, define Excel’s Function widget (sum, average, count, etc.) as a product. It is unique to Excel and as such, serves only one customer. To give it a product backlog and product owner outside the context of Excel would be too risky.

In addition to avoiding one-customer products, another way to reduce suboptimal thinking when working with multiple products is to appoint a chief product owner. The chief product owner is a strategic role, responsible for establishing vision across all subproducts. On the Office product, for example, the chief product owner would be looking at how each individual product affects the suite as a whole.

What Do You Think?

Correctly identifying the products in your organization can help you avoid problems related to team structure, product backlog management and having people in the wrong roles. How do you define “product” in your organization? Are there guidelines you can extrapolate to create a general definition of product? Please share your thoughts in the comments below.

More Effective Team With Less Efficient Workers!

Xebia Blog - Mon, 09/05/2016 - 09:11
Methods based on Agile and the Kanban Method both stimulate collaboration to achieve focus and flow. In practice this is often challenged by teams with specialists who have a tendency to maximize the utilization of the specialists. So, is a team with a focus to finish work more effective than a team with focus on

How Michael Bolton and I Collaborate on Articles

James Bach’s Blog - Mon, 09/05/2016 - 07:28

(Someone posted a question on Quora asking how Michael and I write articles together. This is the answer I gave, there.)

It begins with time. We take our time. We rarely write on a deadline, except for fun, self-imposed deadlines that we can change if we really want to. For Michael and I, the quality of our writing always dominates over any other consideration.

Next is our commitment to each other. Neither one of us can contemplate releasing an article that the other of us is not proud of and happy with. Each of us gets to “stop ship” at any time, for any reason. We develop a lot of our work through debate, and sometimes the debate gets heated. I have had many colleagues over the years who tired of my need to debate even small issues. Michael understands that. When our debating gets too hot, as it occasionally does, we know how to stop, take a break if necessary, and remember our friendship.

Then comes passion for the subject. We don’t even try to write articles about things we don’t care about. Otherwise, we couldn’t summon the energy for the debate and the study that we put into our work. Michael and I are not journalists. We don’t function like reporters talking about what other people do. You will rarely find us quoting other people in our work. We speak from our own experiences, which gives us a sort of confidence and authority that comes through in our writing.

Our review process also helps a lot. Most of the work we do is reviewed by other colleagues. For our articles, we use more reviewers. The reviewers sometimes give us annoying responses, and they generally aren’t as committed to debating as we are. But we listen to each one and do what we can to answer their concerns without sacrificing our own vision. The responses can be annoying when a reviewer reads something into our article that we didn’t put there; some assumption that may make sense according to someone else’s methodology but not for our way of thinking. But after taking some time to cool off, we usually add more to the article to build a better bridge to the reader. This is especially true when more than one reviewer has a similar concern. Ultimately, of course, pleasing people is not our mission. Our mission is to say something true, useful, important, and compassionate (in that order of priority, at least in my case). Note that “amiable” and “easy to understand” or “popular” are not on that short list of highest priorities.

As far as the mechanisms of collaboration go, it depends on who “owns” it. There are three categories of written work: my blog, Michael’s blog, and jointly authored standalone articles. For the latter, we use Google Docs until we have a good first draft. Sometimes we write simultaneously on the same paragraph; more normally we work on different parts of it. If one of us is working on it alone he might decide to re-architect the whole thing, subject, of course, to the approval of the other.

After the first full draft (our recent automation article went through 28 revisions, according to Google Docs, over 14-weeks, before we reached that point), one of us will put it into Word and format it. At some point one of us will become the “article boss” and manage most of the actual editing to get it done, while the other one reviews each draft and comments. One heuristic of reviewing we frequently use is to turn change-tracking off for the first re-read, if there have been many changes.¬† That way whichever of us is reviewing is less likely to object to a change based purely on attachment to the previous text, rather than having an actual problem with the new text.

For the blogs, usually we have a conversation, then the guy who’s going to publish it on his blog writes a draft and does all the editing while getting comments from the other guy. The publishing party decides when to “ship” but will not do so over the other party’s objections.

I hope that makes it reasonably clear.

(Thanks to Michael Bolton for his review.)

Categories: Testing & QA

SPaMCAST 409 ‚Äď Team Structure, QA Presentations, Eliciting Requirements

SPaMCAST Logo

http://www.spamcast.net

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

Special Note РSPAMCAST 409 was due to be posted last week, but bad things happened to my main computer and my backup decided to air-gap itself from the Internet.  That said, #409 is going up a week later so the Re-read Saturday news is a week out of date.  This week we talk about Chapters 22 and 23. I have declared that last weekend was a very stressful vacation from posting.  Now the show goes on!

In Software Process and Measurement Cast 409, we feature our essay on advice I recently provided to a listener to the podcast on whether a team is really one or two teams.  While the essay is a result of answering a friend’s question, the ideas in the essay can be applied when you are building any sort of team.

Our second column this week features a visit to Jeremy Berriault‚Äôs QA Corner. ¬†Jeremy and I discussed how QA should communicate with other leaders in the organization. ¬†In the third and final column, Jon M. Quigley begins a three-part arc on requirements in ‚ÄúThe Alpha-Omega of Product Development.‚ÄĚ This week on discusses the elicitation of requirements.

Re-Read Saturday News

This week we continue our re-read of Kent Beck’s XP Explained, Second Edition with a discussion of Chapters 20 and 21.  Chapter 20 is a discussion of applying XP.  The short version is that there is no one perfect way to apply XP, which dovetails nicely with Chapter 21 which addresses the concept of purity and certification.  IF there is no one perfect way to apply XP, how can there be an absolute litmus test for XP purity?   

Use the link to XP Explained in the show notes when you buy your copy to read along to support both the blog and podcast. Visit the Software Process and Measurement Blog (www.tcagley.wordpress.com) to catch up on past installments of Re-Read Saturday.

Next we are going to read The Five Dysfunctions of a Team.  This will be a new book for me, therefore an initial read, not a re-read!  Steven Adams suggested the book and it has been on my list for a few years. Click the link (The Five Dysfunctions of a Team), buy a copy, and in a few weeks we will begin to read the book together.

Next SPaMCAST

In the next Software Process and Measurement Cast, we will feature our interview of Jessica Long.  Jessica and I discussed storytelling.  Storytelling is useful in all types of organizations for both projects and as a tool in organizational transformations.  

Jessica and I will both be presenting on using stories at the Agile Philly, Agile Tour 2016 on October 10th.  If you are in the Philadelphia area please register and attend!  

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, for you or your team.‚ÄĚ Support SPaMCAST by buying the book here. Available in English and Chinese.


Categories: Process Management

SPaMCAST 409 - Team Structure, QA Presentations, Eliciting Requirements

Software Process and Measurement Cast - Sun, 09/04/2016 - 22:00

Special Note - SPAMCAST 409 was due to be posted last week, but bad things happened to my main computer and my backup decided to air-gap itself from the Internet.  That said, #409 is going up a week later so the Re-read Saturday news is a week out of date.  This week we talk about Chapters 22 and 23. I have declared that last weekend was a very stressful vacation from posting.  Now the show goes on!

In Software Process and Measurement Cast 409, we feature our essay on advice I recently provided to a listener to the podcast on whether a team is really one or two teams.  While the essay is a result of answering a friend’s question, the ideas in the essay can be applied when you are building any sort of team.

Our second column this week features a visit to Jeremy Berriault‚Äôs QA Corner. ¬†Jeremy and I discussed how QA should communicate with other leaders in the organization. ¬†In the third and final column, Jon M. Quigley begins a three-part arc on requirements in ‚ÄúThe Alpha-Omega of Product Development.‚ÄĚ This week on discusses the elicitation of requirements.

Re-Read Saturday News

This week we continue our re-read of Kent Beck’s XP Explained, Second Edition with a discussion of Chapters 20 and 21.  Chapter 20 is a discussion of applying XP.  The short version is that there is no one perfect way to apply XP, which dovetails nicely with Chapter 21 which addresses the concept of purity and certification.  IF there is no one perfect way to apply XP, how can there be an absolute litmus test for XP purity?   

Use the link to XP Explained in the show notes when you buy your copy to read along to support both the blog and podcast. Visit the Software Process and Measurement Blog (www.tcagley.wordpress.com) to catch up on past installments of Re-Read Saturday.

Next we are going to read The Five Dysfunctions of a Team.  This will be a new book for me, therefore an initial read, not a re-read!  Steven Adams suggested the book and it has been on my list for a few years. Click the link (The Five Dysfunctions of a Team), buy a copy, and in a few weeks we will begin to read the book together.

Next SPaMCAST

In the next Software Process and Measurement Cast, we will feature our interview of Jessica Long.  Jessica and I discussed storytelling.  Storytelling is useful in all types of organizations for both projects and as a tool in organizational transformations.  

Jessica and I will both be presenting on using stories at the Agile Philly, Agile Tour 2016 on October 10th.  If you are in the Philadelphia area please register and attend!  

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, for you or your team.‚ÄĚ Support SPaMCAST by buying the book here. Available in English and Chinese.

Categories: Process Management

Extreme Programming Explained, Second Edition: Re-Read Week 12 (Chapters 22 ‚Äď 23)

XP Explained Cover
This week the re-read of Kent Beck and Cynthia Andres‚Äôs Extreme Programing Explained, Second Edition (2005) tackles Chapters 22 and 23. Two more weeks until we shift gears and start reading The Five Dysfunctions of a Team (if you do not own a copy, it is time to order one ‚Äď use the link to support the blog and podcast). ¬†Back to XP Explained;¬†Chapter 22 considers the implications of offshore development on the application of XP. ¬†Distributed team members does not preclude using XP. ¬†Chapter 23 waxes philosophically on the programming. ¬†At its core, programming is a discussion of people and behavior more than technique and tools.

Chapter 22: Offshore Development
In the late 20th and early years of the 21st centuries, the software industry was still learning how to grapple with offshore development. Distributed teams became a popular idea. ¬†Whether a team was partially in India, Belarus or Iowa has always been less of an issue than how power and decision making is distributed. ¬†Beck makes the point that even the word ‘offshore’ is a loaded concept that implies an imbalance of power (Beck prefers the term ‚Äúmultisite‚ÄĚ). Teams with imbalance of power and decision making will be less effective because parts of the team will be demoted to order takers rather than collaborators. ¬†The values of XP (and therefore XP as an approach to development) are just as relevant in multisite development. When embracing XP in a multisite environment the values and principlesof XP provide a stable underpinning to tailor the core and ancillary practices of XP.

The practices of XP, as we have noted before, are merely tools to implement the values and principles of XP.  There is no perfect set of XP practices, but rather each organization needs to implement XP based on their own context.  Multisite development is just another context. As an example, Beck suggests that in a multisite environment planning might have to occur multiple times a week rather than once every sprint or iteration.

The goal of multisite development is to increase productivity.  There are numerous ways to state this goal, such as to get more with less or to improve the value of software delivery; however as we have explored in previous essays, all of these statements boil down to improved productivity.  One way to measure and provide evidence of improved productivity is to reduce team sizes while increasing throughput. The second goal of multisite development is to reduce waste in software development rather than trying to put up barriers that keep work in places with low productivity or high production costs. Everyone should consider the second goal as a clarion call for continuous improvement (process, people and technology) to protect competitiveness and jobs.
 
Side Note:  Even though XP Explained, Second Edition was published in 2005, the state of multisite development is still mixed.  I have worked as a consultant for many organizations that leverage multisite development.  Done well multisite site development often offers significant value, but many organizations approach the model poorly and therefore don’t get the value they expect.

Chapter 23: The Timeless Way of Programming
When I read this chapter I was struck by how different the two editions of XP Explained are when compared. The second edition far more philosophically in tune with the world of software development of the early 21st Century (i.e. now). Beck begins the chapter by using the analogy of the power differential between a structural architect and the person for whom he or she is designing the space.  The architect has the upper hand, unless a balance of between the parties can be established.  In the software development environment, the relationship between the business and development, in which the business describes both what they want and the how, when and cost of what will be delivered, is a reflection of a similar power imbalance.  A healthier relationship requires a balance between the business and technical view that maintains the integrity of the overall system.

The values, principles of XP promote the aim of a balanced relationship between the business and development. XP describes an environment in which the team includes technical and business personnel. ¬†XP provides an environment in which developers can develop and excel technically so decisions about the business can be left to the business-oriented part of the team. As Beck puts it,‚ÄĚsharing power is pragmatic, not idealistic.‚ÄĚ In the end XP is discussion of empowering people versus primarily being a discussion of tools and techniques.

Previous installments of Extreme Programing Explained, Second Edition (2005) on Re-read Saturday:

Extreme Programming Explained: Embrace Change Second Edition Week 1, Preface and Chapter 1

Week 2, Chapters 2 ‚Äď 3

Week 3, Chapters 4 ‚Äď 5

Week 4, Chapters 6 ‚Äď 7 ¬†

Week 5, Chapters 8 ‚Äď 9

Week 6, Chapters 10 ‚Äď 11

Week 7, Chapters 12 ‚Äď 13

Week 8, Chapters 14 ‚Äď 15

Week 9, Chapters 16 ‚Äď 17

Week 10, Chapters 18 ‚Äď 19

Week 11, Chapters 20 – 21

Remember  we are going to read The Five Dysfunctions of a Team by Patrick Lencioni next.  This will be a new book for me; therefore an initial read, not a re-read!  Steven Adams suggested the book and it has been on my list for a few years. Click the link (The Five Dysfunctions of a Team), buy a copy, and in a few weeks, we will begin to read the book together.


Categories: Process Management

Estimating on Non-Trivial Software Projects

Herding Cats - Glen Alleman - Sat, 09/03/2016 - 18:17

A nice conversation on twitter about estimates on software brought up the topic of estimates as commitments. The #NoEstimates advocates see estimates as making commitments. Yes, commitments are made when we estimate. But that commitment is not a promise. A Promise is a guarantee, with 100% confidence it will be net. Our wedding vows are a promise to each other. A commitment must have a probabilistic confidence. Just for the reference, 

A commitment must have a probabilistic confidence. Just for the reference, a commitment is the state or quality of being dedicated to a cause, activity, etc.
"the company's commitment to quality
or an engagement or obligation that restricts freedom of action. Take for example Boulder's commitment for 100% recycling of consumer products inside the city limits. Is that commitment are guarantee every single consumer waste product collected at our curb will be recycled? That is a tall order and not likely to ever be the case. 

I have an 80% confidence (an estimate) I can deliver what you need on or before September 15 (an estimate), at or below $15,000.oo (an estimate) with a 15% error band (an estimate). 

Screen Shot 2016-09-03 at 8.11.19 AM

The misuse of that commitment is a real problem in all domains. But that's got NOTHING to do with the need for the estimate and EVERYTHING to do with bad management. No Estimating isn't going to make the need for estimates go away or fix bad management, no matter how many Dilbert cartoons are used to illustrate that.

In any non-trivial domain, there are larger business processes in play that is looking for value in exchange for money. When business people think about that exchange, they think about some agreement between those paying for the value and those providing the value . This agreement can be formal or it can be informal. But that agreement is always in place. 

In our domain of software intensive system of systems, we have formal agreements at the top of the engagement and less formal agreements lower down based on agile software development processes. Here's how it is done where we work.

This is not a unique domain, once the formality of dealing with a sovereign is removed. Corporate governance has similar frameworks for managing the stockholders or stakeholders money.   For specific activities in our domain, there are other work efforts needed to estimate the outcomes, the cost of those outcomes and when those outcomes will be delivered. This formality is not likely needed for anything other than the largest corporate IT projects. But the principles are the same, it's the processes and practices that are different.  But the 5 Immutable Principles of project success are always in place no matter the size of the project beyond de minimis projects. So when you hear Estimates can't be done, estimates are a waste, estimates are the smell of dysfunction, estimates are evil, this may actually be true for those working on de minimis projects. Projects where those paying for the work have NO concern about how much it will cost to produce the value, NO concern when that value will be available for use, NO concern if the capabilities that produce that value actually work and actually do produce the value for the needed cost on the needed date.   In those conditions, #NoEstimates advocates are right. Estimates are not needed. For those of us working outside the de minimis project domains, they are.   Related articles Capability Maturity Levels and Implications on Software Estimating Are Estimates Really The Smell of Dysfunction? Herding Cats: Connecting Project Benefits to Business Strategy for Success Why Guessing is not Estimating and Estimating is not Guessing Software Estimating for Non Trival Projects Herding Cats: Range of Domains in Sofwtare Development Essential Reading List for Managing Other People's Money Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management
Categories: Project Management

Stuff The Internet Says On Scalability For September 2nd, 2016

Hey, it's HighScalability time:

 

Spectacular iconic drawing of Aurora Borealis as observed in 1872. (Drawings vs. NASA Images)
  • 4,000 GB: projected bandwidth used per autonomous vehicle per day; 100K: photos of US national parks; 14 terabytes: code on Github in 1 billion files held in 400K repositories; 25: age of Linux; $5 billion: cost of labor for building Linux; $3800: total maintenance + repairs after 100K miles and 5 years of Tesla ownership; 2%: reduction in Arizona's economy by deporting all illegal immigrants; 15.49TB: available research data; 6%: book readers who are "digital only";

  • Quotable Quotes
    • @jennyschuessler: "Destroy the printing press, I beg you, or these evil men will triumph": Venice, 1473
    • @Carnage4Life: Biggest surprise in this "Uber for laundry" app shutting down is that there are still 3 funded startups in the space
    • @tlipcon: "backpressure" is right up there with "naming things" on the top 10 list of hardest parts of programming
    • cmcluck: Please consider K8s [kubernetes] a legitimate attempt to find a better way to build both internal Google systems and the next wave of cloud products in the open with the community. We are aware that we don't know everything and learned a lot by working with people like Clayton Coleman from Red Hat (and hundreds of other engineers) by building something in the open. I think k8s is far better than any system we could have built by ourselves. And in the end we only wrote a little over 50% of the system. Google has contributed, but I just don't see it as a Google system at this point.
    • looncraz: AMD is not seeking the low end, they are trying to redefine AMD as the top-tier CPU company they once were. They are aiming for the top and the bulk of the market.
    • lobster_johnson: Swarm is simple to the point of naivety.
    • @BenedictEvans: That is, vehicle crashes, >90% caused by human error & 30-40% by alcohol, cost $240bn & kill 30k each year just in the USA. Software please
    • @joshsimmons: "Documentation is like serializing your mental state." - @ericholscher, just one of many choice moments in here.
    • @ArseneEdgar: "better receive old data fast rather than new data slow"
    • @aphyr: hey if you're looking for a real cool trip through distributed database research, https://github.com/cockroachdb/cockroach/blob/develop/docs/design.md … is worth several reads
    • @pwnallthethings: It's a fact 0day policy-wonks consistently get wrong. 0day are merely lego bricks. Exploits are 0day chains. Mitigations make chains longer.
    • andrewguenther: Speaking of [Docker] 1.12, my heart sank when I saw the announcement. Native swarm adds a huge level of complexity to an already unstable piece of software. Dockercon this year was just a spectacle to shove these new tools down everyone's throats and really made it feel like they saw the container parts of Docker as "complete." 
    • @johnrobb: Foxconn just replaced 60,000 workers with robots at its Kushan facility in China.  600 companies follow suit.
    • @epaley: Well publicized - Uber has raised ~$15B. Yet the press is shocked @Uber is investing billions. Huh? What was the money for? Uber kittens?
    • Ivan Pepelnjak: One of the obsessions of our industry is to try to find a one-size-fits-everything solutions. It's like trying to design something that could be a mountain bike today and an M1 Abrams tomorrow. Reality doesn't work that way
    • There were so many good quotes this week that they wouldn't all fit here. Please see the full post to read all the wonderfulness.

  • This should concern every iPhone user. Total ownage.
    • Steve Gibson, Security Now 575, with a great explanation of Apple's previously unknown professional grade zero-day iPhone exploits, Pegasus & Trident, that use a chain of flaws to remotely jail break an iPhone. It's completely stealthy, surviving both reboots and upgrades. The exploits have been around for years and were only identified by accident. It's a beautiful hack.
    • Your phone is totally open and it happens just like in the movies: A user infected with this spyware is under complete surveillance by the attacker because, in addition to the apps listed above, it also spies on: Phone calls, Call logs,  SMS messages the victim sends or receives, Audio and video communications that (in the words a founder of NSO Group) turns the phone into a 'walkie­talkie'
    • Bugs happen in complicated software. Absolutely. But these exploits were for sale...for years. The companies that sell these exploits do not have to disclose them. Apple should be going to the open market and buying these exploits so they can learn about them and fix them. Apple should be outbidding everyone in their bug bounty system so they can find hacks and fix them.
    • Paying for exploits is not an ethical issue, it's smart business in a realpolitik world. If you can figure out the Double Irish With a Dutch Sandwich you can figure out how to go to the open market and find out all the ways you are being hacked. Apple needs to think about security strategically, not only as a tactical technical issue

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

Scaling Agile and Management Styles

Scaling!

Scaling!

Participative management styles are often used by Agile teams.  Participative management styles are perceived to be more flexible. Flexibility allows teams to immediately react to the feedback they receive as they work rather than wait until it is too late to react. Flexibility is a core principle of Agile; however, scaling Agile requires trading some of the flexibility of participative management styles for more control.  More control is needed due to the increased size of both team and work and the increased level of risk large pieces of work typically represent.   

The five management styles (autocratic, consultative, negotiative, delegative and participative) can be viewed as a continuum from  the most directive to the most collaborative.  Teams that follow Agile principles and are of manageable size leverage a participative management approach (except in specific scenarios). As Agile is scaled the number of people and roles required to deliver in a predictable manner increase. This need is a reflection of a need for control.  The raw number of connections required for a group to use participative management exclusively explodes as team size increases. The harder it is for everyone to communicate and come to a consensus, the more other management styles are required. This is even though small teams within the larger group might mix and match management styles base on their individual needs. For example, I recently observed a moderately large Agile program (six teams and 70 people involved, including support personnel).  A key stakeholder chaired a weekly directional meeting with the leads from each team.  She used a consultative approach to set direction, the leads then returned to their team and more participative styles.   

While Agile principles and autocratic management styles don’t mix (think oil and water, or perhaps ¬†a better analogy might be the combination of water and rocks — autocratic management sinks Agile fast) and are rarely used together in Agile organizations. The other styles mix more appropriately with Agile principles. ¬†The less interactive styles tend to be adopted a step at a time as the work gets larger. Each style reduces the number of decision points. ¬†For example, negotiative styles typically revolve around positions of power within a team, such as a product owner or a technical lead. ¬†The people with power act as decision makers reducing the number of people that need to reach consensus.

In most organizations, the fear generated from risk can cause individuals or groups to want to hold decisions closer to their vest if they perceive that an outcome of a piece can affect their business or career.  As programs get larger (scale) the level of perceived and actual risk gets larger. For example, all other things being equal, a piece of work with a budget of $1,000 will be perceived as being far less risky than a piece of work with $1,000,000 budget.  Individuals that might be affected by a risky project will tend to veer toward more controlling management system.  Controlling management styles allow the decision maker to retain authority for decisions and reduce the fear that they will be seen abdicating responsibility.

The size and risk to the business and career of those involved can often require a more controlling management style. A more controlling style for the overall piece of work does not mean that a team has to abandon their more participative style to guide their day-to-day work.  


Categories: Process Management

Get ready! DevFest Season has started!

Google Code Blog - Thu, 09/01/2016 - 20:33

Posted by Ale Borba and Adriana Cerundolo, Developer Relations Program Managers

Today kicks off the annual DevFest season, a series of developer community-run events which will be happening over the next 3 months. Google Developer Group (GDG) chapters from around the world will host #DevFest16 events, bringing together developers to exchange knowledge, share ideas, and express their passion for technology.

At its core, #DevFest16 is powered by a shared belief that when developers come together to exchange ideas, amazing things can happen! Itis an opportunity for GDGs to share speakers and event resources with each other to put on quality events uniquely tailored to the needs of the local developer communities. Attendees can expect technical content around Google developer technologies, including Firebase, Google Cloud Platform, machine learning with TensorFlow, web development and much more.

We anticipate 50k developers from over 70 countries to participate in #DevFest16 this year; from Canada to Australia, throughout South America, Africa, Europe and Asia, GDGs will be joining together to bring you an enriching developer experience. Go find a DevFest near to you!

Happy Festing!

Categories: Programming

The Power Of ‚ÄúEarly Access‚ÄĚ

Android Developers Blog - Thu, 09/01/2016 - 17:59

By Karolis Balciunas, VC & Startups Business Development Manager, Google Play

If you have ever launched a mobile app, you know full well that launching your app into the world successfully requires more than publishing it and hoping for the best.

It’s the diligent testing, constant user feedback loop and incremental tweaks leading up to that special launch moment that truly count.

The Google Play Developer Console gives developers robust tools to do beta tests or experiment with how they market their apps to users through the Play store listing. Getting this critical early feedback from users requires just that ‚ÄĒ users. And as a developer working on a new product that isn‚Äôt fully launched yet, how do you find people to try your new app and take the time to give you feedback?

1 Million Tester Installs And Counting

At Google I/O in May, we unveiled a new destination on Google Play to address this dilemma head on. Together with 29 app and game partners, we launched an ‚ÄúEarly Access‚ÄĚ collection that made select new Android titles that are running an open beta available for anyone to try before they officially launch. It was an immediate hit. Early-adopter users were eager and willing to send developers actionable, private feedback in exchange for an opportunity to get their hands onto the latest exciting apps and games. Most importantly, the feedback was objective and candid as it did not come from their friends and family who are often afraid to hurt their feelings. In just over a month since the collection became available to all users, open beta titles have been installed over 1 million times and demand is only growing.

3 Powerful Stories

Our launch partners experienced the power of Early Access in various ways. Peer-based language practice developer Lingbe was eager to validate the concept of their app connecting natives with language learners via voice conversations, which meant they needed to connect with a critical mass of possible users around the world from different language and cultural backgrounds. In just a few weeks, "the surge in users in addition to our current fan base meant that we've had Brazilians practicing with Spanish users and talking about their hobby in photography, Mexicans making friends with people from India, and Filipinos talking to Moroccans!"

Readfeed, one of the first online book clubs on Android, relied on Early Access to solicit feature requests, identify bugs, locate new and optimize existing target markets as well as build a sizable reader community. They stated that "early access confirmed that our target market exists and that we have something that they need. I don't think we'd be in the same place right now without it. It enabled us to validate and effectively iterate on our idea from day one."

Finally, Drippler participated in Early Access to test their new "Wiz" app and understand their beta title's appeal to their target demographic. Their performance in the Early Access collection as well as private feedback from thousands of newly acquired beta testers allowed them to polish the app before the launch and gave them confidence that their users will enjoy it."

These three developers’ stories show us just a few ways that Early Access can help developers build great new apps and games, and it shows the value of getting early feedback from beta testers before launching more broadly.

Get Involved

If you are a developer getting ready to launch on Google Play, you can nominate your app or game to be part of Early Access. Learn more here.

New titles are added weekly and thousands of users are looking to experiment with new and exciting ideas.

Categories: Programming

The Myth That Research Can't Be Managed

Herding Cats - Glen Alleman - Thu, 09/01/2016 - 17:20

There is a popular myth that ...

some software development projects are research and aren't subject to normal business management processes

I'm here to tell you this ain't true. I've managed several pure and applied research projects in my life, including my graduate research. This experience includes bio-pharma, engineering development, and physics research projects - all software intensive.

Research projects start with a hypothesis,

A Hypothesis is a supposition or proposed explanation made on the basis of limited evidence as a starting point for further investigation.

This is the target of the research. The why of the effort. Without this hypothesis it's not research, it's wandering around looking under rocks for something. Something that you may not even recognize is what you're looking for.

So don't fall for the claim that I can't know when I'll be done, how much it will cost, or what Done looks like because we're working on innovation or PURE research.

Those who work on research projects and work on innovative design projects have a goal - a hypothesis. They wrote that down before they started. It's in their grant proposal. It's in their funding request. You self-funding, you'd better write that done as well, or your money is going to be wasted looking under rocks for that magic item that you don't even know will sell. 

Related articles Complex Project Management The Fallacy of the Planning Fallacy Qualitative Risk Management and Quantitative Risk Management What Happened to our Basic Math Skills? Mr. Franklin's Advice
Categories: Project Management

My Test Tube Filled with DNA is Better than Your Mesos Cluster

 

We’ve seen computation using slime mold, soap film, water droplets, there’s even a 10,000 Domino Computer. Now DNA can do math In a test tube. Using addition, subtraction, multiplication, and division.

It’s not fast. Calculations can take hours. The upside: they are tiny and can work in wet environments. Think of running calculations in your bloodstream or in cells, like a programmable firewall, to monitor and alert on targeted health metrics and then trigger a localized response. Or if you are writing  science fiction perhaps the ocean could become one giant computer?

The applications already sound like science fiction:

Prior devices for control of chemical reaction networks and DNA doctor applications have been limited to finite-state control, and analog DNA circuits will allow much more sophisticated analog signal processing and control. DNA robotics have allowed devices to operate autonomously (e.g., to walk on a nanostructure) but also have been limited to finite-state control. Analog DNA circuits can allow molecular robots to include real-time analog control circuits to provide much more sophisticated control than offered by purely digital control. Many artificial intelligence systems (e.g., neural networks and probabilistic inference) that dynamically learn from environments require analog computation, and analog DNA circuits can be used for back-propagation computation of neural networks and Bayesian probabilistic inference systems. How does it work?
Categories: Architecture

Closure Compiler in JavaScript

Google Code Blog - Wed, 08/31/2016 - 17:01
Posted by Sam Thorogood, Developer Programs Engineer

The Closure Compiler was originally released, in Java, back in 2009. Today, we're announcing the very same Closure Compiler is now available in pure JavaScript, for use without Java. It's designed to run under NodeJS with support for some popular build tools.

If you've not heard of the Closure Compiler, it's a JavaScript optimizer, transpiler and type checker, which compiles your code into a high-performance, minified version. Nearly every web frontend at Google uses it to serve the smallest, fastest code possible.

It supports new features in ES2015, such as let, const, arrow functions, and provides polyfills for ES2015 methods not supported everywhere. To help you write better, maintainable and scalable code, the compiler also checks syntax, correct use of types, and provides warnings for many JavaScript gotchas. To find out more about the compiler itself, including tutorials, head to Google Developers.

How does this work?

This isn't a rewrite of Closure in JavaScript. Instead, we compile the Java source to JS to run under Node, or even inside a plain old browser. Every post or resource you see about Closure Compiler will also apply to this version.

To find out more about Closure Compiler's internals, be sure to check out this post by Dimitris (who works on the Closure team at Google), other posts on the Closure Tools blog, or read an exploratory post about Closure and how it can help your project in 2016.

Note that the JS version is experimental. It may not perform in the same way as the native Java version, but we believe it's an interesting new addition to the compiler landscape, and the Closure team will be working to improve and support it over time.

How can I use it?

To include the JS version of Closure Compiler in your project, you should add it as a dependency of your project via NPM-


npm install --save-dev google-closure-compiler-js

To then use the compiler with Gulp, you can add a task like this-

const compiler = require('google-closure-compiler-js').gulp();
gulp.task('script', function() {
// select your JS code here
return gulp.src('./src/**/*.js', {base: './'})
.pipe(compiler({
compilation_level: 'SIMPLE',
warning_level: 'VERBOSE',
output_wrapper: '(function(){\n%output%\n}).call(this)',
js_output_file: 'output.min.js', // outputs single file
create_source_map: true
}))
.pipe(gulp.dest('./dist'));
});

If you'd like to migrate from google-closure-compiler (which requires Java), you'll have to use gulp.src() or equivalents to load your JavaScript before it can be compiled. As this compiler runs in pure JavaScript, the compiler cannot load or save files from your filesystem directly.

For more information, check out Usage, supported Flags, or a demo project. Not all flags supported in the Java release are currently available in this experimental version. However, the compiler will let you know via exception if you've hit any missing ones.

Categories: Programming

Agile Teams and Management Styles

Baseball Game

Teams and situations require different management styles.

Every team may leverage several styles of management to deliver value most efficiently. In Agile teams, some styles are used more often than others. The default management style for Agile teams tends to be participative, but management style is affected by team size, context, and role.

Team Size: ¬†The number of people on a team affects possible management styles. ¬†The larger the team, the less participative the team can be due to the sheer number of connections and conversations required. ¬†I have participated on ‚Äúteams‚ÄĚ of 30 or 40 people earlier in my career (I use the term ‚Äúteam‚ÄĚ with reservation). With large teams like that, the possible number of interconnections between individuals is limited, where the formula (n(n-1))/2 defines the possible number of combinations. ¬†A 35 person team requires 595 connections, most of which would have to exercise to generate the consensus needed to execute participative management. Frankly, that is impractical. Agile teams are fairly complicated even though there are aren‚Äôt an infinite number of moving parts. ¬†Scrum teams are typically 5 to 9 people including a Scrum master and product owner, while XP teams tend to be in the 4 – 12 person range. ¬†A team of 12 would have 66 possible connections. ¬†Teams with larger numbers of connections tend to favor directive approaches ranging from the somewhat participative negotiative style to delegative management, or the command and control favorite, the authoritarian style.

Role: Role power is a concept that rarely gets discussed in most Agile conversations, however, different roles often represent a differential in power. For example, the product owner will tend to have more organizational power than a typical tester or coder.  Teams often premise interactions and decision-making on members checking their titles at the door.  Checking titles at the door is code for assuming equality of power at the team level. However, that equality is rare.  Product owners, tech leads and even the scrum master’s opinions tend to have more weight than someone that is one amongst equals.   These types of power imbalances tend to foster the use of negotiative or delegative management styles.

Context: Context is the most important rationale for using different management styles.  Most adherents of Agile would be quick to extol the virtues of collaborative management.  Collaborative management is very supportive of self-organization and self-management, however, there are occasions when collaborative management styles do not make sense.  In times of great stress, more direct authoritative styles are typically more appropriate (when there is a fire in the airline cabin, decisions must be made). How the team adjusts behaviorally, integrates the new decision or direction change and then settles back to its preferred style says a lot about the maturity of the team. A mature team typically recognizes the need for the management style diversion or urges the team member back toward the team norm (through peer pressure or discussion). At other times, Agile teams use delegative approaches to allow a member (or subgroup) to make decisions within their specialty areas.  For example, I recently observed a team that tapped two members to review and purchase print modules for an application.  The team agreed upon a broad set of criteria, then charged the subgroup to operate within that framework.  Whether addressing decision-making in emergencies or areas of technical expertise, context-dependent changes in style are typically short term. Afterwards, the team reverts almost immediately to their preferred style as soon as the need for an alternative style passes.

Teams always have preferred management styles but, as with potato chips, an Agile team can’t just use a single style. Getting work done is complicated. Teams reflect a chaotic environment of roles, team size and situation.

 

Management / Leadership Thread


Categories: Process Management

Improvements for smaller app downloads on Google Play

Android Developers Blog - Tue, 08/30/2016 - 19:09

Posted by Anthony Morris, SWE Google Play and Andrew Hayden, software engineer

Google Play continues to grow rapidly, as Android users installed over 65 billion apps in the last year from the Google Play Store. We’re also seeing developers move to update their apps more frequently to push great new content, patch security vulnerabilities, and iterate quickly on user feedback.

However, many users are sensitive to the amount of data they use, especially if they are not on Wi-Fi. Google Play is investing in improvements to reduce the data that needs to be transferred for app installs and updates, while making data cost more transparent to users.

Read on to understand the updates and learn some tips for ways to optimize the size of your APK.

New Delta algorithm to reduce the size of app updates

For approximately 98% of app updates from the Play Store, only changes (deltas) to APK files are downloaded and merged with the existing files, reducing the size of updates. Google Play has used delta algorithms since 2012, and we recently rolled out an additional delta algorithm, bsdiff (created by Colin Percival1), that our experimentation shows can reduce delta size by up to 50% or more compared to the previous algorithm for some APKs. Bsdiff is specifically targeted to produce more efficient deltas of native libraries by taking advantage of the specific ways in which compiled native code changes between versions. To be most effective, native libraries should be stored uncompressed (compression interferes with delta algorithms).

An example from Chrome: Patch Description Previous patch size Bsdiff Size M46 to M47 major update 22.8 MB 12.9 MB M47 minor update 15.3 MB 3.6 MB

Apps that don’t have uncompressed native libraries can see a 5% decrease in size on average, compared to the previous delta algorithm.

Applying the delta algorithm to APK Expansion Files to further reduce update size

APK Expansion Files allow you to include additional large files up to 2GB in size (e.g. high resolution graphics or media files) with your app, which is especially popular with games. We have recently expanded our delta and compression algorithms to apply to these APK Expansion Files in addition to APKs, reducing the download size of initial installs by 12%, and updates by 65% on average. APK Expansion file patches use the xdelta algorithm.

Clearer size information in the Play Store

Alongside the improvements to reduce download size, we also made information displayed about data used and download sizes in the Play Store clearer. You can now see actual download sizes, not the APK file size, in the Play Store. If you already have an app, you will only see the update size. These changes are rolling out now.

  1. Colin Percival, Naive differences of executable code, http://www.daemonology.net/bsdiff/, 2003. 

Example 1: Showing new ‚ÄúDownload size‚ÄĚ of APK

Example 2: Showing new ‚ÄúUpdate size‚ÄĚ of APK

Tips to reduce your download sizes

1. Optimize for the right size measurements: Users care about download size (i.e. how many bytes are transferred when installing/updating an app), and they care about disk size (i.e. how much space the app takes up on disk). It’s important to note that neither of these are the same as the original APK file size nor necessarily correlated.


Chrome example: Compressed Native Library Uncompressed Native Library APK Size 39MB 52MB (+25%) Download size (install) 29MB 29MB (no change) Download size (update) 29MB 21MB (-29%) Disk size 71MB 52MB (-26%)

Chrome found that initial download size remained the same by not compressing the native library in their APK, while the APK size increased, because Google Play already performs compression for downloads. They also found that the update size decreased, as deltas are more effective with uncompressed files, and disk size decreased as you no longer need an compressed copy of the native library. However, please note, native libraries should only be uncompressed when the minimum SDK version for an APK is 23 (Marshmallow) or later.

2. Reduce your APK size: Remove unnecessary data from the APK like unused resources and code.

3. Optimize parts of your APK to make them smaller: Using more efficient file formats, for example by using WebP instead of JPEG, or by using Proguard to remove unused code.

Read more about reducing APK sizes and watch the I/O 2016 session ‚ÄėPutting Your App on a Diet‚Äô to learn from Wojtek KaliciŇĄski, about how to reduce the size of your APK.

Categories: Programming

The cat-and-mouse story of implementing anti-spam for Mail.Ru Group’s email service and what Tarantool has to do with this

Hey guys!

In this article, I’d like to tell you a story of implementing the anti-spam system for Mail.Ru Group’s email service and share our experience of using the Tarantool database within this project: what tasks Tarantool serves, what limitations and integration issues we faced, what pitfalls we fell into and how we finally arrived to a revelation.

Let me start with a short backtrace. We started introducing anti-spam for the email service roughly ten years ago. Our first filtering solution was Kaspersky Anti-Spam together with RBL (Real-time blackhole list‚Ää— a realtime list of IP addresses that have something to do with spam mailouts). This allowed us to decrease the flow of spam messages, but due to the system’s inertia, we couldn’t suppress spam mailouts quickly enough (i.e. in the real time). The other requirement that wasn’t met was speed: users should have received verified email messages with a minimal delay, but the integrated solution was not fast enough to catch up with the spammers. Spam senders are very fast at changing their behavior model and the outlook of their spam content when they find out that spam messages are not delivered. So, we couldn’t put up with the system’s inertia and started developing our own spam filter...

Categories: Architecture