DEV Community: Milos Zivkovic

How to Become Better Software Estimator?

Milos Zivkovic — Tue, 30 Mar 2021 09:19:08 +0000

Estimating is difficult. Estimating software development is even harder.

We all miss estimation targets. We miss at estimation, but also when delivering on time.

Here’s what you can do to improve the software estimates.

Look at previous tickets

Track time. Track time on previous tickets. Use this as a reference point.

Make a map of tickets. Map of story points to tickets. Here’s an example. Refer to this when making estimates.

Take time to process tickets

Estimates given at the coffee machine will (like the coffee) come back to haunt you. — The Pragmatic Programmer: From Journeyman to Master 1st Edition

Estimate with different precision. Days are not enough? Give estimates in weeks and months.

Give rough estimates. Missing the mark then doesn’t look so bad with rough estimates.

http://www.agilenutshell.com/cone_of_uncertainty

Determine the scope. Understand the domain first. Know exactly what needs to be done. Do proper research.

Break the task down. Tasks exceeding one sprint can be decomposed. Build estimates on decomposed tasks.

Add contingency points, to cover the errors and unknowns. You’re not sure about an estimate?

Create a spike.

Investigate. Build proof of concept, if possible. Estimate after PoC.

More people working on tasks causes more friction. More communication, synchronization, and work are needed.

You never have two same tasks. If they were the same, nothing to work on. Tasks differ. Differ in the personnel, requirements, and priority.

Key points to include when estimating:

Days off
Communication between teams
Testing
Design updates
Changelog updates

Rely on team knowledge

Use planning poker. Consensus-based estimation. Everyone gives high-level estimates, and everyone should agree.

Fibonacci sequence is used for estimations. There’s no way of doubling the estimates. There’s no way of cheating the system.

After voting, estimators explain their votes. The highest and lowest estimates go first.

Planning poker improves team coordination. The discussion takes place, and everyone participates. With this technique, the focus comes on code quality.

This technique is lightweight. There’s no anonymity, but interaction improves. The only overhead is meetings, refinements, and grooming sessions.

Scrum poker combines knowledge. Combines knowledge both from juniors and seniors. Whole team knowledge is there when estimation takes place.

What to avoid?

Don’t estimate under pressure. There can be pressure from peers, businesses, or other factors.

You’ll never give a good estimate under pressure.

You’re either going to give a low estimate, to satisfy the pressure. You won’t go for the higher one, since you’ll feel embarrassed.

Don’t look into tickets with dependencies. Estimate tickets from the bottom up. Contingency always fails to compensate for the unknowns.

Don’t estimate ambiguous tasks.

Don’t give estimates before talking with a domain expert. This can be senior in your team, or business analyst.

Don’t estimate every ticket. There’s no need to estimate bugs. Sometimes they take too little, sometimes a lot. Effort spent on estimating bugs is useless.

Don’t estimate non-essential tasks. Estimate critical ones.

Estimates are just a way to communicate — Deadlines And Estimates In Startups

Don’t be certain about estimation. There’s no way to forecast software estimations. Don’t give percentages of confidence when estimating.

Sometimes you don’t meet the estimate. Inform your scrum master about it. Inform on time. Not before the sprint ends.

Conclusion

What can you do to improve estimation?

Take note of previous work
Operate on team knowledge to tackle estimation
Use contingency to make better estimates
Prefer face-to-face conversations when estimating
Over-estimate
Don’t under-estimate, leave your ego at home
Don’t be certain, it’s an estimate
Avoid estimating non-granular tasks
Avoid estimating tickets with dependencies

Resources

Software development cost estimation approaches — A survey Barry Boehm, Chris Abts, and Sunita Chulani

How to respond when you are asked for an estimate?

Richard Clayton - Software Estimation is a Losing Game

Deadlines And Estimates In Startups

Photo by fauxels from Pexels

Features Java 16 Brings to Developers

Milos Zivkovic — Sun, 28 Mar 2021 20:33:02 +0000

Živković Miloš

Learn about pattern matching, sealed classes, and more new Java features.

Java needs no introduction. It’s a programming language with many years under its belt. Recent updates brought several new features to the language: Sealed classes, pattern matching, and additional safety measures.

Sealed classes

JEP-397

The motivation behind sealed is to restrict concrete classes. Restricting concrete classes, will control implementation, and provide support for pattern matching.

// keyword here is sealed which enables permits

// permits lists classes that can extend sealed class public abstract sealed class Shape

permits Circle, Rectangle, Square { ... }

With basic interfacing, you don’t get reflectiveness. You don’t know about a finite set of concrete implementations.

With sealed classes, you get this reflective behavior. You know about the kind of types, you can have in your domain.

Enums tell about a finite set of values. Sealed classes tell about a finite amount of kind of values.

sealed interface Celestial

permits Planet, Star, Comet { ... }

final class Planet implements Celestial { ... }

final class Star implements Celestial { ... }

final class Comet implements Celestial { ... }

This hierarchy does not, however, reflect the important domain knowledge that there are only three kinds of celestial objects in our model. In these situations, restricting the set of subclasses or subinterfaces can streamline the modeling. — JEP-397

Warnings for value-based classes

JEP-390

Primitive wrapper classes are value-based classes. Examples of value-based classes are:Byte,Short,Integer,Long,Float,Double,Boolean, andCharacter). More on value-based classes can be found here.

As they are immutable objects, it is pointless to use constructors.

To prevent misuse, new annotation is around. This will put warnings each time, the compiler finds a value-based class constructor.

@jdk.internal.ValueBased

Encapsulation of JDK internals removed by default

JEP-396

This is to encourage users to use standard Java API. Still, you could choose relaxed encapsulation. If needed, but try to avoid it.

You’ll need to add props to the launcher of JVM. Below you can see the possible args, you can pass in. More on the arguments can be found here.

--illegal-access= permit | deny | debug | warn

Although this is embraced in JDK 16, you can face problems with earlier versions. This change was proposed after the JDK 9 was released.

Even today, with e.g. Java >=9, certain build tools print out “reflective access”-warningswhen building Java projects, which simply “feels not ready”, even though the builds are fine. — source

Pattern matching

JEP-394

Pattern matching exists a long time. You can find it for example in Elixir.

In Java, there’s a lot ofinstanceofconditions. Motivation to reduce operations leads to pattern matching.

Pattern matching allows the desired “shape” of an object to be expressed concisely (the_pattern_), and for various statements and expressions to test that “shape” against their input (the_matching_). — JEP-394

// a lot of boiler plate codeif (obj instanceof String) {

String s = (String) obj; // grr...

...

}

With pattern matching, we could get this code. Reduces boilerplate, does the casting, and declares the variable.

if (obj instanceof String s) {

// Let pattern matching do the work!

...

}

Pattern variable is in the scope where it matches. Thus code like this is valid.

if (a instanceof Point p) {

// p is in scope

...

}

// p not in scope here

if (b instanceof Point p) { // Sure!

...

}

You never have to worry about names now. Reusing existing names is possible if scopes are different.

What does pattern matching improve?

Reduces explicit casts. Which gives more readable code, in equality methods.

return (o instanceof CaseInsensitiveString) &&

((CaseInsensitiveString) o).s.equalsIgnoreCase(s);// to thisreturn (o instanceof CaseInsensitiveString cis) &&

cis.s.equalsIgnoreCase(s);

Look at the next example. If this conditiono instanceof String s, evaluates to true,sgets assigned a value. On the contrary,shas no value if pattern matching fails.

Thus this code can complete normally. You don’t have an unreachable code.sgets value assigned if conditional passes, if notsis safely discarded.

public void onlyForStrings(Object o) throws MyException {

if (!(o instanceof String s))

throw new MyException();// s has value at this point

System.out.println(s);

...

}

Conclusion

Java is evolving. Causes a lot of breaking changes. Causes a lot of problems.

Constant Java updates

Even so, we do need to adjust. Use new features so we create better software.

These are few features, I would take away. You can read more, in the section below.

Resources

JEP draft: Pattern Matching for the switch (Preview)

JDK 16: The new features in Java 16

Photo by Christina MorillofromPexels

3 Code Metrics Every Developer Should Know

Milos Zivkovic — Sun, 28 Mar 2021 16:44:51 +0000

Here are 3 high-quality code metrics.

Živković Miloš

We need code metrics, to pinpoint smelly code. We all know bad code when we see one. Even so, sometimes it slips through.

Bad code resides in big codebases where developers come and go.

The leaving developer doesn’t care, does a bad job, and leaves. You join the team and encounter a code mess.

You need valuable code metrics to combat bad code.

Even when you see team members writing bad code, you need to point it out. It will, sooner or later, end up on your plate.

1. What is code churning?

Churn is a measure of how often a file changes. Files that change more have higher churn. — Sandi Metz

Complex code with most changes lives in the top right corner. This is yourUtilclass. This is yourManagerclass. This is where your core logic resides, so no one wants to touch it.

Either way, you make changes, causing bugs and tech debt along the way.

Michael Feathers talks about this code metric. He even developed softwareto find these churned files. These are the best candidates for refactoring.

When can we use this metric? Use it in your technical grooming sessions. Pinpoint which most churned class, evaluate tech debt, and start refactoring.

Most software quality measuring is static. Sonarqube, lines of code, and other code quality metrics. Code churn metric adds another dimension with version control.

Code churning is done in big classes. We get pulled into it, as Sandi says, it has its own gravitational force.

Why add a small helper class, when you add logic in a 500 line class? We are all guilty of this behavior. The need to iterate faster leads to more code churn.

More on code churning implementation in the article below.

Why I Made My Own Code Quality Tool, Attractor

2. What is the ABC metric?

The first mention of this metric was in an articleby Jerry Fitzpatrick. This is an extension of cyclomatic complexity.

Not only Conditions make up this metric, but also Assignments and Branches. Hence the name Assignments, Branches, Conditions metric.

ABC is a measure of complexity. — Sandi Metz

ABC metric tells more about the code complexity. If the score is high, your code is complex.

For the sake of this article, I’ll post the formula. For those math nerds, reading this here is the formula. There are few tools that calculate this metric, and you can find them in the wilderness.

|ABC| = sqrt((A*A)+(B*B)+(C*C)) - calculating ABC score

I am a Java developer. How can I count the As, Bs, and Cs in Java?

https://www.win.tue.nl/~wstomv/edu/2ip30/references/ABCmetric.pdf—Pg. 8 in PDF

Why should we care about this metric? What are the benefits of it?

Humans make mistakes, metrics don’t._You can’t manage what you can’t measure._Use metrics to improve. Metrics won’t lie.

3. What is cyclomatic complexity

An algorithm that counts the number of unique execution paths through a body of source code. — Thomas J. McCabe

You’ve seen code with a lot of if-else blocks. Example of bad cyclomatic complexity, or high score of cyclomatic complexity.

Writing OO programs leads to reduced cyclomatic complexity. Extract conditional logic into separate classes. Then inject it into your class.

I wrote more on how to reduce this metric here. Adhering to OO principles vastly reduces this metric.

When you face code with a cyclomatic complexity score of 10, you should refactor.

McCabe states developers who knew structured programming, wrote optimal code. Even before he invented the metric. I wrote about developing structured programs here.

Code with high cyclomatic complexity is hard to test. By definition, tests should cover all execution paths. Think of code with a cyclomatic complexity of 50, you’d need 50 test cases.

Sandi Metz points the reverse way of using this metric. Use it to know if you’ve written enough tests. For example, you have a code with a complexity score of 40 but only 20 tests. You need more tests to cover all paths.

Conclusion

Code metrics are used to navigate us through the project. They tell us where the stinky code part is living. Where we need to clean up.

No one says you need them. For your hobby project, local gym, or MVP they might not be of benefit.

Things get interesting if the project succeeds. Codebase grows bigger, and then they are essential for the life of your project.

I use metrics, at least the cyclomatic complexity, to break up my code. This leads to testable code and reasonable code chunks.

You should take away at least one metric, and implement it today.

Resources

99 Bottles Sample PHP - Sandi Metz

Getting Empirical about Refactoring

Breaking Up the Behemoth - Sandi Metz

Code Churn — A Magical Metric for Software Quality — DZone Performance

Photo byThisIsEngineeringfromPexels

How to Have a Better Stack Overflow Experience

Milos Zivkovic — Sun, 28 Mar 2021 08:29:03 +0000

3. Look at the comments first

Original on Živković Miloš

Developers search Stack Overflow daily. In multiple tabs, of course.

When we encounter related answers, we get hyped. Click the relevant links to find out more. The link is dead. Time wasted.

We try answer’s code snippet. Only to find out it is deprecated, or non-working.

What can we do to prevent these situations?

1. Lookout for obsolete answers

I recently did an upgrade of Hybris and stumbled into an issue. Started looking at our closed source, answers.sap.com. Found myself looking into obsolete documentation and obsolete answer.

The problem of this kind reproduces on StackOverflow. Looking into ever-changing frameworks for answers is hard.

Look at comments, comments describe the answer better.

75% of comments, can reveal if the answer is obsolete².

Most obsolete answers are around NodeJS, AJAX, Android, and ObjectiveC². I would argue a lot of answers, for new frameworks are obsolete.

Look if the answer applies to your environment. “Works for Angular 6”, and you’re face problems in higher versions.

2. What can you ask on StackOverflow?

Most of the questions live in a few categories³.

Non-working code
Unknown implementation
How to implement algorithm (not related to the domain)
Suggestions for new technology

Don’t ask domain-specific questions. You will rarely get an answer. Nobody will go in-depth for nothing.

Use Q&A sites, to find answers for task-specific issues.

You have problems asserting exceptions in the JUnit test. You’ll get a valid answer since the question is task-specific.

Ask about the core issues, issue with JDK, what is supported in the new version of NodeJS. These environmental questionsoften get valuable answers.

3. Look at the comments first

75.6% of tagged comments are informative¹.

Most users write comments in addition. I’ve recently added my way of solving the issue, as an addition.

We like confirmation comments. You see a lot of them.“It works”, or_“working for me on x.x version”_. You could use those as a confirmation of a possible fix.

There’s the other way, with rejecting comments. This doesn’t work or doesn’t suit the question well. You can use those to avoid the answer.

You could see comments in the form of updates. The solution changes because of new software versions. You shouldn’t miss those. They make or break the actual answer.

Conclusion

What should you take away from this article?

Look at obsolete answers. Read more comments.

Learn what you can ask, and then ask. Don’t ask domain-specific questions. Ask in a more generic way if possible.

Resources

[1] Zhang, Haoxiang & Wang, Shaowei & Chen, Tse-Hsun Peter & Hassan, Ahmed E.. (2019). Reading Answers on Stack Overflow: Not Enough!. IEEE Transactions on Software Engineering. PP. 1–1. 10.1109/TSE.2019.2954319.

[2] Zhang, Haoxiang. (2020). On the Maintenance of Crowdsourced Knowledge on Stack Overflow.

[3] M. Allamanis and C. Sutton, “Why, when, and what: Analyzing Stack Overflow questions by topic, type, and code,” 2013 10th Working Conference on Mining Software Repositories (MSR), San Francisco, CA, USA, 2013, pp. 53–56, doi: 10.1109/MSR.2013.6624004.

Photo byHelena LopesfromPexels

How Good Developers Fix Vulnerable Apps?

Milos Zivkovic — Sun, 28 Mar 2021 08:15:38 +0000

How to separate insecure from critical logic?

Follow me on Medium
Original article

Where does business and UI logic live?

These are the business rules, validations, and calculations that operate on the data as it is brought into an information system or displayed by it. — Martin Fowler

Your services are in the business layer. Business rules that you apply to data, and create conclusions on the data.

Your controllers are in the UI layer, responsible for UI, pages, and simple logic around them.

Layered Architecture

Why is the business layer critical?

Let’s explain in layman’s terms.Laurent S.has a great explanation for this topic. I’ll try to deliver his words, with my own opinion attached.

source

Let’s look at the truck loading process. There are two workers.

One loads the truck, the worker, one is supervising, the supervisor. Worker represents presentational logic. Supervisor — business rules.

The supervisor cares about the truck weight.How much the truck can carry?— business rule.

The worker puts the boxes in the truck. The worker decides_where to put the box_— presentation logic.

When you don’t have a supervisor, you need to teach the worker the rules. Let’s say it is a simple rule, 1 tone is the weight limit.

Your business expands, you hire more workers (mobile, desktop, other devices). You teach them this rule.

New rules come. Now you need to adhere to the laws of the country. Laws change too often.

You have two options here:

Hire lawyers to fill the truck.
Workers call the lawyer.

Let’s say you pick lawyers to fill your truck. They know the laws and can figure out the weight limit.

In software terms, you put more logic in your presentational layer.

The other option is more beneficial. Workers call the lawyer, get an answer if they continue loading or stop.

In software terms, add business rules to the business layer, which UI can call for information.

What‘s wrong to do in the UI?

Don’t deceive your customers. Look at this article below.

## Blatant lies revealed in the source code for an online shop### Are 14 people really looking at this product?medium.com

Don’t lie about active customers. Any developer will see through this lie.

Solve this on the backend. Look at active sessions, and extra info to identify the product. A product which the customer is looking at.

Query the backend for data. Calculate active customers, and respond to the UI layer.

Don’t do your business logic on the frontend. Don’t calculate promotions on the frontend, for example.

## This Website Accidentally Left Promo Codes in Their Source Code### Finding interesting things by inspecting websitesjavascript.plainenglish.io

Act on the data on the back-end. Hide sensitive info from the front-end.

Keep your promo rules in the backend. Promotions are conditions and actions. You do need some rule engine to decide if the promotion is valid.

After the decision is made, apply promotion, and return the page. In a headless approach, you call the promo API to get the information.

Seems logical, yet we have bad examples.

What’s appropriate in the UI layer?

Access the backend logic. Send promo codes. Get back the response. Or embed in the page applied promotion.

Call the backend, get relevant active users to count, and present it on the UI. The backend should calculate this count. Not jQuery.

Don’t do this —source

Conclusion

These are few examples of how to combat unwanted behavior.

Do your critical rules on the backend. Check promotions, develop algorithms, on the backend. Less critical ones can go on the frontend. Develop conditional styling in this layer.

With this, you can rest assured, your app is protected. Protected from unwanted behavior.

Resources

Enterprise Patterns

Most of this topic was derived from thisquestion.

Photo byGabby KfromPexels

What Kills Developer’s Willpower?

Milos Zivkovic — Sat, 27 Mar 2021 22:22:39 +0000

Best ways to kill the software engineer willpower

Developers are under constant fire. Bugs, deadlines, and a lot of abstractions. Really easy to lose the willpower to code.

Why developers don’t like coding? Paychecks are good. You sit all day. You don’t do any physical labor.

What aggravates developers the most?

Meaningless coding jobs

For any software engineer, this is by far, the best way to lose interest. Lose interest in coding. You become a drag-n-drop developer.

Drop-in a plugin, add a few adjustments, job well done. It is easy money, but no valuable progress.

Freelance developers can’t pick work. They work on adult sites, scams, and Ponzi schemes.

Imagine your friends asking about work. You would feel upset about this, and leave programming for good.

Micromanagement

Ask developers every day for status reports. Even better, ask them every hour.

Push them to finish that feature. Ask them constantly about the progress.

Change scope. Change it mid-sprint. To agitate on the developer’s pain.

Impossible schedule

Notify them about the critical bug on friday. Expect, the fix in few hours.

Don’t think about their well-being. Ask them to deliver. Deliver instantly.

Don’t provide the best tools

Blame everything on them. Build failed? It’s your fault. Not that we don’t have CI in place. Your fault.

Work with legacy systems. Then question why developers are not happy. The answer presents itself.

Dysfunctional team composition

Testers don’t match the developers. You’re pulling your hair to explain basic features. You’re drained from all that explaining.

Even after you explain. Testers don’t test properly. Bugs occur. You lose your motivation to work.

Tech debt

Code is locked down. No changes. It works. Don’t touch it.

And tech debt takes its toll. Developers get to a breaking point.

The point at which one can’t add code. Changes on feature X break feature Y, or even worse problems occur.

Unclear software requirements

Business giving requirements directly to developers. Never works well. Without a good business analyst, it is impossible to do work.

You’re constantly bombarded with dumb requests.“Margins are bad”,_“why is this not brown?”._While performance issues are causing more and more customers to click away.

Disruption of flow

source

Constant meetings. You drop from one to join another one. Talks about mundane things.

Disrupting your code flow. Directly impacting your will to code.

Conclusion

Times are hard. Your mental health is important.

Leave bad businesses. New opportunities do come up. Don’t stay and feel upset, leave and find a better workplace.

Photo byAndrea PiacquadiofromPexels