<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*qD0JDT3Kk5RqJNwbE4E6FA.jpeg" /></figure>In the dynamic realm of relational databases, PostgreSQL stands tall as a versatile powerhouse. When it comes to optimizing database performance, there is a crucial tool that every developer and database admin relies on — indexes. In this blog post, we’ll take a closer look at PostgreSQL indexes — a handy tool for improving database performance. From demystifying what they are to mastering their creation, understanding when to use them, and ensuring they’re finely tuned, we’ll cover it all, peppered with real code snippets and examples.<h3>Decoding PostgreSQL Indexes</h3>Let’s start with the basics. An index in PostgreSQL is like a map that turbocharges your queries, enabling swift data retrieval. Picture an index as the table of contents in a book — it’s your shortcut to finding exactly what you need, without flipping through every page. Without indexes, databases would slog through entire tables to fetch data, leading to inefficient query performance, especially for large datasets.<h3>Crafting Indexes in PostgreSQL</h3><pre>CREATE INDEX index_name ON table_name (column_name);</pre>Indexes can be sprinkled over one or multiple columns in a table. But, hold on! The columns you pick for indexing and the type of index you choose are pivotal.<h3>The Index Selection Dilemma: When to Index</h3>Indexes are strong tools, but they’re not without their trade-offs. While they boost read performance, they can slow down write operations due to maintenance overhead. The key is to choose your battles wisely. Here are scenarios where indexes shine:<ol><li>Frequent Searches: If your application heavily relies on frequent searches within specific columns, indexing is the optimal choice.</li><li>Joining: Columns used in joining tables are prime candidates for indexing, ensuring faster data retrieval during joins.</li><li>Sorting &amp; Ordering: For columns playing sorting and ordering roles, indexing steps up the game of ORDER BY and GROUP BY clauses.</li></ol><h3>Navigating Index Types</h3>PostgreSQL spoils you with index types, each tailored to specific scenarios. Let’s explore a couple:<ul><li>B-tree Index: Your go-to choice. Great for range queries and equality comparisons.</li></ul><pre>-- Create a B-tree index on a single column CREATE INDEX idx_column_name ON table_name (column_name);</pre><pre>-- Create a B-tree composite index on multiple columns CREATE INDEX idx_multi_column ON table_name (column1, column2);</pre><ul><li>Hash Index: A heavyweight for equality checks, particularly when dealing with limited distinct values.</li></ul><pre>-- Create a hash index on a single column CREATE INDEX idx_column_name ON table_name USING hash (column_name);</pre>Since it <a href="https://www.postgresql.org/docs/current/indexes-types.html#INDEXES-TYPES-HASH:~:text=Hash%20indexes%20store%20a%2032%2Dbit%20hash%20code%20derived%20from%20the%20value%20of%20the%20indexed%20column.%20Hence%2C%20such%20indexes%20can%20only%20handle%20simple%20equality%20comparisons.%20The%20query%20planner%20will%20consider%20using%20a%20hash%20index%20whenever%20an%20indexed%20column%20is%20involved%20in%20a%20comparison%20using%20the%20equal%20operator%3A">uses equality checks(=)</a> If we specify a separate operator (such as pattern matching), it does not use the hash index.<ul><li>GIN (Generalized Inverted Index): A power player for array data queries and full-text search.</li></ul><pre>-- Create a GIN index on an array column CREATE INDEX idx_array_column ON table_name USING gin (array_column);</pre><pre>-- Create a GIN index for full-text search (requires the &quot;pg_trgm&quot; extension) -- Enable the extension if not already enabled CREATE EXTENSION IF NOT EXISTS pg_trgm; CREATE INDEX idx_full_text_search ON table_name USING gin (text_column gin_trgm_ops);</pre><ul><li>GiST (Generalized Search Tree): Versatile and valuable for various data types, including spatial data.</li></ul><pre>-- Create a GiST index on a geometry column (requires the &quot;postgis&quot; extension) -- Enable the extension if not already enabled CREATE EXTENSION IF NOT EXISTS postgis; CREATE INDEX idx_spatial_data ON table_name USING gist (geometry_column);</pre>Please note that for some index types (e.g., GiST and GIN), you may need to enable specific extensions (like “postgis” for spatial data or “pg_trgm” for text search) before you can create indexes of that type.<h3>Harnessing the Power of ANALYZE</h3>The ANALYZE command is your backstage pass to index insights. It offers statistics about table distribution and index usage, helping you evaluate their effectiveness.<h4>The ANALYZE Command:</h4><ul><li>The ANALYZE command is used to collect statistics about a table or an index. It provides the PostgreSQL query planner with information about the distribution of data within a table or index.</li><li>When you perform an ANALYZE operation on a table or an index, PostgreSQL takes a representative sample of the data and collects information about how the data is distributed.</li><li>ANALYZE is employed as part of regular database upkeep to ensure that the statistics remain current and relevant.</li></ul><pre>ANALYZE table_name;</pre><h4>EXPLAIN ANALYZE:</h4><ul><li>The EXPLAIN ANALYZE command is used to obtain the execution plan and performance statistics for a query without actually executing the query. It&#39;s a tool for understanding how PostgreSQL plans to execute a query and how long each part of the query takes to run.</li><li>When you run EXPLAIN ANALYZE followed by a query, PostgreSQL generates the query execution plan, executes the query, and then provides a detailed breakdown of how the query was executed, including the time spent on each step and the number of rows processed at each step. This information is valuable for query optimization and performance tuning.</li></ul><pre>EXPLAIN ANALYZE SELECT * FROM table_name WHERE column_name = &#39;value&#39;;</pre><h3>Indexing Strategies in Action</h3><h4>Scenario 1: Basic Indexing</h4>Imagine you’re overseeing a table named customers, which stores valuable information about your clients. You often need to search for customers using their email addresses. Here&#39;s how it looks:<pre>CREATE TABLE customers ( customer_id SERIAL PRIMARY KEY, first_name VARCHAR(50), last_name VARCHAR(50), email VARCHAR(100) ); INSERT INTO customers (first_name, last_name, email) VALUES (&#39;Arik&#39;, &#39;Jordan&#39;, &#39;Arik@example.com&#39;), (&#39;Jane&#39;, &#39;Smith&#39;, &#39;jane@example.com&#39;), (&#39;Michael&#39;, &#39;Johnson&#39;, &#39;michael@example.com&#39;);</pre>Without an index in place, when you want to find a specific email address, it’s like searching for a needle in a haystack. Here’s what the query would look like:<pre>EXPLAIN ANALYZE SELECT * FROM customers WHERE email = &#39;Arik@example.com&#39;;</pre><figure><img alt="" src="https://cdn-images-1.medium.com/max/684/1*1TwA_a0pSjS-ulV6Fpeg0Q.png" /><figcaption>EXPLAIN ANALYZE comman’s output — without index</figcaption></figure>Now, let’s create an index on the email column to speed up these queries, and see the output of the EXPLAIN ANALYZE command:<pre>CREATE INDEX idx_email ON customers (email); EXPLAIN ANALYZE SELECT * FROM customers WHERE email = &#39;Arik@example.com&#39;;</pre><figure><img alt="" src="https://cdn-images-1.medium.com/max/790/1*3Zb7hKTlX0VICjYpSDRcqQ.png" /><figcaption>EXPLAIN ANALYZE comman’s output — with index</figcaption></figure>Now the query plan using an index scan instead of a regular seq scan.Wait..! but you said ‘speed up’, it is taking longer now, how is that possible?we will figure it out in last section: When to Avoid Indexing: Situations to Consider.<h4>Scenario 2: Multi-Column Index</h4>In a slightly different scenario, you’re tasked with managing an orders table that keeps track of customer orders. You frequently need to find orders based on two things: the customer&#39;s ID and the order date. Here&#39;s how the orders table looks:<pre>CREATE TABLE orders ( order_id SERIAL PRIMARY KEY, customer_id INT, order_date DATE, total_amount DECIMAL(10, 2) ); INSERT INTO orders (customer_id, order_date, total_amount) VALUES (1, &#39;2023-01-15&#39;, 150.00), (2, &#39;2023-02-10&#39;, 200.00), (1, &#39;2023-02-20&#39;, 120.00);</pre>To make these order-based queries faster, we can create a multi-column index on both customer_id and order_date. It&#39;s like giving your database a roadmap for finding orders efficiently:<pre>CREATE INDEX idx_customer_order_date ON orders (customer_id, order_date);</pre>Now, your queries involving filtering by both criteria will be optimized for speed.<h4>Scenario 3: Index Order and Included Columns</h4>Imagine managing a products table with detailed information about various products. You frequently search for products based on their category and manufacturer. To create a covering index, including the product_name column in the index might enhance performance.<pre>CREATE TABLE products ( product_id SERIAL PRIMARY KEY, product_name VARCHAR(100), category VARCHAR(50), manufacturer VARCHAR(50), price DECIMAL(8, 2) ); INSERT INTO products (product_name, category, manufacturer, price) VALUES (&#39;Laptop&#39;, &#39;Electronics&#39;, &#39;ABC Electronics&#39;, 999.99), (&#39;Smartphone&#39;, &#39;Electronics&#39;, &#39;XYZ Mobile&#39;, 599.99), (&#39;Chair&#39;, &#39;Furniture&#39;, &#39;Furniture Co.&#39;, 149.99);</pre>Create an index with columns ordered by category and manufacturer, and include the product_name:<pre>CREATE INDEX idx_product_search ON products (category, manufacturer) INCLUDE (product_name);</pre><h3>Multi-Column Indexes Order</h3>Consider a scenario where you manage a database of products. The table includes several columns: product_id, category, manufacturer, price, and availability. You frequently run queries to filter products based on their category and manufacturer.<h4>Column Order Matters:</h4>When creating a multi-column index, the order of the columns is crucial. The leftmost column in the index plays a pivotal role. It should align with the most frequently filtered or sorted criteria in your queries.In our case, since we often filter by category first and then by manufacturer, the optimal index order should have category as the leftmost column.<pre>-- Correct Index Order (category, manufacturer) CREATE INDEX idx_product_search ON products (category, manufacturer);</pre>Now, when you run queries filtering by category and manufacturer, the index&#39;s hierarchy aligns perfectly with your query patterns, leading to efficient data retrieval.<h4>Incorrect Index Order:</h4>Conversely, if you create the index with an incorrect order, say, starting with manufacturer, it might not yield the same performance benefits:<pre>-- Incorrect Index Order (manufacturer, category) CREATE INDEX idx_incorrect_order ON products (manufacturer, category);</pre>Queries filtering by category first would not benefit from this index as much, as it doesn&#39;t match the leftmost prefix of the index.<h4>Querying with the Correct Index</h4>Now, let’s see how this well-ordered index improves query performance:<pre>SELECT * FROM products WHERE category = &#39;Electronics&#39; AND manufacturer = &#39;ABC Electronics&#39;;</pre>This query efficiently utilizes the multi-column index, benefiting from the leftmost category column.<h4>Querying without the Correct Index</h4>Contrast this with a query that doesn’t align with the index order:<pre>SELECT * FROM products WHERE manufacturer = &#39;ABC Electronics&#39; AND category = &#39;Electronics&#39;;</pre>This query might not fully leverage the index’s potential, resulting in potentially slower performance.<h3>When to Avoid Indexing: Situations to Consider</h3><ol><li>Highly Volatile Tables: Tables frequently changing with new data or updates may not benefit from indexes due to potential write performance impacts.</li><li>Small Tables: For very small tables with few rows, adding indexes may not significantly boost performance and could be unnecessary.</li><li>Low Selectivity Columns: Columns with limited distinct values might not gain much from indexing; focus on columns with higher variety.</li><li>Frequent Full Table Scans: When queries scan the entire table without leveraging indexes, the overhead of maintaining them may not be justified.</li><li>Batch Insert Operations: During large data imports, temporarily removing and then rebuilding indexes can expedite the process.</li><li>Temporary Tables: For short-lived tables rarely queried, adding indexes might not be worth the effort.</li><li>Queries with Low Complexity: Simple queries with minimal filtering may not see significant performance gains from indexes.</li><li>Low Latency Tolerance: In real-time applications, even minor indexing delays may not be acceptable, necessitating other optimization methods.</li></ol>Keep in mind that whether to use or skip indexes should be based on a thorough analysis of your specific database and your performance needs. It can be beneficial to closely examine your queries, both with and without indexes, and employ the EXPLAIN ANALYZE command to determine the actual impact on performance.<h3>Conclusion: Mastering the Art of Indexing</h3>Becoming professional in indexing is a must skill when working with the PostgreSQL database management system. By knowing which columns to index and understanding how indexing really works, you’ll have the tools to make your queries faster and more efficient. Don’t hesitate to experiment with various types of indexes, monitor their performance, and leverage included columns to create efficient covering indexes. Armed with these practical examples, you’ll be well-prepared to enhance the efficiency of your PostgreSQL database, ensuring that your application remains responsive and fast, even as your data continues to evolve and expand.<img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=5e4b0dc293e5" width="1" height="1" alt=""><hr><a href="https://medium.com/autodesk-tlv/mastering-postgresql-indexes-for-optimal-performance-5e4b0dc293e5">Mastering PostgreSQL Indexes for Optimal Performance</a> was originally published in <a href="https://medium.com/autodesk-tlv">Autodesk TLV</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the dynamic realm of relational databases, PostgreSQL stands tall as a versatile powerhouse. When it comes to optimizing database performance, there is a crucial tool that every developer and database admin relies on — indexes. In this blog post, we’ll take a closer look at PostgreSQL indexes — a handy tool for improving database performance. From demystifying what they are to mastering their creation, understanding when to use them, and ensuring they’re finely tuned, we’ll cover it all, peppered with real code snippets and examples.
Decoding PostgreSQL Indexes
Let’s start with the basics. An index in PostgreSQL is like a map that turbocharges your queries, enabling swift data retrieval. Picture an index as the table of contents in a book — it’s your shortcut to finding exactly what you need, without flipping through every page. Without indexes, databases would slog through entire tables to fetch data, leading to inefficient query performance, especially for large datasets.
Crafting Indexes in PostgreSQL
CREATE INDEX index_name ON table_name (column_name);
Indexes can be sprinkled over one or multiple columns in a table. But, hold on! The columns you pick for indexing and the type of index you choose are pivotal.
The Index Selection Dilemma: When to Index
Indexes are strong tools, but they’re not without their trade-offs. While they boost read performance, they can slow down write operations due to maintenance overhead. The key is to choose your battles wisely. Here are scenarios where indexes shine:

Frequent Searches: If your application heavily relies on frequent searches within specific columns, indexing is the optimal choice.
Joining: Columns used in joining tables are prime candidates for indexing, ensuring faster data retrieval during joins.
Sorting & Ordering: For columns playing sorting and ordering roles, indexing steps up the game of ORDER BY and GROUP BY clauses.

Navigating Index Types
PostgreSQL spoils you with index types, each tailored to specific scenarios. Let’s explore a couple:

B-tree Index: Your go-to choice. Great for range queries and equality comparisons.

-- Create a B-tree index on a single column
CREATE INDEX idx_column_name ON table_name (column_name);
-- Create a B-tree composite index on multiple columns
CREATE INDEX idx_multi_column ON table_name (column1, column2);

Hash Index: A heavyweight for equality checks, particularly when dealing with limited distinct values.

-- Create a hash index on a single column
CREATE INDEX idx_column_name ON table_name USING hash (column_name);
Since it uses equality checks(=) If we specify a separate operator (such as pattern matching), it does not use the hash index.

GIN (Generalized Inverted Index): A power player for array data queries and full-text search.

-- Create a GIN index on an array column
CREATE INDEX idx_array_column ON table_name USING gin (array_column);
-- Create a GIN index for full-text search (requires the "pg_trgm" extension)
-- Enable the extension if not already enabled
CREATE EXTENSION IF NOT EXISTS pg_trgm; 
CREATE INDEX idx_full_text_search 
ON table_name 
USING gin (text_column gin_trgm_ops);

GiST (Generalized Search Tree): Versatile and valuable for various data types, including spatial data.

-- Create a GiST index on a geometry column (requires the "postgis" extension)
-- Enable the extension if not already enabled
CREATE EXTENSION IF NOT EXISTS postgis; 
CREATE INDEX idx_spatial_data ON table_name USING gist (geometry_column);
Please note that for some index types (e.g., GiST and GIN), you may need to enable specific extensions (like “postgis” for spatial data or “pg_trgm” for text search) before you can create indexes of that type.
Harnessing the Power of ANALYZE
The ANALYZE command is your backstage pass to index insights. It offers statistics about table distribution and index usage, helping you evaluate their effectiveness.
The ANALYZE Command:

The ANALYZE command is used to collect statistics about a table or an index. It provides the PostgreSQL query planner with information about the distribution of data within a table or index.
When you perform an ANALYZE operation on a table or an index, PostgreSQL takes a representative sample of the data and collects information about how the data is distributed.
ANALYZE is employed as part of regular database upkeep to ensure that the statistics remain current and relevant.

ANALYZE table_name;
EXPLAIN ANALYZE:

The EXPLAIN ANALYZE command is used to obtain the execution plan and performance statistics for a query without actually executing the query. It's a tool for understanding how PostgreSQL plans to execute a query and how long each part of the query takes to run.
When you run EXPLAIN ANALYZE followed by a query, PostgreSQL generates the query execution plan, executes the query, and then provides a detailed breakdown of how the query was executed, including the time spent on each step and the number of rows processed at each step. This information is valuable for query optimization and performance tuning.

EXPLAIN ANALYZE SELECT * FROM table_name WHERE column_name = 'value';
Indexing Strategies in Action
Scenario 1: Basic Indexing
Imagine you’re overseeing a table named customers, which stores valuable information about your clients. You often need to search for customers using their email addresses. Here's how it looks:
CREATE TABLE customers (
    customer_id SERIAL PRIMARY KEY,
    first_name VARCHAR(50),
    last_name VARCHAR(50),
    email VARCHAR(100)
);
INSERT INTO customers (first_name, last_name, email)
VALUES
    ('Arik', 'Jordan', 'Arik@example.com'),
    ('Jane', 'Smith', 'jane@example.com'),
    ('Michael', 'Johnson', 'michael@example.com');
Without an index in place, when you want to find a specific email address, it’s like searching for a needle in a haystack. Here’s what the query would look like:
EXPLAIN ANALYZE SELECT * FROM customers WHERE email = 'Arik@example.com';
EXPLAIN ANALYZE comman’s output — without index
Now, let’s create an index on the email column to speed up these queries, and see the output of the EXPLAIN ANALYZE command:
CREATE INDEX idx_email ON customers (email);
EXPLAIN ANALYZE SELECT * FROM customers WHERE email = 'Arik@example.com';
EXPLAIN ANALYZE comman’s output — with index
Now the query plan using an index scan instead of a regular seq scan.
Wait..! but you said ‘speed up’, it is taking longer now, how is that possible?we will figure it out in last section: When to Avoid Indexing: Situations to Consider.
Scenario 2: Multi-Column Index
In a slightly different scenario, you’re tasked with managing an orders table that keeps track of customer orders. You frequently need to find orders based on two things: the customer's ID and the order date. Here's how the orders table looks:
CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    customer_id INT,
    order_date DATE,
    total_amount DECIMAL(10, 2)
);
INSERT INTO orders (customer_id, order_date, total_amount)
VALUES
    (1, '2023-01-15', 150.00),
    (2, '2023-02-10', 200.00),
    (1, '2023-02-20', 120.00);
To make these order-based queries faster, we can create a multi-column index on both customer_id and order_date. It's like giving your database a roadmap for finding orders efficiently:
CREATE INDEX idx_customer_order_date ON orders (customer_id, order_date);
Now, your queries involving filtering by both criteria will be optimized for speed.
Scenario 3: Index Order and Included Columns
Imagine managing a products table with detailed information about various products. You frequently search for products based on their category and manufacturer. To create a covering index, including the product_name column in the index might enhance performance.
CREATE TABLE products (
    product_id SERIAL PRIMARY KEY,
    product_name VARCHAR(100),
    category VARCHAR(50),
    manufacturer VARCHAR(50),
    price DECIMAL(8, 2)
);
INSERT INTO products (product_name, category, manufacturer, price)
VALUES
    ('Laptop', 'Electronics', 'ABC Electronics', 999.99),
    ('Smartphone', 'Electronics', 'XYZ Mobile', 599.99),
    ('Chair', 'Furniture', 'Furniture Co.', 149.99);
Create an index with columns ordered by category and manufacturer, and include the product_name:
CREATE INDEX idx_product_search 
ON products (category, manufacturer) 
INCLUDE (product_name);
Multi-Column Indexes Order
Consider a scenario where you manage a database of products. The table includes several columns: product_id, category, manufacturer, price, and availability. You frequently run queries to filter products based on their category and manufacturer.
Column Order Matters:
When creating a multi-column index, the order of the columns is crucial. The leftmost column in the index plays a pivotal role. It should align with the most frequently filtered or sorted criteria in your queries.
In our case, since we often filter by category first and then by manufacturer, the optimal index order should have category as the leftmost column.
-- Correct Index Order (category, manufacturer)
CREATE INDEX idx_product_search ON products (category, manufacturer);
Now, when you run queries filtering by category and manufacturer, the index's hierarchy aligns perfectly with your query patterns, leading to efficient data retrieval.
Incorrect Index Order:
Conversely, if you create the index with an incorrect order, say, starting with manufacturer, it might not yield the same performance benefits:
-- Incorrect Index Order (manufacturer, category)
CREATE INDEX idx_incorrect_order ON products (manufacturer, category);
Queries filtering by category first would not benefit from this index as much, as it doesn't match the leftmost prefix of the index.
Querying with the Correct Index
Now, let’s see how this well-ordered index improves query performance:
SELECT * FROM products 
WHERE category = 'Electronics' AND manufacturer = 'ABC Electronics';
This query efficiently utilizes the multi-column index, benefiting from the leftmost category column.
Querying without the Correct Index
Contrast this with a query that doesn’t align with the index order:
SELECT * FROM products 
WHERE manufacturer = 'ABC Electronics' AND category = 'Electronics';
This query might not fully leverage the index’s potential, resulting in potentially slower performance.
When to Avoid Indexing: Situations to Consider

Highly Volatile Tables: Tables frequently changing with new data or updates may not benefit from indexes due to potential write performance impacts.
Small Tables: For very small tables with few rows, adding indexes may not significantly boost performance and could be unnecessary.
Low Selectivity Columns: Columns with limited distinct values might not gain much from indexing; focus on columns with higher variety.
Frequent Full Table Scans: When queries scan the entire table without leveraging indexes, the overhead of maintaining them may not be justified.
Batch Insert Operations: During large data imports, temporarily removing and then rebuilding indexes can expedite the process.
Temporary Tables: For short-lived tables rarely queried, adding indexes might not be worth the effort.
Queries with Low Complexity: Simple queries with minimal filtering may not see significant performance gains from indexes.
Low Latency Tolerance: In real-time applications, even minor indexing delays may not be acceptable, necessitating other optimization methods.

Keep in mind that whether to use or skip indexes should be based on a thorough analysis of your specific database and your performance needs. It can be beneficial to closely examine your queries, both with and without indexes, and employ the EXPLAIN ANALYZE command to determine the actual impact on performance.
Conclusion: Mastering the Art of Indexing
Becoming professional in indexing is a must skill when working with the PostgreSQL database management system. By knowing which columns to index and understanding how indexing really works, you’ll have the tools to make your queries faster and more efficient. Don’t hesitate to experiment with various types of indexes, monitor their performance, and leverage included columns to create efficient covering indexes. Armed with these practical examples, you’ll be well-prepared to enhance the efficiency of your PostgreSQL database, ensuring that your application remains responsive and fast, even as your data continues to evolve and expand.

Mastering PostgreSQL Indexes for Optimal Performance was originally published in Autodesk TLV on Medium, where people are continuing the conversation by highlighting and responding to this story.

Mastering PostgreSQL Indexes for Optimal Performance

Developing Games for Android and iOS with Kotlin in Jetpack Compose
Jetpack Compose is Android’s recommended modern toolkit for writing and building native UI. Using compose we can bring our app to life using less code, and very quickly, but what about games ?
Recently, Jetbrains announced that compose Multiplatform will be able to target iOS for the first time (Desktop had already been supported for a while) which great news, since now we share the UI between our Android and iOS, which means that we can try to create our game and share the whole code between two platforms, and write it all using Compose.
Let’s see how this can be achieved.
Our first step will be to create new KMP (KMM name is deprecated) and run it to make sure we have a good starting point for running an Android and iOS app.
Our second step will be defining compose Multiplatform libraries support for the KMP, project since they aren’t a part of the basic template, and we need to manually add these libraries into our Gradle settings.
Also we will create a shared composable function that will be shared for Android and iOS.
Finally in the third step we will create a very simple game engine in compose in Kotlin(which is based on the wonderful tutorial of Sebastian Aigner almost two years ago — creating Asteroid game ! Check it out for more info)
First step — Creating KMP Project
Download latest Android Studio and open a new project
Select Kotlin Multiplatform App
Select Kotlin Multiplatform App and this template will generate all the needed files in order to run our app on Android and iOS.
Write your app’s name and package name
Write your app and package names and select the Minimum SDK in order to target your audience. I choose Android 8.1 since it targets most of the devices. Finally leave the build configuration as is, and click Next.0
Write your Android and iOS project names
In the next screen choose the Android and iOS project names and click Finish.
Once finished is clicked, AS will sync all the needed files (which can take a while, since on the first time it needs to download all the packages for KMP)
When finished, you can test and run that everything works OK, in AS click Play and for iOS — open the iOS folder, click on the iosBallApp.xcodeproj and open it using Xcode.
Open with Xcode
Inside Xcode, click Play and see the results :
Android and iOS apps running with KMP support
Second step — Define Jetpack Compose Multiplatform support
Next steps are needed in order to use the compose libraries inside the shared code, this will require manual settings inside the settings and Gradle files. Let’s jump into it.
Open gradle.properies file and add these lines :
kotlin.version=1.8.20
agp.version=8.0.1
compose.version=1.4.0
org.jetbrains.compose.experimental.uikit.enabled=true
kotlin.native.cacheKind=true
Next, open Project build.gradle.kts and replace the lines the template created with the following lines :
 kotlin("multiplatform").apply(false)
 id("com.android.application").apply(false)
 id("com.android.library").apply(false)
 id("org.jetbrains.compose").apply(false)
We just removed the constant versions and we added compose library plugin.
For android and shared build.gradle.kts , add also the plugin of compose as one of the plugins.
id("org.jetbrains.compose")
Inside the shared build.gradle.kts scroll down to the code where there are list of iOS and add isStatic = true so your code will look like this :
listOf(
 iosX64(),
 iosArm64(),
 iosSimulatorArm64()
 ).forEach {
 it.binaries.framework {
 baseName = "shared"
 isStatic = true
 }
 }
Next, we will add the compose dependencies to the common main module. Make sure your commonMain variable will have these dependenices :
val commonMain by getting {
 dependencies {
 implementation(compose.runtime)
 implementation(compose.foundation)
 implementation(compose.material)
 @OptIn(org.jetbrains.compose.ExperimentalComposeLibrary::class)
 implementation(compose.components.resources)
 }
 }
it’s ok that they are still marked in red color, since we didn’t sync the project yet. Let’s wait with the sync for a little bit.
Finally, let’s open settings.gradle.kts and add compose repository so all the dependencies can be resolved :
Add this inside Plugin management repositories, as well as inside the Resolution management :
maven("https://maven.pkg.jetbrains.space/public/p/compose/dev")
Then, inside the Plugin management code, add this block of code:
 plugins {
 val kotlinVersion = extra["kotlin.version"] as String
 val agpVersion = extra["agp.version"] as String
 val composeVersion = extra["compose.version"] as String
 kotlin("jvm").version(kotlinVersion)
 kotlin("multiplatform").version(kotlinVersion)
 kotlin("android").version(kotlinVersion)
 id("com.android.application").version(agpVersion)
 id("com.android.library").version(agpVersion)
 id("org.jetbrains.compose").version(composeVersion)
 }
This code takes the configuration we defined and applies the version to the plugins, so in the future we can easily change the versions.
Now we can click the sync Gradle with project files and hope that everything will sync correctly.
Now we will add shared composable functions that will be in use both for Android and for iOS.
Open commonMain package and add inside Kotlin a new file called App
Add App file tha will contain shared composable code
Add some composable content into that file, for example:
@Composable
fun App() {
 var count by remember { mutableStateOf(0) }
 Box(
 Modifier.fillMaxSize(),
 contentAlignment = Alignment.Center
 ) {
 Button(
 onClick = { count++ }
 ) {
 Text("Count: $count")
 }
 }
}
Next, we will need to use this composable function in Android and in iOS.
For android, let’s open our MainActivity and add the new composable function instead of the current code
class MainActivity : ComponentActivity() {
 override fun onCreate(savedInstanceState: Bundle?) {
 super.onCreate(savedInstanceState)
 setContent {
 MyApplicationTheme {
 App()
 }
 }
 }
}
For iOS we need to do some additional steps.
First, let’s open our iosMain package inside AS and add a new file called App and add this function inside the file :
fun MainViewController() = ComposeUIViewController {
 App()
}
This function creates an iOS style view controller that will be a special composable view controller since we are providing our shared composable function — App()
Second, we need to create a new file
Creating a new Composable view for iOS
Lets call it ComposableView swift file and add this content inside the file
import Foundation
import SwiftUI
import shared
struct ComposeView: UIViewControllerRepresentable {
 func updateUIViewController(_ uiViewController: UIViewControllerType, context: Context) {
 }
 
 func makeUIViewController(context: Context) -> some UIViewController {
 AppKt.MainViewController()
 }
 
}
We can see that we are statically calling our previous method MainViewController (from Kotlin) that will hold our composable shared code.
By running the code after the changes, we will see a simple composable views both on Android and on iOS written from same shared code.
Android and iOS are running the same composable code written once in compose.
This step is described very well by Philipp Lackner in his great tutorial video, you can check it out here
Third step — writing a small game engine.
Inside a commonMain package let’s create a Game class and MainGame file.
enum class GameState {
 STOPPED, RUNNING
}
class Game {
 var prevTime = 0L
 var width by mutableStateOf(0.dp)
 var height by mutableStateOf(0.dp)
 var gameState by mutableStateOf(GameState.STOPPED)
 var totalTime by mutableStateOf(0L)

 fun startGame() {
 gameState = GameState.RUNNING
 totalTime = 0L
 }
 fun endGame() {
 gameState = GameState.STOPPED
 }
 fun update(time: Long) {
 val delta = time - prevTime
 prevTime = time
 if (gameState == GameState.STOPPED) return
 totalTime += delta
 }
}
and MainGame composable with separate file.
@Composable
fun MainGame() {
 val game = remember { Game() }
 val density = LocalDensity.current
 LaunchedEffect(Unit) {
 while (true) {
 withFrameNanos {
 game.update(it)
 }
 }
 }
 Column(modifier = Modifier.background(Color(51, 153, 255)).fillMaxHeight().fillMaxWidth()) {
 Row(modifier = Modifier.align(Alignment.CenterHorizontally).fillMaxWidth()) {
 Button({
 if (game.gameState == GameState.STOPPED)
 game.startGame()
 else
 game.endGame()
 }) {
 Text(if (game.gameState == GameState.STOPPED) "Play" else "Stop")
 }
 Text(
 "${(game.totalTime / 1E8).roundToInt() / 10f} seconds.",
 modifier = Modifier.align(Alignment.CenterVertically).padding(horizontal = 16.dp),
 color = Color.White
 )
 }
 Box(modifier = Modifier
 .background(Color.Black)
 .fillMaxWidth()
 .fillMaxHeight()
 .clipToBounds()
 .onSizeChanged {
 with(density) {
 game.width = it.width.toDp()
 game.height = it.height.toDp()
 }
 }) {
 }
 }
}
We can see that we create our Game class and every time there is an update we call game.update(it) This is the heart of the engine, where update called with some times, and we can know how much time took to draw last frame.
if we compile and play our code, we will see a running time.
Running compose engine code — shows the running time
This maybe isn’t much but it’s actually a template for a very basic game, we just don’t have any game objects, and math and nothing but that’s can be easily added as well.
Let’s add some math library so we can use some basic math vectors.
Add this dependency to the commonMain dependencies, this allow us to use vectors with Float2 (by RomainGuy)
implementation ("dev.romainguy:kotlin-math:1.5.3")
Now let’s create some basic GameObject and add a basic functionality to it :
abstract class GameObject(
 speed: Float = 0.0F,
 angle: Float = 0.0F,
 position: Float2 = Float2()
) {
 companion object {
 val UNIT_X = Float2(1.0f, 0.0f)
 }
 var speed by mutableStateOf(speed)
 var angle by mutableStateOf(angle)
 var position by mutableStateOf(position)
 var movementVector
 get() = (UNIT_X.times(speed)).rotate(angle)
 set(value) {
 speed = length(value)
 angle = value.angle()
 }
 abstract val size: Float // Diameter
 open fun update(realDelta: Float, game: Game) {
 val obj = this
 val velocity = movementVector.times(realDelta)
 obj.position = obj.position.plus(velocity)
 }
}
Then let’s create a BallData class that will be inherited from this game object :
class BallData(
 ballSize: Float = 20f,
 val color: Color = Color.Red,
 var isEnabled: Boolean = true
) :
 GameObject() {
 override var size: Float = ballSize
 override fun update(realDelta: Float, game: Game) {
 if (!isEnabled) return
 super.update(realDelta, game)
 if (xOffset > game.width - size.dp || xOffset < 0.dp) {
 movementVector = movementVector.times(Float2(-1f, 1f))
 if (xOffset < 0.dp) position.x = 0f
 if (xOffset > game.width - size.dp) position.x = game.width.value - size
 } else if (yOffset > game.height - size.dp || yOffset < 0.dp) {
 movementVector = movementVector.times(Float2(1f, -1f))
 if (yOffset < 0.dp) position.y = 0f
 if (yOffset > game.height - size.dp) position.y = game.height.value - size
 }
 }
}
We handle the logic of the ball inside the update method, once the ball hits the walls, we change the vector direction.
Let’s add some code to our Game class that will handle the balls in the game.
class Game {
 var prevTime = 0L
 var gameObjects = mutableStateListOf<GameObject>()
 var gameState by mutableStateOf(GameState.STOPPED)
 var gameStatus by mutableStateOf("Let's play!")
 var totalTime by mutableStateOf(0L)

 fun startGame() {
 gameObjects.clear()
 repeat(10) {
 val ball = BallData(
 ballSize = random(25, 45),
 color = Color(
 red = Random.nextFloat(),
 green = Random.nextFloat(),
 blue = Random.nextFloat()
 )
 )
 ball.position = Float2()//Float2(width.value / 2.0F, height.value / 2.0F)
 ball.movementVector = Float2(1f, 0f)
 ball.speed = random(0, 8) + 16f
 ball.angle = random(0, 15) + 30f
 gameObjects.add(ball)
 }
 gameState = GameState.RUNNING
 gameStatus = "Good luck!"
 totalTime = 0L
 }
 fun update(time: Long) {
 val delta = time - prevTime
 val floatDelta = (delta / 1E8).toFloat()
 prevTime = time
 if (gameState == GameState.STOPPED) return
 for (gameObject in gameObjects) {
 gameObject.update(floatDelta, this)
 }
 val allDisabled = gameObjects.filterIsInstance<BallData>().all {
 !it.isEnabled
 }
 if (allDisabled && gameState == GameState.RUNNING) {
 winGame()
 }
 totalTime += delta
 }
 fun endGame() {
 gameObjects.clear()
 gameState = GameState.STOPPED
 gameStatus = "Better luck next time!"
 }
 fun winGame() {
 gameState = GameState.STOPPED
 gameStatus = "Congratulations!"
 }
 var width by mutableStateOf(0.dp)
 var height by mutableStateOf(0.dp)
}
We are creating 10 random balls and add them to game objects array, when game starts. Then for every update of the game, we call to the update for each ball, so each ball can move.
Once game ended, we clear all the objects. 
This is the main game loop.
In order for code to work we are using some extension methods, create file called GameExtensions.kt and add this code
val GameObject.xOffset: Dp get() = position.x.dp
val GameObject.yOffset: Dp get() = position.y.dp
inline val Float.asRadians: Float get() = this * 0.017453292f
inline val Float.asDegrees: Float get() = this * 57.29578f
fun Float2.angle(): Float {
 val rawAngle = atan2(y = this.y, x = this.x)
 return ((rawAngle / PI) * 180F).toFloat()
}
fun Float2.rotate(degrees: Float, origin: Float2 = Float2()): Float2 {
 val p = this - origin
 val a = degrees.asRadians
 val w = Float2(
 p.x * cos(a) - p.y * sin(a),
 p.y * cos(a) + p.x * sin(a)
 )
 return w + origin
}
fun random(min: Int, max: Int): Float {
 require(min < max) { "Invalid range [$min, $max]" }
 return min + Random.nextFloat() * (max - min)
}
Now let’s create a representation of a ball in compose :
@Composable
fun Ball(ballData: BallData) {
 val ballSize = ballData.size.dp
 Box(
 Modifier
 .offset(ballData.xOffset, ballData.yOffset)
 .size(ballSize)
 .clip(CircleShape)
 .background(ballData.color)
 .clickable { ballData.isEnabled = !ballData.isEnabled }
 )
}
and finally let’s use this inside our main game composable :
@Composable
fun MainGame() {
 val game = remember { Game() }
 val density = LocalDensity.current
 LaunchedEffect(Unit) {
 while (true) {
 withFrameNanos {
 game.update(it)
 }
 }
 }
 Column(modifier = Modifier.background(Color(51, 153, 255)).fillMaxHeight().fillMaxWidth()) {
 Row(modifier = Modifier.align(Alignment.CenterHorizontally).fillMaxWidth()) {
 Button({
 if (game.gameState == GameState.STOPPED)
 game.startGame()
 else
 game.endGame()
 }) {
 Text(if(game.gameState == GameState.STOPPED) "Play" else "Stop")
 }
 Text(
 game.gameStatus,
 modifier = Modifier.align(Alignment.CenterVertically).padding(horizontal = 16.dp),
 color = Color.White
 )
 Text(
 "${(game.totalTime / 1E8).roundToInt() / 10f} seconds.",
 modifier = Modifier.align(Alignment.CenterVertically).padding(horizontal = 16.dp),
 color = Color.White
 )
 }

 Box(modifier = Modifier
 .background(Color.DarkGray)
 .padding(50.dp)
 .border(BorderStroke(2.dp, Color.Red))
 .fillMaxWidth()
 .fillMaxHeight()
 .clipToBounds()
 ) {
 Box(modifier = Modifier
 .background(Color.Black)
 .fillMaxWidth()
 .fillMaxHeight()
 .clipToBounds()
 .onSizeChanged {
 with(density) {
 game.width = it.width.toDp()
 game.height = it.height.toDp()
 }
 }) {
 game.gameObjects.forEach {
 when (it) {
 is BallData -> Ball(it)
 }
 }
 }
 }
 }
}
These lines
game.gameObjects.forEach {
 when (it) {
 is BallData -> Ball(it)
 }
}
means that we are “drawing” the composable ball, and each ball will move by itself (once it’s position will change)
We also enable / disable the ball once it’s clicked, so for our game to end we count the number of disabled balls and when all balls are disabled, we win.
val allDisabled = gameObjects.filterIsInstance<BallData>().all {
 !it.isEnabled
}
if (allDisabled && gameState == GameState.RUNNING) {
 winGame()
 }
Let’s run the games and we will get :
Balls compose game in Android & iOS
I hope that these examples can help you get started with developing your own game using Jetpack Compose Multiplatform with Kotlin.
Please don’t hesitate to contact me with any questions.
Full source code :
GitHub - jazzyjester/BallsComposeKMP: Balls compose game for Android and iOS
Happy Koding !

How to write games for Android and iOS with Kotlin in Jetpack Compose ? was originally published in Autodesk TLV on Medium, where people are continuing the conversation by highlighting and responding to this story.

How to write games for Android and iOS with Kotlin in Jetpack Compose ?

<h4>The case for learning from traditional industries</h4>What does software product delivery have to do with Manufacturing or Visual arts? Well, they are all in the business of creation. And therefore, they all share a high-level fundamental process of taking a vague idea and turning it into reality. We call it the Fundamental Creation Flow, and as product managers, we are essentially doing one thing — moving ideas through the Fundamental Creation Flow.It doesn’t matter what your product is and how your team is structured. You start with a vague need that needs a solution, you push it one step forward to become a schematic solution and one more to become a detailed solution. And then you harness all your energies and team members to move one more step toward execution and make it a reality. You are literally pushing up an idea through the creation cycle.<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*NgFtP4ruFm6O84Oa7xUPwA.png" /><figcaption>Fundamental creation flow</figcaption></figure>And it&#39;s not just you. Everyone who gets up in the morning and attempts to create a reality in this world goes through the same high-level fundamental cycle. Architects, Writers, Artists, Construction contractors, Manufacturers, etc. As product managers, we can, and should, learn from creators in other industries. They encounter similar problems and solve them in wildly different ways from us.<h4>What we learned</h4>Can we leverage construction methodologies to solve the most effort-intensive part of the creation cycle — Execution? Can we plan more confidently and manage the execution with fewer communication breakdowns? We decided to try.At Autodesk, we build software for construction professionals. While conducting research for our Schedule tool, the product we built from scratch and released a few months ago, we were exposed to many techniques that innovative construction companies use to plan and execute some of the biggest projects humanity is building.It made us think.Construction entrepreneurs need to balance end-user needs alongside time-to-market and execution costs continually. Just like us. Construction site managers have dozens of subcontractors to keep synced and sequenced while making sure they can provide clarity on when things will be completed. Just like we need to manage three teams working on the same feature. Construction projects keep changing even when construction is underway and have numerous dependencies and clarifications that need to be resolved to make them tick. Just like every feature we ever built.We methodically embedded three construction management techniques based on<a href="https://leanconstruction.org/"> lean construction</a> methodology. We tweaked them a bit and polished them so they will work for software development. We packed them into an easy-to-embed framework that we call SWORD™.Its stands for — Syncs; WORk planning; Decision log And if parts of it sound like something you’re already doing, that’s great. But the real value lies with all of these parts working together to build a clear, collaborative execution engine.The results were clear from day one. We dramatically improved our ability to plan and track complex projects while minimizing open-ended questions to literally zero. Developers on our team report that they have more confidence in the processes and feel much more ownership over what they build. We call that a success.<h3>So, what is SWORD™ all about?</h3>Let’s get to the details.<h4>Work planning :</h4><figure><img alt="" src="https://cdn-images-1.medium.com/max/640/0*R8AbLAge6rnzp5Wv.jpg" /><figcaption>Construction work planning session; source: <a href="https://theleanbuilder.com/">https://theleanbuilder.com/</a></figcaption></figure>Work planning is a collaborative process that creates more accurate, efficient, and, most importantly — higher team commitment to plans. It is also an artifact that allows full transparency and readability of the execution for all stakeholders. Before every feature or initiative, we have a dedicated work planning meeting. All relevant stakeholders are there. Developers who build the feature, Designers, Products, QA, and others that we feel have experience building similar initiatives. It&#39;s not a kickoff meeting. We actually hold it after the kickoff, and everyone is already familiar with the feature. It is pure planning. We all have a tendency towards under-planning. This meeting, with everyone onboard, ensures you and your team take enough time to plan.The meeting has two parts,1. Work breakdown Each stakeholder with actionable tasks in this feature breakdown his work into tickets. Each ticket gets a working day estimation. Overall guidance is that if a ticket is more than five working days, it should be broken down into two. This is the only noncollaborative part of the process.2. Timing One by one, each team member places their tickets on the timeline. It sounds simple, but this is where the magic happens. The First developer places his tickets, and it usually goes like this:- BE Dev: puts his tickets on the timeline. - Tech lead — “I actually think you should do X before Y. I did something similar a few months ago. - Other BE Dev — “and there’s no way you’ll finish Z in 4 days. It’s at least 7 days work”That&#39;s nice. We just got our BE plan better and more accurate, but that&#39;s not all. Because now all other developers place their tickets as wellFE Dev: puts her tickets on the timeline BE Dev: “You can’t do this; you won’t have the API ready before I finish that ticket” QA: “ I think we better build this BE part before because then when we finish this FE ticket I have a QAable chunk” ( he puts QA ticket in place)The same happens with Designers and Products. Crucial dependencies are revealed, times are communicated and reviewed, and the overall sequence of execution is crystallized a few times and with the people that matter. All parts of the work are planted in the right places with everyone’s agreement and understanding.At the end of the meeting, we have an understandable, collaborative plan committed by the whole team. We pin it to our Slack channels and revisit it regularly (more on that in the Sync part of SWORD)There is no ideal place to handle work planning (yet). We use both Mural and some Construction-specific work planning software. The important thing is to allow color-coding by person and arrange rows by areas of work or vice versa.<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*Ude_0qlA5eVW2bJp" /></figure>(small work planning in Mural. Color-coded by team members. Important milestones that might affect all of the execution are marked with green checkboxes)<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*e64RFAnZxDhtjCG9" /></figure>(parts of a large work plan in construction work planning software. Color-coded by team members and arranged by area of work )<h4>Decision log:</h4>It doesn’t really matter how good you are in moving vague ideas into a concrete PRD. Once execution begins, you will have a bunch of things coming in from Devs, designers, and QAs that will need clear decisions. Don’t try to fight it by creating more detailed PRDs. You can’t. This is just the way reality works. Taking an idea into a schematic solution (high-level requirements and design wireframes for most of us Products) and then into a detailed Solution (detailed PRD document and design specs) is a process of narrowing it down through decisions. The execution phase isn’t any different. You will need to keep getting those in a tight team context, where everyone must be aligned, and decisions must be clear and discoverable.I used to lose items I should’ve decided on and would find out about them minutes before production. I used to decide things, communicate them in slack, and find out the opposite found its way into the code. Something wasn’t working. Our team came up with the Decision Log. A freestyle interpretation of the Construction projects Constraints Log.<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*-HtWLAAqv6-F0HII.jpg" /><figcaption>onsite constraints log; source: <a href="https://theleanbuilder.com/">https://theleanbuilder.com/</a></figcaption></figure>Decision Log is a collaborative table we handle per feature. Everyone has access to it and has the right to add items that need a decision. We try to keep the term “decisions” pretty loose to allow team members to add deliverables that block them or a design that needs a second look. Once a decision is made, it is documented, and its status changes from “To Decide” to “Decided and not synced”. Once requirements are updated, the design is tweaked, and the team is aligned, we change the status into “Decided and synced” Very lightweight. Very efficient.Personally, I also use it to document marketing decisions and high-level value proposition thoughts. This allows all team members to see all aspects of the emerging feature. I also have a filtered view with only open decisions I need to make across all features. For the first time in my career, I can open my day with a clear view of all the decisions I need to make. No multi-channel slack browsing, no going through the list of developers in my mind and thinking about what I owe to whom. Clear, collaborative, transparent decision log.<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*qBQmO4UftBNdWl-0" /></figure><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*IRvjMHu7vTdcgWZl" /></figure><h4>Syncs</h4>We all do syncs. But they are not always that efficient. With Workplan and Decision log built into your process the syncs will get a new flavor and will become the place where everything gets connected. In our team, the feature owner — the developer who is responsible for making the feature happen, is the one who runs the syncs. And it has a very clear structure.(1) Go over the decision log — what’s open? What’s been recently decided but hasn’t been communicated? What’s the priority of the decisions? This part makes sure everyone is aligned on the information.(2)Go over the workplan — where are we? What is the next milestone? Who should get involved next? If needed- edits are made, and tasks are moved around to ensure the work plan reflects reality.<h3>Bottom line</h3>We have been working according to the SWORD framework for almost a year. Every feature we kickoff gets its own Workplan, its own Decision Log and dedicated syncs. With all its parts combined, we feel that this new framework provides unrivaled clarity and efficiency.<h3>Acknowledgments</h3>The creation of SWORD framework is a joint effort of Nitzan Sankevitz ; Einav Kivshany and myself. It was piloted, polished and fully adopted by the amazing Schedule team in Autodesk (Odiya Erlichster ; Liron Zluf ; Dor Tchizik ; Vipul Singh ; Gilad Green and Sagi Yemini)<img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=4fb505e0bc7d" width="1" height="1" alt=""><hr><a href="https://medium.com/autodesk-tlv/how-construction-project-management-boosted-our-software-execution-4fb505e0bc7d">How construction project management boosted our software execution</a> was originally published in <a href="https://medium.com/autodesk-tlv">Autodesk TLV</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

The case for learning from traditional industries
What does software product delivery have to do with Manufacturing or Visual arts?
Well, they are all in the business of creation. And therefore, they all share a high-level fundamental process of taking a vague idea and turning it into reality.
We call it the Fundamental Creation Flow, and as product managers, we are essentially doing one thing — moving ideas through the Fundamental Creation Flow.
It doesn’t matter what your product is and how your team is structured.
You start with a vague need that needs a solution, you push it one step forward to become a schematic solution and one more to become a detailed solution. And then you harness all your energies and team members to move one more step toward execution and make it a reality.
You are literally pushing up an idea through the creation cycle.
Fundamental creation flow
And it's not just you. Everyone who gets up in the morning and attempts to create a reality in this world goes through the same high-level fundamental cycle. Architects, Writers, Artists, Construction contractors, Manufacturers, etc. 
As product managers, we can, and should, learn from creators in other industries. They encounter similar problems and solve them in wildly different ways from us.
What we learned
Can we leverage construction methodologies to solve the most effort-intensive part of the creation cycle — Execution? Can we plan more confidently and manage the execution with fewer communication breakdowns?
We decided to try.
At Autodesk, we build software for construction professionals.
While conducting research for our Schedule tool, the product we built from scratch and released a few months ago, we were exposed to many techniques that innovative construction companies use to plan and execute some of the biggest projects humanity is building.
It made us think.
Construction entrepreneurs need to balance end-user needs alongside time-to-market and execution costs continually. Just like us. 
Construction site managers have dozens of subcontractors to keep synced and sequenced while making sure they can provide clarity on when things will be completed. Just like we need to manage three teams working on the same feature. 
Construction projects keep changing even when construction is underway and have numerous dependencies and clarifications that need to be resolved to make them tick. Just like every feature we ever built.
We methodically embedded three construction management techniques based on lean construction methodology. We tweaked them a bit and polished them so they will work for software development. 
We packed them into an easy-to-embed framework that we call SWORD™.
Its stands for — Syncs; WORk planning; Decision log 
And if parts of it sound like something you’re already doing, that’s great. But the real value lies with all of these parts working together to build a clear, collaborative execution engine.
The results were clear from day one. We dramatically improved our ability to plan and track complex projects while minimizing open-ended questions to literally zero.
Developers on our team report that they have more confidence in the processes and feel much more ownership over what they build.
We call that a success.
So, what is SWORD™ all about?
Let’s get to the details.
Work planning :
Construction work planning session; source: https://theleanbuilder.com/
Work planning is a collaborative process that creates more accurate, efficient, and, most importantly — higher team commitment to plans. It is also an artifact that allows full transparency and readability of the execution for all stakeholders.
Before every feature or initiative, we have a dedicated work planning meeting. All relevant stakeholders are there. Developers who build the feature, Designers, Products, QA, and others that we feel have experience building similar initiatives. 
It's not a kickoff meeting. We actually hold it after the kickoff, and everyone is already familiar with the feature. It is pure planning. 
We all have a tendency towards under-planning. This meeting, with everyone onboard, ensures you and your team take enough time to plan.
The meeting has two parts,
1. Work breakdown 
Each stakeholder with actionable tasks in this feature breakdown his work into tickets. Each ticket gets a working day estimation. Overall guidance is that if a ticket is more than five working days, it should be broken down into two. This is the only noncollaborative part of the process.
2. Timing
One by one, each team member places their tickets on the timeline. It sounds simple, but this is where the magic happens. 
The First developer places his tickets, and it usually goes like this:
- BE Dev: puts his tickets on the timeline.
 - Tech lead — “I actually think you should do X before Y. I did something similar a few months ago. 
- Other BE Dev — “and there’s no way you’ll finish Z in 4 days. It’s at least 7 days work”
That's nice. We just got our BE plan better and more accurate, but that's not all. Because now all other developers place their tickets as well
FE Dev: puts her tickets on the timeline
BE Dev: “You can’t do this; you won’t have the API ready before I finish that ticket”
QA: “ I think we better build this BE part before because then when we finish this FE ticket I have a QAable chunk” ( he puts QA ticket in place)
The same happens with Designers and Products. Crucial dependencies are revealed, times are communicated and reviewed, and the overall sequence of execution is crystallized a few times and with the people that matter.
All parts of the work are planted in the right places with everyone’s agreement and understanding.
At the end of the meeting, we have an understandable, collaborative plan committed by the whole team. We pin it to our Slack channels and revisit it regularly (more on that in the Sync part of SWORD)
There is no ideal place to handle work planning (yet). We use both Mural and some Construction-specific work planning software. The important thing is to allow color-coding by person and arrange rows by areas of work or vice versa.

(small work planning in Mural. Color-coded by team members. Important milestones that might affect all of the execution are marked with green checkboxes)

(parts of a large work plan in construction work planning software. Color-coded by team members and arranged by area of work )
Decision log:
It doesn’t really matter how good you are in moving vague ideas into a concrete PRD. Once execution begins, you will have a bunch of things coming in from Devs, designers, and QAs that will need clear decisions. 
Don’t try to fight it by creating more detailed PRDs. You can’t. This is just the way reality works. Taking an idea into a schematic solution (high-level requirements and design wireframes for most of us Products) and then into a detailed Solution (detailed PRD document and design specs) is a process of narrowing it down through decisions. The execution phase isn’t any different. You will need to keep getting those in a tight team context, where everyone must be aligned, and decisions must be clear and discoverable.
I used to lose items I should’ve decided on and would find out about them minutes before production. I used to decide things, communicate them in slack, and find out the opposite found its way into the code. Something wasn’t working. 
Our team came up with the Decision Log. A freestyle interpretation of the Construction projects Constraints Log.
onsite constraints log; source: https://theleanbuilder.com/
Decision Log is a collaborative table we handle per feature. Everyone has access to it and has the right to add items that need a decision. We try to keep the term “decisions” pretty loose to allow team members to add deliverables that block them or a design that needs a second look. 
Once a decision is made, it is documented, and its status changes from “To Decide” to “Decided and not synced”. Once requirements are updated, the design is tweaked, and the team is aligned, we change the status into “Decided and synced” 
Very lightweight. Very efficient.
Personally, I also use it to document marketing decisions and high-level value proposition thoughts. This allows all team members to see all aspects of the emerging feature. 
I also have a filtered view with only open decisions I need to make across all features. For the first time in my career, I can open my day with a clear view of all the decisions I need to make. No multi-channel slack browsing, no going through the list of developers in my mind and thinking about what I owe to whom. Clear, collaborative, transparent decision log.

Syncs
We all do syncs. But they are not always that efficient. With Workplan and Decision log built into your process the syncs will get a new flavor and will become the place where everything gets connected. 
In our team, the feature owner — the developer who is responsible for making the feature happen, is the one who runs the syncs. And it has a very clear structure.
(1) Go over the decision log — what’s open? What’s been recently decided but hasn’t been communicated? What’s the priority of the decisions? This part makes sure everyone is aligned on the information.
(2)Go over the workplan — where are we? What is the next milestone? Who should get involved next? If needed- edits are made, and tasks are moved around to ensure the work plan reflects reality.
Bottom line
We have been working according to the SWORD framework for almost a year. Every feature we kickoff gets its own Workplan, its own Decision Log and dedicated syncs. With all its parts combined, we feel that this new framework provides unrivaled clarity and efficiency.
Acknowledgments
The creation of SWORD framework is a joint effort of Nitzan Sankevitz ; Einav Kivshany and myself. It was piloted, polished and fully adopted by the amazing Schedule team in Autodesk (Odiya Erlichster ; Liron Zluf ; Dor Tchizik ; Vipul Singh ; Gilad Green and Sagi Yemini)

How construction project management boosted our software execution was originally published in Autodesk TLV on Medium, where people are continuing the conversation by highlighting and responding to this story.

Shape the world,
shape your future.

Design it.
Build it.
Autodesk it.

Our product.

Shape the world,
shape your future.

Design it.
Build it.
Autodesk it.

Our product.

Shape the world,
shape your future.

Autodesk Construction Cloud

Collaboration at its best

A Day At The Office

Our Blog

Podcast

Autodesk handles software design and development that affects the lives of hundreds of millions of people around the world on a daily basis. Autodesk Israel supports the creation of a varied work environment for the development of innovative technologies, alongside an original and creative design.

Links

Design it.Build it.Autodesk it.

Autodesk Construction Cloud

Collaboration at its best

A Day At The Office

Our Blog

Podcast

Design it.
Build it.
Autodesk it.