Skip to main content

Day 4 of Software Architecture 2012 & Agile and OO design

Today was the last day of Software Architect 2012. Last day was dedicated to workshops and I decided to join Allen Holub session: “Agile/OO design from start to finish”. After these days I become a fan of A. Holub and I hope that I will be able to implement a correct OO design. It is pretty challenging, but I promise that I will try to write about this in future.
Here are some notes from the presentation that I considered important. A part of them are well known by all of you:
Agile is based on communication, but there are people that will not be able to integrate in a team environment. Even if they are great on technical side and have a lot of knowledge, they are not able to communicate and to share data. Sharing is one of the most important things in Agile. The biggest enemy for Agile is EGO. Because of this people will not be able to communicate and different roles will appear – “I am the MASTER and the team need to do as I say.” – WRONG.
When we are talking about user-stories, management should understand the concept of points and the relations between points and duration – there is no relationship. Also when the team say, there are 50% percent chances to not be able to finish at time, than the chances are pretty high.
If you have a bunch of user-stories, start with the one that are the most risky. You will need time to clarify and resolve them. Also if you have a complicate or a user story that is very big than you should slit him? One good solution here is for the first sprint to consider only one happy flow, after that another, or an exceptional flow and so on. In this way we will be able to make it more and more complex at each iteration. Your scope is to have something that is fully functional at the end of every iteration.
Be strong and in the moment when someone wants to take off a man from the team say “NO!” This action can affect the project velocity; because of this there are chances not to finish all the user stories at the end of the iteration.
I didn’t use the SCRUM and SPRINT terminology.  Why? SCRUM is not the only way to be AGILE. From some perspective SCRUM is not agile, in the current “implementation”.
I will finish this post blogs about this conference with two cited that I heard today and I like:
“A ‘bug’ is not a logic error; it is a missing unit test.”
“Each team member is responsible for his own word and the team is responsible for the entire project (all the code and artifacts that are generated).”

Comments

Popular posts from this blog

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

Azure AD and AWS Cognito side-by-side

In the last few weeks, I was involved in multiple opportunities on Microsoft Azure and Amazon, where we had to analyse AWS Cognito, Azure AD and other solutions that are available on the market. I decided to consolidate in one post all features and differences that I identified for both of them that we should need to take into account. Take into account that Azure AD is an identity and access management services well integrated with Microsoft stack. In comparison, AWS Cognito is just a user sign-up, sign-in and access control and nothing more. The focus is not on the main features, is more on small things that can make a difference when you want to decide where we want to store and manage our users.  This information might be useful in the future when we need to decide where we want to keep and manage our users.  Feature Azure AD (B2C, B2C) AWS Cognito Access token lifetime Default 1h – the value is configurable 1h – cannot be modified

What to do when you hit the throughput limits of Azure Storage (Blobs)

In this post we will talk about how we can detect when we hit a throughput limit of Azure Storage and what we can do in that moment. Context If we take a look on Scalability Targets of Azure Storage ( https://azure.microsoft.com/en-us/documentation/articles/storage-scalability-targets/ ) we will observe that the limits are prety high. But, based on our business logic we can end up at this limits. If you create a system that is hitted by a high number of device, you can hit easily the total number of requests rate that can be done on a Storage Account. This limits on Azure is 20.000 IOPS (entities or messages per second) where (and this is very important) the size of the request is 1KB. Normally, if you make a load tests where 20.000 clients will hit different blobs storages from the same Azure Storage Account, this limits can be reached. How we can detect this problem? From client, we can detect that this limits was reached based on the HTTP error code that is returned by HTTP