havkom

The ”game” of software development is rather ”won” by understanding the surrounding business and delivering on those goals rather than any, by software developers made up, “goals” about “standards”, “unit testing” or “SOLID design patterns”.

The game is also about good co-operation, helping colleagues succeed without imposing dogmatic requirements, and making friends with influential people connected to the software development team.

This is rather an article about loosing the “game”.

Example 1 was interesting. Who was it that was inflexible and may be difficult to work with? The interviewer that wanted to ask about another specific solution or the person who was interviewed who was not interested in another solution?

I would recommend that when someone is new in a large project with an older code base, to pay attention and learn from others.

A mistake I often see is too many “suggestions for improvement” too early. This behavior, when excessive as it often is, is perceived to be invalidating tough choices that were made before your time and chances are that the people who made the choices had good reasons for it and are more experienced than you are. Learn from your seniors - it may be hard when you’ve just read about this new “paradigm X which solves all problems” and you believe you are smarter than others - but please try.

I’m glad that FB treats everyone equally.

Many meetings are extremely important for me as a manager.

Very few of the meetings are about “deciding things”, rather they are about aligning views. As a manager I see my role as setting up meetings so that the most qualified peoples views properly influences the right stake holders. When everyone aligns on what problem to solve and how to solve it there are generally no need to take any decisions, since work gets efficiently done and few issues pops up that are not automatically solved by way of previously achieved alignment.

While using this strategy, what generally drives more meetings are: 1) Managers and other power holders that cares more about their importance and status than the work. 2) The parts of the staff that are dissatisfied and don’t like their work. In many of these cases, they have been obviously neglected/abused by management before and don’t feel trust in the organization.

My fault. 17 280 h per year was the calculated savings

My fault. 17 280 h per year was the calculated savings

The main parts of the wrong-doing:

- The school had obtained consent from the pupills and each one of the pupills could opt out at any time. The Swedish Data Protection Agency (DPA) did however find that due to the power balance of a school vs a pupill, these consents are not ”freely given”, and thus are void. The school therefor have no legal basis of processing special categories of data/sensitive data, which processing face recognition data (”biometric information”) for identification purposes is. Violation of GDPR Article 9.

- The school had not completed a sufficient Data Protection Impact Assesment which properly identified risks of this processing. In addition, due to the nature of this processing, they would have been obliged to consult with the DPA about this impact assessment before starting. Violation of GDPR Article 35&36.

- The DPA also found that the processing was more extensive than necessary, since attendance could be taken in less invasive ways. This a violation of GDPR article 5.1c (the data minimisation principle).

I hope the decision will be appealed by the school, which is run by the municipality. There are several interesting questions, such as if consent can be freely given in schools, if the data minimization principle was really breached (the school claimed this way of taking attendance saves a calculated 72,000h of teachers time per year in just this school), etc. I am not sure however that the municipality has the right resources and competency to make a competent appeal.

Additional information if anyone is interested:

In general, I believe for example the US court system hierarchy (where you appeal instance by instance in serial order) is very different from the EU court system (when it comes to interpretation on EU law).

Lower courts MAY ask the EU court for guidance on what EU law means while the court of last instance for a type of case (the highest court) MUST ask the EU court on what the EU law means if it is not clear.

Here is the relevant text in the Treaty of the Functioning of the European Union (TFEU):

https://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX...

If anyone is interested in more information of exceptions from referring to the EU court you can read up on the doctrine of acte clair and acte eclairé. This doctrine is now always followed (nd may sometimes be difficult to follow) by court of last instance so it is important that lower courts can ask if they think the higher court has made an error in relation to this.

The main parts of this judgement were very unsurprising. It is very well established in EU law that a higher national court can not order a lower court to withdraw a reference for a preliminary ruling from the Court of Justice of the European Union.

EU law normally override EU member state national law. The EU court is the final interpreter on EU law.

The thinking about lower courts unappealable ability to ask the EU court for what the EU law is, that a higher or highest national courts should never be able to suppress a question from reaching the EU court.

Hence, if the Supreme Court in a member state would give a final ruling on a topic, any lower court that thinks the Supreme Court were wrong on points of EU law, may always in a following case ask the EU court for final guidance on what EU law actually means (instead of just following the Supreme Court ruling). The Supreme Court would in that instance have no means of preventing that from happening.

In many real world applications using common databases you do not always need “transaction safety”, in particular when reading data for statistical purposes.

Performance gains and not blocking the database for many other readers and writers will in many scenarios outweigh the possibly of reading uncommitted/dirty data.

Use:

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

(whether you are are querying from within a transaction or not)

and you may be surprised how this may solve many of your performance problems in your application/service.

This is correct according to the text of the law.

However, according to precedents the criteria “the matter can be satisfactorily investigated” is not easily satisfied in case of serious crime that is contested (see the court case RH 2011:4).

I have no idea of the facts in this case, but based on how organizations function in general, one possibility is that the redundancy issues of MCAS were raised internally by some engineers without result.

In that case, the engineers were probably not thanked internally back then and are probably not thanked now either.

If their potential concerns would had led to changes on the MCAS design they would probably not have been thanked either, but rather seen as the people who unnecessarily made the project more expensive or less profitable.

In conclusion, people who avert or try to avert risk are seldom proportionally thanked in organizations in general.

Just a side note in relation to the title, EU institutions are not subject to GDPR.

They are instead subject to the similar Regulation (EU) 2018/1725 of the European Parliament and of the Council.

Much smaller administrative fines among other things.

https://eur-lex.europa.eu/legal-content/EN/TXT/?qid=15525770...

However, the linked article discusses not EU government/institutions but rather EU member states public authorities web sites. Such web sites are subject to GDPR but each member states decides whether administrative fines should be possible to impose on public authorities (and if so their max amounts) according to GDPR Article 83(7).

> BTW, if your data set can be disposed by an awk script, it should not be called “big data”.

I think this statement is wrong. The popular meaning of the hype term “big data” can not be easily changed.

Rather, awk, sed and other tools that can read from stdin and write to stdout are great tools for “big data” and often more efficient and suitable than larger and more hyped systems.

It is often junior ppl who request rewrites.

Junior as in * have been exposed to few real-world development projects, or, * have little understanding for the interplay between development and business. (The junior developer may however be very good at programming in languages X, Y and Z.)

Many developers will be junior under this definition for all of their career.

The exception I have seen from this is consultant sales ppl, who want to use the hype of the new often untested (or for the task non-optimal) technology or paradigm X.

When the original system was written by developers who were not junior, as is often the case with large successes systems that have survived, the result from letting junior developers rewrite the system, will be predictable.

Tip: Be cautious when listen to developers that talk about “technical debt” and similar. Make sure they are not junior developers under the definition above or are just not that good at reading code and understanding real world systems. Similarly, when listening to a sales pitch by a consultancy firm, make sure they have your interest in mind.

Well, I have had well run experiments which showed that the “currently internally hyped” way of doing things is completely inferior to the “old boring” and inexpensive way. The project leader was extremely hyped about doing the experiment to prove the superiority of the new hyped way. When he got the results though, it was clear that this was not to be talked about and this result would not be presented to his superiors.

Another upshot is that this system with a whiteboard marker is avoiding personal data processing that is not needed (the GDPR data minimization and storage limitation principles).

Privacy by design :-)

What is important is the business objectives. It does not matter if a whiteboard marker is used or a mouse is used that sends signals to an elegant micro-service architecture.

The customer is always right, and in this case the restaurant is the customer.

This is a great example of that principle and in the end the customer was happy and used a, for their business need, a good system.

I just want to add for the record that I am not a fan of very complicated principles based legislation (which GDPR is) by myself. It is not easy to comply with and it has clear drawbacks.

But now we have GDPR I wanted to state facts (as I understand them) so people can get a more nuanced view of what to expect and hopefully help them with how to deal with compliance in a reasonable manner.

Yes. Exactly what non-material damages means will be up to CJEU to decide eventually. I do not think many ppl expects it to mean “free-for-all” and I do not think your “sleeping example” would suffice. Admittedly, no one can know for sure at this point in time though.

The level of fines looks like it will be harmonized by EDPB (a board of all Data Protection Authorities) so individual DPAs will probably not be able to set arbitrary levels. There are also the one-stop-shop rules so a company will normally only have to deal with one DPA.

When it comes to compensation, you have to show what material or non-material damages you’ve suffered. Class actions are generally not a big thing in the EU. Sure, there is an exposure here but in practice I think it will be very limited, especially for smaller companies.

Not related to the ads industry but GDPR compliance in general for smaller companies (which is discussed in various other comments to this article), I would like to add these remarks:

I think ”GDPR compliance” is not a binary thing - there are levels of compliance. No smaller normal company or Google or Facebook will be able to “fully comply” at any point in time. There will always have to be incremental improvements over time, hopefully in the right direction.

Also recognize that the obligations in GDPR “scales” with the size of operation/amount of data that is processed. For example smaller companies:

- are exempted from some of the record keeping obligations,

- may not have to appoint a data protection officer,

- may often not have to do data protection impact assessments,

- may not have to set up and implement some policies relating to data protection

- may also have less obligations when it comes to Privacy by Design (since reasonable costs are a recognized factor)

- may generally have fewer data processing activities that requires consent (most normal personal data processing does not)

I would also forget about scares of 4% fines unless you are doing something really bad or do not care at all even after a fine, repremand or warning from a Data Protection Authority.

My guess is that the “normal level of fine amount” will not change with GDPR for data protection violations in the EU (compared to current UK levels). This seems to be what the UK:s Data Protection Authroity (ICO) is going around and telling everyone as well (if I have not misunderstood).

We now live in the information age. Blockchains and AI will transform everyday life as well as specific sectors such as health care and trade.

Imagine walking in to a Starbucks café, order a cup of coffee, digitally signing a payment transaction on your mobile or laptop and then wait for it to be confirmed by the Blockchain while enjoying the hot cup of coffee you have ordered.

What is more, think about AI, you will not need to talk to the staff to place an order for your coffee. The staff can relax and watch you make gestures to a camera. They will be able to read on a screen if you’d like it white or black.

I think the article is too negative and does not see the big picture of transformation that is going on (as exemplified above).

Yes. Forget about just not rendering the data in projections. Article 5.1e states: “Personal data shall be kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed [...]”

Article 5 contains concrete rules and also sets out the basic principles.

In short, you must be able to remove all information that may enable you to “single out” an individual (a physical individual by eg name or an online identity such as a particular web visitor by eg a cookie id).

I agree with everything in your comment.

Regarding necessity I think it should not be interpreted too strictly. Rather, I believe it means something like this in EU law:

“Necessity implies the need for a combined, fact-based assessment of the effectiveness of the measure for the objective pursued and of whether it is less intrusive compared to other options for achieving the same goal.”

(Quote from: https://edps.europa.eu/sites/edp/files/publication/17-06-01_... )

I agree w this too. However, it depends if you have a valid contract with the user and the data processing is sufficiently related to the performance of that contract, if you are going to use that basis.

Notwithstanding Article 5.2 on accountability, I do not believe that non-controversial data processing under legitimate interest needs to be well documented in practice, although I may be proven wrong. I believe it is sufficient to mention legitimate interest and what your legitimate interest is in broad terms in the privacy notice.

For controversial use, that is processing which the data subjects may not approve you of doing, I believe you need documentation on the balancing test. However, in controversial cases you probably also need documentation on the necessity both when it comes to performance of contract and legitimate interest.

Regarding your first statement: It depends if you have a valid contract with the user and the data processing is sufficiently related to the performance of that contract.

Yes. Unless you have legacy systems with screen shot based SAR responses for example

> Functions that allow the users to delete and automatically download/access their own data is good practice for legitimate interest but not needed. You are anyway in general allowed to deal with these types of request on a case by case basis if you provide your data subjects with an email address.

I want to be very clear - you _almost always without exception_ have to provide access to/copy of personal data to the data subject no matter what legal basis is used (consent or not). “Data portability”, providing the data in a commonly used electronic format, such as JSON/XML download, is optional when using legitimate interest but mandatory when using consent.

You also _normally_ have to delete personal data of those data subjects who have requested it. You also normally have to stop using the data for the purposes the data subject requests you to stop with.

These processes do not normally need to be automated (but with consent it should be as easy to provide consent for the data subject as it is to revoke it).