Nestimate

nestimate

As an autonomous driving enthusiast, I’ve been interviewing at several autonomous driving companies for the position of a software engineer. Typically, autonomous driving companies build a car that is able to navigate its way in 3D surroundings. Consequently, the company cares how good you as a candidate are with computational geometry and specifically your ability to code it up. One of the interview questions that intrigued me was formulated like the following: Imagine your autonomous car is driving on the road and its locations are captured with GNSS (ex.: GPS), not precisely but with some measurement error. Given a car drives straight with constant speed, compute the locations of its most likely positions knowing a sequence of 2D noisy measurements in the bird-eye-view projection. This task can be attacked from several different approaches. In this article, we will look into 3 solutions coded in Python and NumPy and compare them. Mathematically, the task is phrased as linear regression: finding a straight line that regresses our set of points. Approach 1: Ordinary least squares At the first glance, the problem looks like a regular . least-squares problem We are given 2D coordinates that are pairs of (x, y). We can treat as the argument and as the value of a function. We can follow the formula below: x y This method is very handy since it is straightforward (no pun intended), i.e. we just take the formula and calculate according to it. Without further ado let’s code it up! Please follow the comments in the code below. x = points[:, ]
   y = points[:, ] X = np.vstack((np.ones(x.shape[ ]), x)).T normal_matrix = np.dot(X.T, X)
   moment_matrix = np.dot(X.T, y) beta_hat = np.dot(np.linalg.inv(normal_matrix), moment_matrix)
   intercept = beta_hat[ ]
   slope = beta_hat[ ] y_hat = intercept + slope * x points_hat = np.vstack((x, y_hat)).T points_hat -> np.ndarray: def least_squares (points: np.ndarray) """
   Function to approximate a set of points by a straight line
   using least squares method.

   :param points: an input array of points of shape [N, 2]
   :return: Numpy array of shape [N, 2] of points on a straight line
   """ 0 1 # For least squares method we need X to be a matrix containing # 1-s in the first column and x-s in the second 0 # We compute normal matrix and moment matrix as a part of # formula to compute intercept and slope # beta_hat is a vector [intercept, slope], we need to invert # the normal matrix and compute cross product with the moment matrix 0 1 # Now when we know the parameters of the line, computing # y coordinates is straightforward # Let's combine x and y into a single matrix that we want to return return Let’s see what we get as the result. Looks exactly as we would like it to - the line is straight and is well fit into the given set of 2D points. However, the least squares method has a significant flaw -- it does not work if the line is vertical. In this case, the slope of the line becomes infinite and the program either crashes or returns NaNs (Not a Numbers). Consequently, it is not suited for production purposes when we expect all possible kinds of trajectories. Approach 2: RANSAC is a method of finding a consensus that is based on random samples. It was proposed in 1981. RANSAC In our 2D case, we are going to randomly sample 2 points (which we are going to call “a support”) from the input array and check how well the input points fit into a stripe of the vicinity of a straight line formed by the support. Of course, not all trials will yield a line that goes through the point set, that is why RANSAC is an iterative algorithm. For RANSAC we have a nice formula that allows us to estimate the number of iterations required to obtain a successful result given an estimated fraction of outliers and a probability of success: where - the probability of success, - a fraction of outliers, - the size of the support. In our case of a straight line in 2D space, the size of the support is equal to 2. For a line in 3D space, it would be 2 as well, and for a plane in 3D it would be 3. In the code example below the number of iterations turns out to be 16 which is a pretty affordable number. Going further , I suggest following comments in the code. p ω n num_trials = int(math.log( - probability_of_success) /
                    math.log( - outliers_fraction** ))

   best_num_inliers = best_support = _ range(num_trials): random_indices = np.random.choice(
           np.arange( , len(points)), size=( ,), replace= ) random_indices[ ] != random_indices[ ]
       support = np.take(points, random_indices, axis= ) cross_prod = np.cross(support[ , :] - support[ , :],
                             support[ , :] - points)
       support_length = np.linalg.norm(support[ , :] - support[ , :]) distances = np.abs(cross_prod) / support_length num_inliers = np.sum(distances < max_distance) num_inliers >= min_inliers num_inliers > best_num_inliers:
           best_num_inliers = num_inliers
           best_support = support best_support : support_start = best_support[ ]
       support_vec = best_support[ ] - best_support[ ] offsets = np.dot(support_vec, (points - support_start).T)
       proj_vectors = np.outer(support_vec, offsets).T
       support_sq_len = np.inner(support_vec, support_vec)
       projected_vectors = proj_vectors / support_sq_len
       projected_points = support_start + projected_vectors projected_points -> Optional[np.ndarray]: def ransac (points: np.ndarray,
          min_inliers: int = ,
          max_distance: float = ,
          outliers_fraction: float = ,
          probability_of_success: float = ) 4 0.15 0.5 0.99 """
   RANdom SAmple Consensus method of finding the best fit line.

   :param points: an input array of points of shape [N, 2]
   :param min_inliers: Minimum number of inliers to consider a support
   :param max_distance: Maximum distance from a support line
                        for a point to be considered as an inlier
   :param outliers_fraction: As estimated fraction of outliers
   :param probability_of_success: desired probability that the support
                                  does not contain outliers
   :return: Numpy array of shape [N, 2] of points on a straight line
   """ # Let's calculate the required number of trials to sample a support 1 1 2 0 None for in # For each trial, randomly sample 2 different points # from the input array to form the support 0 2 False assert 0 1 0 # Here we compute distances from all points to the line # defined by the support. Distances are nicely computed # with cross product function. A peculiarity of np.cross # is that it returns z coordinate of the cross product - # exactly what we need to compute the distance. 1 0 1 1 0 # cross_prod contains signed distances thus we need modulus # Inliers are all the points that are close enough # to the support line # Here we update the support with the better one if and # If we succeeded to find a good support if is not None # Let's project all points onto the support line 0 1 0 # Dot product is the right function to compute projections return What do we get having launched the code? The resulting line approximates the set of points well. The points that form the best support are denoted with black squares. What are the drawbacks of RANSAC? First of all, it does not guarantee a successful result. The probability that random sampling chooses an outlier as one of the support points or chooses a couple of bad inliers (for example very close to each other) is fairly low. However, for applications that require high reliability like autonomous driving, RANSAC may not be a good fit. Also, RANSAC won’t work in cases when we do not have access to a random or pseudo-random number generator. Apart from this RANSAC has several parameters which must be chosen appropriately for each application. Specifically, max_distance is hard to estimate beforehand without spending some time on the estimation of the amount of noise in 2D locations. Approach 3: PCA PCA, is often used for dimensionality reduction when we need to find an affine transform of a point cloud in a way that the variance in most of the dimensions becomes small, or at least small compared to the minority of important dimensions. In this case, we can drop the dimensions that do not provide the information. This is very similar to our case when we want to get rid of the noise in the direction perpendicular to the main direction of point locations and then project the points on the line of the main direction. Principal Component Analysis To perform PCA we need to calculate pairs of (eigenvector, eigenvalue) the given point cloud. The bigger an eigenvalue is the bigger the variance is along the direction of the corresponding eigenvector. For our problem, we need to find an eigenvector that has the largest eigenvalue. This eigenvector will describe the straight line that we will project the input points on. Below is the code with comments: mean = np.mean(points, axis= ) centered = points - mean cov = np.cov(centered.T) eigenval, eigenvec = np.linalg.eig(cov) argmax_eigen = np.argmax(eigenval) loc_pca = np.dot(centered, eigenvec)
   loc_maxeigen = loc_pca[:, argmax_eigen]
   max_eigenval = eigenval[argmax_eigen]
   max_eigenvec = eigenvec[:, argmax_eigen] loc_start = mean + max_eigenvec * loc_maxeigen[ ]
   loc_final = mean + max_eigenvec * loc_maxeigen[ ]
   linspace = np.linspace( , , num=len(points))
   positions = loc_start + np.outer(linspace, loc_final - loc_start) positions -> np.ndarray: def pca (points: np.ndarray) """
   Principal Component Analysis (PCA) method to estimate the direction
   of the maximal variance of a point set.

   :param points: an input array of points of shape [N, 2]
   :return: Numpy array of shape [N, 2] of points on a straight line
   """ # Perform PCA to understand what the primary axis # of the given point set is 0 # Points have to be zero-mean # np.linalg.eig takes a covariance matrix as an argument # Call eigenvector decomposition to obtain principal components # We want to parametrize target straight line # in the coordinate frame given by the eigenvector # that corresponds to the biggest eigenvalue # We'll need projections of data points # on the primary axis # Re-parametrize the line 0 -1 0 1 return Having run the code we get the following graph. PCA has done well! Important to notice that PCA does not have a drawback of the least squares method: PCA gracefully deals with vertical lines. Also, PCA will always give us the result as opposed to RANSAC. However, compared to RANSAC, PCA is more sensitive to wild outliers in 2D point locations. Conclusion This problem caught my attention because it has several significantly different solutions, all of which have their own pros and cons. Also, this problem allows us to practice computational geometry and matrix operations with NumPy on a simple example. Let’s take a look at all three solutions in the same figure. Out of these 3 solutions my personal preference is PCA. Dear reader, I hope you like the article and that it helped you get more insight into the practical experience of implementing a computational geometry problem into code. The full code is available at . my GitHub page Thank you for your attention and best luck with your interviews!

RANSAC, OLS, PCA: 3 Ways to Draw a Straight Line Across a Set of Points

A Guide to Making Estimates for Software Development Projects

Ask any developer to estimate how long it will take for them to finish a project. You will see the loathing in their eyes. And for good reason. Estimates have been wrongly used for decades by a lot of managers who then hold the team accountable to their estimate as if it were the actual deadline. Even more frustrating, in many cases those managers only act on the lowest number they hear from you! It’s as if they had a min() function, and they just keep trying to get the number lower. But engineering is not magic!! No wonder the hashtag #NoEstimates has become famous. For this to happen, we (well…especially managers) need to abide by a few rules. Then we’ll see how estimates can improve the quality of your software. Yup, you read that right. Well, in my opinion, obviously. Don’t Mess with the Rules of Estimation! Rule #1: Never ever consider an estimate as a commitment to a deadline Or, you risk losing your team’s trust at once, and it will be hard to get their trust back. The funny thing here is that even managers don’t know exactly what they will get done by the end of the day. So how can they imagine will know exactly what they will have accomplished, given their and that most of the time projects have a lot of unknowns? Nothing is magic 🤬! developers productivity can be randomly impacted Rule #2: Don’t ever share your estimate outside of your team or to other related departments I guess that’s even worse than rule #1. Communicating an estimate carries the risk that it will automatically switch to a commitment to a deadline, and other departments will adjust their priorities accordingly, putting even more pressure on your team. Rule #3: If you have a ballpark estimate, the reality is most likely in between the lower and higher boundaries, but not on the lower one As a manager, you cannot actually influence the delivery date by just wishing. Unless you change the scope or quality of the project. But otherwise, you cannot. If you are given a ballpark figure with a high and low estimate, you would be smarter to consider both pieces of information. Even the PMP introduced the term to get closer to what the end result will be. PERT (Program Evaluation and Review Technique) Rule #4: The uncertainty of estimates is linked to the unknowns. The more unknowns, the LESS confident you should feel about the estimate But also the less unknowns, the more confident you should feel about the estimates. What does this mean? Every project has a certain level of unknowns attached to it. When developers give you a ballpark estimate, let’s say 4–8 days, they give you 2 valuable pieces of information: the number of days and how confident they feel about it. Another way to view it is like this: 6 days with 2 days of uncertainty (or 33% uncertainty). If the uncertainty is important, it means that there are potentially many unknowns that could impact the eventual delivery. These unknowns can have a lot of impact, or none at all. My point here is that the chances are greater for estimates to go awry (even outside of the defined boundaries) when the uncertainty is high. Rule #5: Addressing unknowns first DOES increase the confidence on estimates There are 2 types of unknowns: unknown unknowns and known unknowns. There is not much you can do for unknown unknowns. And by definition, developers can’t really take them into consideration in their estimates; they might have given themselves a few more days just in case, and those days are usually actually spent on debugging. However, concerning known unknowns, spending the first hours or days of your project to address them can significantly alleviate doubts on the work to be done in the end. This way you can reduce the uncertainty mentioned in rule #4. For instance, the 6 days +/- 2 days, can become 6 days +/- 1 day. By the way, you can understand that specs are part of the possible known unknowns. The more precise the specs are, the less uncertainties there will be. So get to work, PMs. Rule #6: If an estimate seems fine to you (and you’re the high-expectation kind of manager), you may want to ask the right questions If a developer tells you it’s going to take 4 days for a project, and you were expecting 5, and you always have a tendency to be too optimistic, then it may mean the developer doesn’t have the same thing in mind for the task as you do. I would personally advise you to ask yourself some of the following questions: Are the specs well understood? Can the or architecture scale to the number of users we want? technology Can it last at least 24 months? What are the risks associated with this solution and to the choices about to be made? The point is, you might not be thinking about the same level of requirements for the solution. Again, there is no magic. Rule #7: If you ever need a deadline, respect the cone of uncertainty Sometimes you need to have a release date defined a few weeks / months early, because you are not the only ones that need to meet the deadline for that particular project. This is a reality that you need to consider. In this case, have you heard about the ? cone of uncertainty The graph is pretty self-explanatory, but in a few words: You can’t ask for promises too early on. Promises don’t work well with unknowns. So the first thing to do is to set the release date for as late as possible. But if you really have to give a timeline early on, ask your team to be exploratory at first and try to address all unknowns before starting to agree on a date. Keep in mind, though, that your team should be defining or influencing the date as much as possible. If not, you take the chance of impacting the scope or quality of your project. Rule #8: Analysis paralysis is easily surmountable Okay…so this is not a rule per se. But it’s a good hack for managers. Developers might not really appreciate it at first, but I think it does initiate the conversation, and if in the end you agree that estimates can have value for developers, then maybe developers will be ok with this rule. 🤞 If a developer doesn’t want to give you an estimate because the task is too complicated (and to be fair, estimating is no easy task), an easy way to initiate the discussion is to just throw out a very high number like “100 days”? The developer will probably say, “Hell, no!” Then you work your way down with lower and lower numbers until the developer tells you, “Might be.” Then do the same, but with a very low number; the developer will again tell you, “Impossible!” And again you work your way up until the developer tells you, “Possibly.” There! You have a ballpark estimate to start with. But don’t forget to respect all the other rules — an estimate is not a committed delivery time. Okay, so we’ve gone through the rules. Don’t hesitate to add more in the comments. I will edit the article with your input. Now, let’s suppose our team respects all the rules as to how and why estimates can be useful to developers. Why would developers be more than okay with estimates? If you don’t need to have a predefined release date, you might wonder why you would even need estimates at all. Valid question, my friend. In my mind, the point of estimates is that they create discussions and mutual understanding around the unknowns. When you discuss estimates, if any of them are a bit off, it will create discussions, and the developer could go to the whiteboard to sketch their understanding of the work to be done for the tasks at hand. If their understanding is a bit off, other developers might clarify some point in the architecture of the code. You might even have cases where a senior developer can learn some great hacks from more junior ones. Estimates create discussions that educate developers on the code and its architecture. They can eventually uplevel the quality of the code itself and even help developers tackle tasks faster than they would have done otherwise. However, note that to take the most advantage of estimates, they should be done as a team. You could also reflect on the estimates during your post mortems; there will be more lessons to be learned. In the end, the benefits gained are a trade-off with the time spent by the team on the estimates. There are many ways to do this. For instance, estimates could have their own dedicated meetings that should be kept focused as much as possible. We all know about meetings … enough said. — Just a last note. If you have second thoughts on estimates you’ve been given, you might also consider ‘gamifying’ the process to engage your developers. For example, score the team’s accuracy across weeks or projects and have some kind of congratulatory gifts when beating a new record. Well, just an idea :). Let me know if I missed any rules, or if you don’t agree with my conclusions. Before You Go… Learned something? Don’t hesitate to share it to help others find it! If you are interested in articles about , subscribe to our newsletter! engineering and product leadership, productivity and how to scale a team Or join our . Engineering Leadership Community _High-quality trending articles curated by the community on engineering leadership, productivity, how to scale teams and…_community.anaxi.com Engineering Leadership Community | Anaxi You can also check out my latest articles: _Have you ever heard about teams being managed through metrics, like bug close rate or lines of code produced per week…_hackernoon.com Do NOT Measure Developers — Measure Projects _A lot of articles address the role of tech leads and engineering managers. One common theme we often come across is how…_hackernoon.com Top 12 Things That Destroy Developer Productivity _We’ve all heard about the 10x engineer phrase, haven’t we? Did you know that the original study back in the 1960s…_hackernoon.com The Attributes of a Unicorn 20x Engineer You can also follow me on to stay connected. Thank you! Twitter Originally published at anaxi.com on November 9, 2018.

How to Make Estimates Finally Useful to Developers

Hopefully I caught your attention with the controversial (and admittedly hyperbolic) title. Good. Let me restate it in a slightly more elegant and less form: clickbaity In general, you can either have software delivered on time or good software, but you can’t have both* * except on counted occasions in established, highly-performant teams The past few months I’ve been reflecting about why delivering good software does not play well with estimates and planning in general. During my career I’ve seen projects ran in many different ways (waterfall, agile, agile-fall) and all of them shared a thing in common: no matter what kind of project we were working on, if we “ ” (i.e. we didn’t take hacky shortcuts that would give us nightmares), we always ran past the deadline. true did it right On the other hand, whenever a project was delivered “on time”, either its scope was reduced along the way or we had to cut so many corners that the tech debt accumulated during implementation all but guaranteed that the project would have to be re-written shortly after launch, which made me wonder: Is a project actually “on time” even when the end result is an uglier, less maintainable, bug-ridden and, plainly speaking, version of what we set out to do initially? suckier I’ve also worked on projects that were not deadline-driven. There were “deadlines”, sure, but far from them being set in stone, it was understood that deadlines were flexible and that quality trumped on-time delivery. Those were the projects which produced the best software, had the happiest developers and were the most successful overall amongst the ones I’ve worked on. But we all know those projects are a rare find, or I wouldn’t be writing this. So why is it so difficult to plan and deliver good software given a static timeline? I think it has a lot to do with , and . creativity craftsmanship unpredictability The creative side of coding I am of the view that . Sure, there are developers who perform repetitive, trivial tasks, but they will have a job only as long as no one figures out how to automate theirs — not a great place to be in, and not the focus of this essay. software development is an inherently creative undertaking For me, there’s something special about the act of something new and looking for original solutions to challenges that calls me to software development, and I don’t think I am the only one. In fact, I believe creativity is the main reason why developers enjoy their work. In my experience, whenever I’ve worked in environments where there were strict and unchangeable “set of practices” (think tech stack, processes, guidelines, etc.) — i.e. the least creative freedom I had — , the less engaged I felt. “After all, if they already have it all figured out, why do they me?”, I wondered. On the other hand, I felt much more fulfilled, excited and productive at work when there were few top-down directives, I was given creative leeway and was trusted to own up to my technical decisions. creating need It’s important to note that more creative freedom begets more trial and error to reach the solution — which is fine. Some people think that you can just know the perfect solution (i.e. in advance) before writing a single line of code. I contend instead that, for creative activities, the process of discovering a solution to a given problem (not only software) is : you can’t have perfect knowledge in advance, but instead you learn by doing, iteratively trying new things and keeping what works, and by refining your solution (and possibly shipping it to your customers if you are lean/agile) until you are satisfied with it. ex-ante a process of tinkering Just think of how many times you have spent time designing a feature on paper, just to have to change the design completely once you actually start implementing it. There will always be and the only way to uncover and deal with them is by actually coding your solution, instead of spending a lot of time theorizing and pretending we have perfect information in advance. This process of tinkering does not play very well with estimates. unknown unknowns ex-post Further, as it’s the case with other creative endeavors, coding benefits from — A term coined by Adam Grant which asserts that often you can’t be creative but instead creativity comes as a “push event” from a process running in the background of your mind: Strategic Procrastination on demand “ Employees who procrastinated regularly spent more time engaging in divergent thinking and were rated as significantly more creative by their supervisors. Procrastination didn’t always fuel creativity: if the employees weren’t intrinsically motivated to solve a major problem, stalling just set them behind. But when they were passionate about coming up with new ideas, putting off the task led them to more creative solutions .” — Grant, Adam. “Originals: How Non-Conformists Move the World.” Again, not great news for the out there trying to plan and measure every minute of software development projects. central planners The craft of building software The best developers I know are crafts[wo]men. Craftsmanship is the hallmark of good software: — It’s relatively easy to build something that works, but very hard to build something that works and stands the test of time. you don’t only build something that works, but you build it in the best way possible . You prime quality over quantity because you don’t want to be known to write crappy software, even if you could satisfy your Product Manager by just making your software look good “on the outside” but full of nasty surprises on the inside — what I call . You know that investing time in writing good software pays off and you push back on pressures to “execute faster” as you know the more shortcuts you take now, the less life expectancy your code will have and the more problems it will cause down the road. As a crafts[wo]man, the quality of your work defines you Kinder Surprise Development My eyes bleed Craftsmanship is about : caring to do a great job, caring about the ones who will maintain your code after you, caring about the consumers of your software having an easy time using it, caring about your team mates, and so on. You care because you are not an asshole and because you know that it’s the right thing to do if you want the project to be successful. caring In short, good engineers have the difficult task of caring about quality — something that has the long-term consequences — in a world driven by short-term execution. In practice, that translates into things like: Finding the right mix between encapsulation, extensibility, scalability, etc. — again, you will need iterative trial and error, will build the best solution on the first try. no one Taking time to refactor when you stumble upon a shamefully bad part of the code Writing good, complete tests — maybe even doing TDD Code pairing with colleagues Needless to say, it’s impossible to plan for all these in advance, so this doesn’t help you hit any deadlines either. Your predictions are wrong Even with clear requirements — and it seems that they never are — it is still almost impossible to know how long something will take, because we’ve never done it before. If we had done it before, we’d just give it to you. — Ron Jeffries, The NoEstimates Movement Software Projects are : They are made possible by human beings and thus are affected by interpersonal interactions, motivation, communication issues and human psychology in general — all those pretty difficult to model and quantify on a spreadsheet, if you ask me. This makes software projects very difficult to model (and hence predict). Nassim Taleb explains it best in his book : Complex Systems Antifragile “Complex systems are full of interdependencies — hard to detect — and nonlinear responses. “Nonlinear” means that when you double the dose of, say, a medication, or when you double the number of employees in a factory, you don’t get twice the initial effect, but rather a lot more or a lot less. Two weekends in Philadelphia are not twice as pleasant as a single one — I’ve tried.“ Antifragile — Nassim Nicholas Taleb, What’s worse, given that time can’t be negative, any unplanned “surprises” will very likely increase the completion time instead of reducing it as there is an in the outcomes: asymmetry “Just as time cannot be negative, a three-month project cannot be completed in zero or negative time. So, on a timeline going left to right, errors add to the right end, not the left end of it. If uncertainty were linear we would observe some projects completed extremely early (just as we would arrive sometimes very early, sometimes very late). But this is not the case.“ Antifragile — Nassim Nicholas Taleb, This is bad news, as and even small errors in estimating individual tasks will compound exponentially at the project level. All this is assuming the best case scenario where deadlines have been set after some careful estimation by the developers, but reality is even more absurd: most of the time “The Business” sets the deadlines arbitrarily and only then Engineering comes up with a plan to deliver the requirements by those randomly chosen points in time, in a flagrant case of start building the house from the roof and then putting the cart before the horse on top. uncertainty is certain Good question Here are some examples to illustrate some of the nonlinearities and feedback loops of writing software: That time when you assumed that the API you need to communicate with accepts but it actually only accepts . You had to add 4 days to your estimate to refactor the API code — which in turn had to go through a separate review process which added 2 additional days. accountId memberId A task estimated to 2 days ends up taking a week because during the review process one of your team mates pushes you (and rightly so) to refactor and improve a very ugly part of the code that was long overdue. That one-point task where you had to implement some new functionality that happened to require an update to a dependency which ended up taking 4 days as the dependency update triggered a chain reaction of dependencies needing to be updated and that caused a bunch of errors in the build. Are we screwed? We keep playing the estimation and planning game out of inertia to reassure ourselves that we know what we are doing, but the truth is that we don’t, and that software projects are empirically unpredictable. Thus, in my opinion, we’d be better off just focusing more on rather than planning — anyone? But of course this will not fly in many organizations: “We can’t just let the engineers run the show, unchecked, there needs to be some accountability!”. I get it. doing #NoEstimates You don’t say? What to do then? I think it comes down to bridging the gap between the world of the spreadsheet and the world of the IDE in a way that allows maximum creativity, flexibility and craftsmanship to Engineering while at the same time carefully managing the commitments made to, and the expectations from the project stakeholders. The Engineering Manager is in the best position to bridge and manage this gap and act like a buffer between the two worlds. It’s not an easy job, but a necessary one. Aaron Longwell explains it well in : his article flexible_; to bend without breaking and to resolve the tension gradually. Servant leadership can be a guide to finding this flexibility.”_ “Because engineering managers inhabit the border between the business and the technical, they are the ones who need to resolve the tension between estimate and reality. It’s a bit like being the wishbone being pulled at both ends; either side can snap. When the business side ‘wins’, the developers end up in a death march. When development concerns outweigh business ones, you end up blowing the budget and deadline. Either way you’re broken. Successful software managers find ways to be — Aaron Longwell, Why Software Development Requires Servant Leaders It’s also very important to have a strong relationship based on trust between Product and Engineering. If there is trust, you will be able to negotiate timelines honestly and openly with good faith. If you have previously proven that your team delivers good software, there should be enough “social capital” for the stakeholders to trust that if you push back on a given schedule is for good reasons and for the common good. Another “trick” that I’ve personally used as a Manager is to avoid giving concrete dates, as they will inevitably be used as hard deadlines. Diffuse time ranges work best, something like “between 3 and 5 weeks”. Then, the closer the diffuse deadline gets, the more definition you add to it: “Between April and May” turns to “Between April 15th and May 3rd” at the beginning of April, which turns to “The week of April 20th” around April 10th, and so on. This way you are openly truthful with your peers while allowing your team the flexibility they will need to solve the inevitable unforeseen problems that will arise. Lastly, remember that it’s up to the developers to stand up for the technical quality of the product delivered, not to the other stakeholders. It’s only natural that tensions will arise between organizations with seemingly divergent incentives on the surface. The key is to point out that, in fact, you are all (presumably) aligned with the same goal: Deliver good quality software to the customers in the fastest way possible — the gist that only good developers seem to understand is that you should avoid taking the deceivingly “fast and easy” way as it’s actually the slowest one in the long run. In conclusion, it’s a solvable yet complex (and common) problem. I’d say that if you feel like your manager or your organization doesn’t set you up to build good software, it’s up to you to speak up and try to change it or, if that fails, find somewhere else to work.

You have to choose between Software Delivered on Time and Good Software

If you could travel back in time and change one thing in a delivered project, what would it be? I spent my last two years working on a major digital transformation project. The project was delivered using at its peak a project team of about sixty team-members, organised in nine teams across two geographical locations. We’ve used Kanban, ran a #NoEstimates approach and relied heavily on Lean product management concepts. It was what I consider a fairly successful project. We delivered regularly working software (deploying to production multiple times per week), we engaged well with the client, we learnt and got things done. As the project ramped down for me, it felt natural to look back and reflect. Were we as successful as we could have been? Could we have done more? What was the ‘ ’ that done differently it would have made the biggest impact? That one thing. one thing Maybe the question is not the right one, maybe you should not look for only one thing to improve and maybe improving loads of small things creates that significant impact. If you would tell me that I wouldn’t disagree with you, however I was determined to find the most impactful ‘thing’. I spent quite some time thinking about it. Could we have tweaked more our Kanban method? Could we have had more collocated Product Owners? Could we have identified our risks sooner? Yeah, maybe all of the above would have helped, but none of them would have been the ‘one thing’ I’m looking for, the one thing that would have made the biggest impact. After a number of sleepless nights, it dawned to me — that one thing that would have made the biggest impact was a . OK, just kidding on losing sleep over it … better decision making process Throughout a day hundreds of micro decisions were made. What should I build first, this story or that story? Should I start a new story, or should I do a bit of refactoring? When should we release, today or tomorrow? Is this story really needed for this release, or can it wait for another release? Can it wait another fortnight? Which feature should we build first? Do I need extra people for the user research, or what I have is enough? For a project of over five hundred working days, with a team of around sixty members, that amounts to a lot of decisions. With so many decisions, it was not surprising that some of them were not understood by the wider team, some were disputed, some disappointed. And, at times some wrong decisions were made. Decisions are triggers of our actions. We act based on what we decided. Take a wrong decision and you create a lot of wasted effort. Make a decision that is not well understood and you have a lot of displeased team members whose morale will be negatively affected. And that had a significant negative impact. So how can we make better decisions? First of all, we need to understand when we are really in a position to make a decision. Ronald A. Howard, quoted by Sam Savage in his book “Flaw of Averages”, put it succinctly: The three elements of any decision are alternatives, information and preferences. Like a three legged stool, if any of these is missing we don’t really have a decision .— Ronald A. Howard This is an important aspect to acknowledge. Paying attention that all elements are present in the decision making process is key. All too often decisions are made on preference alone. Assuming that we are in position to make a decision, then how can we improve the decision making process? Making all the decisions centrally by a person or a group of people it is just not feasible. What about defining all the rules upfront and giving each team-member a rule book? This approach doesn’t seem too appealing either. The rules would impose too many constraints, likely they would not be exhaustive (could you define all possible instances of action?), hard to maintain and difficult to introduce at scale. How about a ? Daniel Kahneman in his best-seller “Thinking, Fast and Slow” defined heuristics as “ ” heuristic based approach a simple procedure that helps find adequate, though often imperfect answers to difficult questions. Dave Snowden talks about the use of heuristics in a Cynefin context [2]. He cites the US Marines who rely on heuristics when the original battle plan breaks down — “ capture the high ground, stay in touch and keep moving”. A good heuristic should be easy to comprehend and easy to with it. For instance, in the US Marines case it is easy to measure if the heuristic was followed or not — ‘have you captured the high ground?’ This is an easy assessment. measure compliance The goal of each project then would be to define a set of heuristics specific to its context. Once defined they would form part of the team’s doctrine (in the same way they are part of the US Marine doctrines) and teams would use it to derive decisions. As an example, a set of heuristics could look something like this: on items which are work only part of your work-in-progress. work-in-progress items. Therefore, before we start working on a new item we check the age of all the items. We select the oldest one we can deal with. work on the oldest , but understand that cost of gathering the information should not exceed the value of the information itself. Therefore, in face of uncertainty we seek ways to reduce it by doing first the activities that will give us the information (as long as they are in WIP). value buying information . Therefore, we will prioritise activities that will give us the fastest route to gain benefits. value cost of delay over solution purity . Therefore before starting any activity we ask ‘why’ are we doing this? question why we are doing the work We will be able to easily measure if we followed the heuristic or not, if we are compliant with it. For instance we can ask ourselves, ? This should be a very easy question to answer. “have we worked on the oldest work-in-progress item” As Daniel Kahneman stated, heuristics don’t offer guarantee of success in all situations. Equally, in the US Marines case by following the heuristics success won’t be always guaranteed. However, what heuristics offer is an ability to move forward in a coherent fashion — as long as all team-members use the same heuristics they should arrive to the same decision, understand how and why the decisions have been made. If the heuristics stop working, then they would focus on finding new heuristics. And don’t forget about the three legged stool. Maybe you are not even faced to make a decision. Yeah, if I could go back in time this is what I’d change. I’d look to improve the decision making process. I can’t go back in time but I will have a chance to do something about it in a new project. These doodling mean nothing of course. I did them unconsciously while making some decisions. [1] Sam, Savage (2009). The Flaw of Averages: Why We Underestimate Risk in the Face of Uncertainty [2] http://cognitive-edge.com/blog/cynefin-dynamics/

Decisions

Estimation — how can we estimate with confidence in software delivery?

How Your Layover Time Can Make or Break an Airline’s Profit

Com el vostre temps de pagament pot fer o trencar els beneficis d'una companyia aèria

Cómo tu tiempo de entrega puede hacer o romper el beneficio de una aerolínea

Ki jan tan Layover ou ka fè oswa ranpli yon profit nan yon konpayi avyon

How Your Layover Time Can Make or Break an Airline's Profit あなたのレイアウトタイムはどのようにして航空会社の利益を生み出すか

Таны Layover цаг нь нисэх онгоцны нисэх онгоцны арилжаа хийх, эсвэл хуваалцах вэ?

Bagaimana Waktu Layover anda boleh membuat atau memecahkan keuntungan syarikat penerbangan

Cum timpul dvs. de transfer poate face sau rupe profitul unei companii aeriene

ඔබේ Layover වේලාව ගුවන් සමාගමේ ලාභයක් නිර්මාණය හෝ බිඳ දැමිය හැකි ආකාරය

วิธีการกําหนดเวลาของคุณสามารถทําหรือทําลายผลกําไรของ บริษัท อากาศ

Kung paano ang iyong layover time ay maaaring gawin o i-break ang isang airline's profit

Layover Zamanınız Nasıl Yapabilir veya Bir Havayolu Şirketinin Kârını Kırabilir

Як ваш час розкладу може зробити або зламати прибуток авіакомпанії

“Burn the Witch! Burn the Witch!” “I have a spell that can make it easy to differentiate AI-generated content from real content.” Like me, you probably got hooked on this ‘burn the witch’ trend before you even realized those videos were AI-generated. Honestly, no one can fault you for that because the things we can do with AI are becoming increasingly limitless. With tools like ChatGPT, DALL·E, Midjourney, Deepfakes, and more that can produce high-quality text, images, and videos on a massive scale, we face a greater risk of misinformation than ever before. Traditional methods like fact-checking have become too slow to keep us in the loop with the right information. So that begs the question: How do we maintain trust in a digital content era where anything can be faked instantly? Keep reading, and you’ll learn the spell. The AI Content Crisis—Why Trust Is Under Attack Imagine watching a video of your favorite politician only to find out it was entirely fabricated by AI. How can we trust anything we see or read online anymore? AI-generated content has never been more prevalent than it is now. For a generation whose trust issues run deep, the thought that any content you read—no matter how human it sounds—could have been generated using a language model like ChatGPT is unsettling. And to top it off, for every human-created video you scroll through, there are three more generated by AI tools like Deepfake. The worst part? You might not even realize that what you saw was AI-generated because how do you explain the voices and faces in the videos? This puts us at risk of not just misinformation but also scams, propaganda, and political manipulation. For instance, there are numerous videos online of politicians saying things they never said. Fake news articles have been used to spread false narratives during elections, and synthetic reviews artificially inflate product reputations. If you weren’t worried already, now would be a good time to start second-guessing the information you’ve consumed in the last few weeks. I know I have had to pause several times and try to confirm if what I was seeing was real—and now I’m less encouraged to turn to the internet in search of valuable information. Unfortunately, this is a looming epidemic. Having to second-guess everything you come across on the internet is not a way to live, especially when it is already such an integral part of our lives. So, what can we do? Enter blockchain—a technology that promises to restore trust by creating a permanent, tamper-proof record of digital content. Blockchain as a Digital Truth Ledger Immutability and Transparency Blockchain provides a solution and an anchor for truth thanks to its immutability, decentralization, and transparency. Data recorded on a blockchain cannot be altered or deleted—it remains permanent. Also, the fact that no single party controls the data reduces censorship and tampering risks. In addition, these records can be publicly verified, enabling anyone to confirm authenticity. Provenance Tracking and Verification These properties work together to ensure that each piece of digital content can be time-stamped and linked to its original creator or publisher on the blockchain; consumers or platforms can verify if content matches the original record, flagging modifications or fakes. Decentralized storage systems like IPFS (Interplanetary File System) store actual content off-chain but link cryptographic hashes to the blockchain for verification. Think of it as having a tamper-proof receipt or certificate attached to every piece of media, confirming its origin and identity. How much easier would life be, and how much more assured would you feel once you spot the seal that confirms originality? I know I would heave a sigh of relief. Real-World Blockchain Applications Are Already Here The great thing is, you don’t have to just imagine this happening or wait expectantly for it to become a reality—it’s already happening. Toniq Labs uses NFTs (Non-Fungible Tokens) to represent digital assets’ origin and ownership. Toniq Labs Truepic provides verified photos and videos by cryptographically certifying content’s origin and integrity for journalism and insurance claims. Truepic Adobe’s Content Authenticity Initiative embeds origin metadata into creative files to track authenticity and modifications, integrating blockchain to store this metadata securely. Adobe’s Content Authenticity Initiative embeds Platforms like po.et enable creators to timestamp and claim ownership of written content metadata, helping verify publishing rights and originality. po.et po.et Other use cases include journalistic content verification to fight fake news, scientific data authenticity to prevent research fraud, and supply chain transparency applied to digital goods. These projects empower creators and consumers by making authenticity verifiable and transparent, building trust in digital content. Challenges on the Road to Mass Adoption While blockchain can make our information generation more authentic, several hurdles remain: Adoption and Usability It’s not enough to have blockchains; convincing creators to encrypt their work on blockchain takes effort. Then there’s the need to make verification easy and seamless for average users. Scalability Current blockchain networks have limits on transaction speed and cost, which challenge mass adoption for content verification. For example, Ethereum’s gas fees and transaction delays can be prohibitive for small-scale content verification. Privacy vs Transparency Blockchain’s transparency raises questions about how much transparency is too much transparency? What about sensitive information creators don’t want revealed, like identity or location? Exposing such data risks misuse. Solutions include off-chain storage, zero-knowledge proofs, privacy-focused blockchains, and permissioned blockchains where access is controlled. But balancing transparency and privacy remains a delicate, ongoing trade-off. Interoperability Different blockchain systems and protocols must work together for wide-scale effectiveness. Without cross-chain compatibility, users may experience friction, slowing adoption. Fragmentation may occur if verification tools are limited to specific blockchains. Solutions like cross-chain bridges—Polkadot, Cosmos, Chainlink — are bridging these gaps. Polkadot, Cosmos, Chainlink Regulatory and Ethical Questions Because blockchain is decentralized, questions remain: Who oversees content verification? What laws apply? Who handles disputes? How to comply with privacy laws like GDPR when data is immutable? Ethical questions arise about who decides “truth,” risks of weaponizing verification to silence dissent, and potential marginalization of less tech-savvy users. Collaborative efforts among regulators, technologists, and ethicists are essential to create frameworks ensuring blockchain tools are fair, transparent, accountable, and privacy-respecting. The Road Ahead: Why Blockchain is Our Best Bet Despite these challenges, blockchain stands out as our safest bet to deal with the AI-generated content pandemic. Positive signs include: Growing interest from governments and media organizations in blockchain for verification.


Combining blockchain with AI-powered content scanners for layered authentication.


Developing open-source standards and protocols focused on digital content authenticity.
According to a 2023 Deeptrace report, deepfake videos increased over 900% between 2019 and 2023. A 2024 Gartner prediction estimates that by 2026, 75% of online content will be synthetically generated. The global blockchain market is expected to reach $67.4 billion by 2026 (ResearchAndMarkets), signaling strong momentum for such applications.
Given these trends, it’s only a matter of time before a decentralized, blockchain-backed system for content authenticity becomes a foundational trust layer of the internet—critical in combating misinformation and AI-generated fake content.
How Do We Move Forward?
I have good news and bad news. The bad news is, we will have to stay vigilant for AI-generated content for quite a while.
The good news is, while blockchain might not be a cure-all, it is a key enabler for verifying digital truth. However, we won’t get the full benefits if we don’t start adopting these verification systems soon.
My opinion? Innovators, creators, and platforms must collaborate quickly to restore trust in the digital world, using blockchain as a promising piece of this complex puzzle.
As digital citizens, staying informed and supporting technologies like blockchain can help protect the truth. The fight against AI-generated misinformation needs all of us. Growing interest from governments and media organizations in blockchain for verification. Growing interest from governments and media organizations in blockchain for verification. Combining blockchain with AI-powered content scanners for layered authentication. Combining blockchain with AI-powered content scanners for layered authentication. Developing open-source standards and protocols focused on digital content authenticity.
According to a 2023 Deeptrace report, deepfake videos increased over 900% between 2019 and 2023. A 2024 Gartner prediction estimates that by 2026, 75% of online content will be synthetically generated. The global blockchain market is expected to reach $67.4 billion by 2026 (ResearchAndMarkets), signaling strong momentum for such applications.
Given these trends, it’s only a matter of time before a decentralized, blockchain-backed system for content authenticity becomes a foundational trust layer of the internet—critical in combating misinformation and AI-generated fake content.
How Do We Move Forward?
I have good news and bad news. The bad news is, we will have to stay vigilant for AI-generated content for quite a while.
The good news is, while blockchain might not be a cure-all, it is a key enabler for verifying digital truth. However, we won’t get the full benefits if we don’t start adopting these verification systems soon.
My opinion? Innovators, creators, and platforms must collaborate quickly to restore trust in the digital world, using blockchain as a promising piece of this complex puzzle.
As digital citizens, staying informed and supporting technologies like blockchain can help protect the truth. The fight against AI-generated misinformation needs all of us. Developing open-source standards and protocols focused on digital content authenticity. According to a 2023 Deeptrace report, deepfake videos increased over 900% between 2019 and 2023. A 2024 Gartner prediction estimates that by 2026, 75% of online content will be synthetically generated. The global blockchain market is expected to reach $67.4 billion by 2026 (ResearchAndMarkets), signaling strong momentum for such applications. Given these trends, it’s only a matter of time before a decentralized, blockchain-backed system for content authenticity becomes a foundational trust layer of the internet—critical in combating misinformation and AI-generated fake content. How Do We Move Forward? I have good news and bad news. The bad news is, we will have to stay vigilant for AI-generated content for quite a while. The good news is, while blockchain might not be a cure-all, it is a key enabler for verifying digital truth. However, we won’t get the full benefits if we don’t start adopting these verification systems soon. My opinion? Innovators, creators, and platforms must collaborate quickly to restore trust in the digital world, using blockchain as a promising piece of this complex puzzle. As digital citizens, staying informed and supporting technologies like blockchain can help protect the truth. The fight against AI-generated misinformation needs all of us.

How Blockchain Can Help Us Trust What We Read and See

Science fiction has been an incubator for Utopian visions of space travel and extrasolar colonization for decades. Each TV show, novel, and movie offers a different means of traversing the stars within human lifespans, akin to how one may drive a car or ride a plane from place to place. To explore the vast expanse of space in human timescales, these stories usually utilize a method of FTL (faster than light) travel aboard grand starships. Many of these methods of FTL travel are rooted in scientific fact and may even be possible from a modern physics standpoint. They have inspired us to believe that we may be well on our way to colonizing the galaxy within the next millennium. methods of FTL travel methods of FTL travel But what if warp drives can not exist? What if wormholes are impossible to manufacture? What if the laws of physics are so strict that we are indeed tied to the dreaded speed of light forever? These ever-present possibilities would seem to make interstellar travel within human lifespans a romantic fantasy. As I was contemplating that thought, an idea occurred to me: what if we could use other stars as interstellar starships to ferry ourselves across the cosmos? Hypervelocity Stars All stars in our galaxy orbit the galactic center (GC). Stars nearer the galactic center tend to have higher velocities than stars that orbit farther out in the galactic arms. This means that stars that are relatively near each other should have similar orbital velocities. But this distribution is not perfect. Due to imperfections in the circularity of stellar orbits, known as eccentricity, stars that are nearby to one another can have very different relative velocities. Alpha Centauri, for example, which should have a relative velocity of just a few meters per second with the standard orbital velocity distribution boasts an interstellar speed of 20 km/s with respect to the Sun. This speed is faster than the fastest spacecraft ever launched by the human race to date. If you look at our other nearby stellar neighbors, Alpha Centauri is not unique. Most stars in our stellar neighborhood today were not within 1000 light years of us one galactic orbit ago due to differences in their orbits. If you look at the GIF above, you can see that the majority of the stars plotted seem to remain in a loose cloud around the sun. These are “normal” stars, from a stellar kinematics point of view, with relative velocities on the order of 100 km/s or less. If you look closely, you can see that some of the stars seem to fling off the edge of the diagram, and then come speeding back in to meet the yellow dot that is our sun. These are known as runaway stars, with relative velocities above 100 km/s. But there is a class of rapidly moving stars that are not plotted above. A hypervelocity star is defined as a star that has exceeded the escape velocity of the galaxy. Several hypervelocity stars have had speeds clocked in above 1000 km/s, which is 1/3 of 1% of the speed of light. This velocity is fast enough to traverse the diameter of the solar system in a little over 100 days. Our fastest deep space probes take decades. By utilizing this difference in velocity, one could traverse great distances through space, sort of like a cosmic hitchhiker, by perhaps terraforming a planet around such a star and setting up a long term colony. The idea is tantalizing. Traveling through space on a planet around a star eliminates a lot of the known dangers of interstellar travel. Cosmic rays, blue-shifted light, micrometeorites, and deadly ions would be filtered out and nullified by a planet protective atmosphere and magnetic shield. People could live out normal day to day lives on a planet, unworried about forgoing the pleasantries of living on a cramped, tight spaceship. All the while, the star would be travelling away from the Sun into parts of the galaxy unknown. In many ways, it would seem to be much more practical than sending out enormous, complex interstellar spacecraft. However, a more detailed analysis brings some unforeseen issues to light. First of all, the nearest hypervelocity stars are more than 50,000 light years away. We would have to get ourselves there first to hitch a ride, and if you had the technology to do that, you may as well just explore the universe on your own. Secondly, hypervelocity stars are very rare, with an estimated value of only 1000 or so in the entire Milky Way galaxy. Even if there were a rare hypervelocity star that were making a close pass to the sun in the near future, we would still have to launch a spacecraft to match it is relative speed, at which point one may ask why we didn’t just use that speed to go somewhere we actually want to go. Furthermore, hypervelocity stars may not even have their own planets by the nature of their existences. Hypervelocity stars only exist because of close encounters with black holes or other dense objects, which is what sent them off at such high velocities to begin with. It would be unlikely that most planetary systems would survive such an encounter unperturbed. Even if you wanted to use a closer, slower star to travel the cosmos instead, it is important to remember that 1/3 of 1% of the speed of light is not very fast on a cosmic scale. Even at this astonishing speed, it would still take well over a millennium to cover the distance to Alpha Centauri. A slower star would take even longer. Shkadov Engines (Stellar Engines) If your goal was instead to use your home star as a starship, you may be on a path towards a much more difficult, albeit slightly more versatile application of stellar propulsion. In 1987, physicist Leonid Shkadov proposed that advanced civilizations may be able to explore the galaxy from the comfort of their home star system with what he called a “stellar engine”. Like the Dyson sphere, it ended up inheriting its creator name. A Shkadov engine is made up of three components: a star, a Dyson swarm, and a massive, static reflector. The Dyson swarm is only used for energy collection to power the advancing civilization. The real magic happens between the reflector and the star. The reflector is placed at a Goldilocks distance where outward radiation pressure from solar wind is equal to the inward gravitational force of the home star mass. This makes the reflector stationary with respect to the star. However, the force of reflecting a fraction of a star light in one direction propels said star in the opposite direction. It is not much (relative to the mass of a star), but over the course of a long time, this continuous force can add up to an appreciable velocity. Due to the immense timescales involved, the star planetary system would be dragged along peacefully with the star as it accelerated through space, essentially making the entire solar system an interstellar starship. Any civilization venturing to execute such a project would be in no hurry to get anywhere. For a sun-like star with half of its light being reflected backwards, an acceleration of 6.4*10^-13 m/s² would be imposed on the system. This is incredibly slow. Over the course of a million years, such an engine would only cover about 0.03 light years and attain a velocity change of about 20 m/s; no faster than a car on a highway. After a billion years, the system could potentially reach 20 km/s, traversing tens of thousands of light years from its initial orbital trajectory. However, for the amount of materials, energy, and time required to build such a megastructure, this too would be an inelegant solution for galactic exploration. An example where a Shkadov engine could be more practical is in the conservation of a species home planet. Perhaps a rapidly advancing species knows that their home star will bloat to a red giant within a few hundred million years, and wants to place their home planet around a new star to preserve the relic of their history. Using a Shkadov engine, which would be easy for a Type III Kardachev civilization to manufacture, said species could slowly guide their home system towards another, younger star. Once there, they could use some fancy orbital dynamics to place their planet at a safe distance around the new star. When complete, the stellar engine could continue to push the dying star far away from the new star system so that it could explode at a safe distance. Conclusion Using stars to explore the galaxy is slow and tedious. Stars are simply too massive to manipulate easily for interstellar travel on human timescales. Hypervelocity stars are rare and distant, and getting to them requires the same ability we would hope to gain from them. Shkadov engines may have certain specific applications in the far future, but as of now our advancement outwards and into the cosmos seems to be limited by our own technology. to from This may sound discouraging, but I am hopeful that one day humanity will find its place among the stars. Nature has laid out some rigorous ground rules for us to follow in terms of space travel. It is our duty as a species to bend these rules as far as we can to allow us to discover the universe, so that we may learn more about our own origin in the process. Zipping around the cosmos in grand starships with warp drives may turn out to be impossible, and steering stars may be impractical, but these setbacks cannot stop the human race from doing what it has always been destined to do: to explore space.

Can We Hitch a Ride Through Space on Hypervelocity Stars?

Ці можам мы гуляць у космос на гіпершчаслівых зорках?

Können wir eine Fahrt durch den Weltraum auf Hypergeschwindigkeitsstern schlagen?

¿Puedes viajar a través del espacio en estrellas hipervelocitadas?

Megtalálhatjuk a hipersebességű csillagokat az űrben?

We Hitch a Ride Through Space on Hypervelocity Stars(ハイパースピードの星に宇宙を乗り越えられるか?)

តើយើងអាចធ្វើដំណើរតាមរយៈអ៊ីនធឺណិតនៅលើអ៊ីនធឺណិត Hypervelocity?

We Hitch a Ride Through Space on Hypervelocity Stars (우리는 하이퍼브로시티 스타를 통해 우주를 여행 할 수 있습니까?)

Ar galime nuvažiuoti per kosmosą ant hipersnelės žvaigždžių?

Vai mēs varam braukt cauri kosmosam uz hipervērtības zvaigznēm?

Azontsika atao ve ny mandehandeha amin'ny habakabaka amin'ny kintana Hypervelocity?

We Hitch a Ride Through Space нь Hypervelocity Stars дээр аялах боломжтой вэ?

நாம் Hypervelocity இல் ஒரு விமானத்தில் பயணம் செய்ய முடியுமா?

Focus Plant is one of my favorite apps to stay productive, but since I’m using the free version, it comes with a price: endless ads. Weirdly enough, about 80% of those ads are for loan apps. That got me thinking, what data did these apps collect about me to decide I desperately needed a loan? Beyond that, I started to wonder how these loan companies actually survive. Do people scam them? Or are they the ones running the scam? Most of them offer tiny loan amounts, probably as their way of managing risk. But still, these low-budget ads promise things that sound too good to be true: no collateral, no real verification, tiny interest rates. It all feels a bit off. them Personally, I don’t plan on borrowing money anytime soon and even if I did, I wouldn’t trust those platforms. But what if I did need a loan someday? Suppose I had a world-changing idea but zero resources to fund it. As a student, there’s no way a traditional bank would take me seriously, and those sketchy loan apps aren’t exactly confidence-inspiring. That question stuck with me. If I needed money but couldn’t get it through a bank or a suspicious app, then what? Let’s hold on to that idea for a second and talk about something promising: Blockchain Technology. Blockchain and Finance Ah, ‘’Blockchain”. A word everyone seems to have heard, but few really understand. Blockchains are essentially public ledgers where transactions are permanently recorded. really Bitcoin was the first big application of blockchain, proving you could send money directly between people without trusting a bank. But its potential goes far beyond cryptocurrency. One area it is now disrupting is lending and credit. What if you could prove you’re a good borrower to anyone, anywhere, without needing a bank to vouch for you? What if your repayment history lived on an open, tamper-proof record you could take with you, no matter where you lived? That’s the kind of possibility blockchain presents. And that brings me back to my earlier train of thought: is there a way for blockchain to connect with loans and credit scores so that borrowing money finally makes sense? That’s where Creditcoin comes in. Creditcoin The Lack of Credit Infrastructure Problem According to World Bank, an estimated 65 million firms or 40% of formal micro, small and medium enterprises (MSMEs) in developing countries, have an unmet financing need of $5.2 trillion every year According to World Bank, an estimated 65 million firms or 40% of formal micro, small and medium enterprises (MSMEs) in developing countries, have an unmet financing need of $5.2 trillion every year World Bank In many lower-income countries, the idea of a credit score just doesn’t exist. There’s no formal system to prove you’re trustworthy when you need to borrow money, so you get shut out before you even start. That forces people to rely on friends, family, or worse, loan sharks who charge sky-high rates and threaten them if they can’t pay back. Banks don’t make it any easier. Their requirements are rigid, with complicated paperwork, collateral demands, and painfully slow approvals. If you’re someone earning daily wages or running a small cash-based business, you’re basically locked out. And even if you manage to get a loan informally, there’s no record to build on for the future, so every new loan feels like starting from scratch. It traps hardworking people in a cycle of poverty, not because they aren’t capable, but because there’s no trusted way to show they can be responsible borrowers. Lenders also lose out. Without any transparent data, they take big risks lending to strangers, so they usually keep amounts small and terms harsh, or avoid lending altogether. It’s a broken system on both sides. That’s the massive gap Creditcoin is trying to close. The Creditcoin Creditcoin was built to change this. It’s a public blockchain network where financial institutions and lenders can record how loans perform, whether they’re paid back or not. Once a borrower takes a loan and repays it, that data is locked on the blockchain permanently, tamper-proof, and publicly viewable. Over time, that gives borrowers a real, provable credit history that they can carry anywhere. For lenders, it means they finally have trustworthy, transparent data to make smarter lending decisions and reach more people. The network essentially connects investors and fundraisers under clear, predefined terms. When a loan is repaid, Creditcoin permanently records it on-chain, making that data available for future credit evaluations. By cutting out unnecessary intermediaries, it allows for more competitive interest rates and flexible loan conditions that traditional systems often can’t match. It also supports sharing credit information without exposing private personal details. Any cryptocurrency can be lent on the Creditcoin network, with the native token (CTC) used to pay fees for lending and borrowing transactions. Creditcoin is built on a Nominated Proof of Stake (NPoS) framework, where validators stake tokens to earn the right to produce and finalize blocks. All validators have equal rights regardless of the size of their stake. For those who don’t want to run their own node, there’s the option to participate as a nominator, delegating your stake to trusted validators and sharing in their rewards or penalties. Who Built Creditcoin? Launched in 2019 by Gluwa in collaboration with Aella, Creditcoin is built on EVM-compatible technology to support decentralized credit. Aella, which functions almost like a digital bank, offers loans, savings, bill payments, and investment products across developing economies. Its mission is to make financial services easy, fast, and accessible. Gluwa Aella Gluwa, on the other hand, founded by Tae Ho, is a blockchain technology company building decentralized financial and physical infrastructure. Beyond Creditcoin, it also developed Spacecoin, a decentralized network of nanosatellites that aims to deliver global, trustless internet connectivity on top of Creditcoin’s blockchain. Tae Ho Spacecoin Creditcoin in Action Since it launched, Creditcoin has handled over five million transactions and even partnered with Nigeria’s central bank to help roll out the eNaira, Nigeria’s Central Bank Digital Currency (CBDC). They’re also talking with governments in Liberia, Ghana, and Sierra Leone to expand this impact. eNaira, Nigeria’s Central Bank Digital Currency (CBDC) Already, Creditcoin has disbursed over 100B Naira to over 2 Million Nigerians alongside its partner Aella allowing them to build on-chain credit scores and gain access to necessary funding. It’s become one of the pioneers of what’s now called on-chain lending. Understanding On-Chain Lending On-chain lending is basically borrowing and lending through smart contracts on a blockchain, instead of through a traditional bank. It’s open, permissionless, and transparent by design. Big players in this sector include Aave, Compound, and Yearn. But of course, it isn’t perfect. There are still challenges around verifying people’s real identities, protecting smart contracts from bugs, dealing with volatile crypto collateral, and navigating unclear regulations. How Creditcoin Builds Trust Creditcoin addresses a lot of those challenges by keeping a public, tamper-proof record of repayment history. Borrowers can build a visible track record, while lenders get clear evidence instead of making blind bets. Through partnerships with licensed fintechs, Creditcoin can verify people’s identities off-chain while keeping their repayment data on-chain, so you get both transparency and compliance. Plus, because blockchain records are cryptographically secured, it’s incredibly hard for anyone to tamper with them. Since these credit histories are visible worldwide, Creditcoin also makes cross-border lending possible. Borrowers and lenders in different countries can finally verify each other without depending on outdated, disconnected local credit bureaus. That means capital can move from developed markets to emerging economies far more easily. Why On-Chain Lending Matters Traditional lending is full of hidden fees, paperwork, and painfully slow systems. On-chain lending changes that by putting the whole process on a blockchain, where everyone can see what’s happening in real time. For communities without proper credit systems, that’s huge. It lets people build up a transparent, provable credit reputation from nothing, without shady middlemen. It also means that if I ever did have that “world-changing idea”, I could potentially get a loan from anywhere, with confidence that the lender is looking at my real repayment record, not some fuzzy guess. Technical Innovations to Watch One thing that makes Creditcoin so interesting is its EVM compatibility, i.e it can work with apps and smart contracts built for Ethereum, tapping into a global network of innovation and developers. That flexibility makes it easier to upgrade and stay relevant as the financial world evolves. What really blows my mind is how Creditcoin connects with Spacecoin’s nanosatellite network. Imagine someone in a completely remote village, with no bank and no internet, suddenly connecting through a satellite to the blockchain. They could start building a credit history with nothing but a simple device, transforming their entire community’s future prospects. Rethinking Financial Trust If there’s one thing I’ve learned from seeing all those shady loan ads, it’s how fragile trust can be. When lenders hide their true intentions, when borrowers default, people get burned, and everyone loses faith in the system. Blockchain doesn’t magically fix everything, but it offers a kind of trust built on verifiable data instead of promises. Yes, code can have bugs and human errors, but at least it’s open for everyone to check. That feels far more reassuring than trusting a random loan app that won’t even list a phone number. In the end, that’s what makes Creditcoin so powerful. It doesn’t demand blind trust, it gives you the receipts. By helping people build provable credit reputations, it reduces the need for massive collateral and opens up fairer lending for the unbanked. In a world where so many financial players have failed us, that might be exactly what we need. Sources Creditcoin Whitepaper
Creditcoin Blog
Small and Medium Enterprise Finance by World Bank
Onchain Credit Scores
Spacecoin Creditcoin Whitepaper Creditcoin Whitepaper Creditcoin Whitepaper Creditcoin Blog Creditcoin Blog Creditcoin Blog Small and Medium Enterprise Finance by World Bank Small and Medium Enterprise Finance by World Bank Small and Medium Enterprise Finance by World Bank Onchain Credit Scores Onchain Credit Scores Onchain Credit Scores Spacecoin Spacecoin Spacecoin

Stories, News & Mentions about NESTIMATE

Trending Topics

Classic

Neon Noir

Minty

Newspaper

HN StartUps