Deriving Value Out Of Available Data In Software Products

This topic is becoming the recent  trend and an interesting topic for various software organizations. Earlier we had software products that our customers were using for years together and of course there is something to learn as to how the products were being used, what feature of the products our customers used the most, how many times the product crashed in the site. This report was never collected and analyzed. And there is a problem in not doing this at all.

This article talks about how we can make our products collect and log the 'useful' data that helps product developers see how product is performing and what are customer pain points and improvement areas. This does happen through customer calls and by reading the issues that customers reported. But how about collecting all these data, analyzing and giving solutions automatically or seeing if we can provide altogether new value add services using the collected data?

I would like to quote an example that a device requires servicing and software controlling the devices know that it needs service. This data can be used for maintenance service and can be provided SaaS (Software as a Service) to customers so that customer knows when to service and what device. Nevertheless this becomes difficult for customers to know this information given thousands of device in a site.

The current problems are (though they vary from product to product), the products lack the feature of logging the data(they never designed to do that), the 2nd problem is that even if the products log the information, the information is not used to derive any value, may be data is collected in such a way that it can be used to derive some value. Some products are deployed offline and do not have the internet connectivity and hence the data is not reachable at all unless there is alternate mechanism to collect it.

We can solve the first problem by delivering a revised software products that have capability to log data. The second problem can be solved by having intermediate software. For example, mobile app that connects to products and gets the data and then sends may be to central server where data can be further processed.

More data can be analyzed to supervisory layer since different products are usually connected to supervisory layer. And this is exactly the big data concept which already industries are investing into. There are good business opportunities when data is used for value adds. This can take advantage of cloud computing that is present today. The product data can be pushed into cloud and run programs to process data; provide value add services to customers.

How to Avoid Common Software Build Errors/Mistakes

In software projects, there are number of chances that build/packaging errors may occur. And the cost to fix the build errors is high especially in an environment were water fall software development methodology is being followed. This is because some build errors are not caught during smoke test and found late during system integration testing. In the latest Agile/Scrum methodologies, the builds are made continuously on daily basis and an engineer verifying the build. Hence it becomes extremely important to double verify the build.

Some of the common causes of build errors are

•  Manual Method of building & packaging: In today's complex software systems, manual builds are never encouraged and are definitely error prone. 
• Build procedure getting changed frequently: This happens because new release assets can get added during software development and existing build procedure becomes obsolete and engineers will have to exercise extra caution on the current build procedures.
•  Changing the build engineer frequently: The complete knowledge transfer may not happen. Certain gaps in understanding the build procedures cause the build errors to occur.
• Lack of build verifications: The build is not verified for correctness.

Let me share some best practices that we can follow to avoid/minimize the build or the packaging errors.

•  Automate build & packaging process: Automation is said to be avoiding the build errors, however the automation scripts have to be verified for correctness before you trust the automated build. Then automation not only avoids build mistakes but also takes less time to create release deliverable. Have a look at the article 'How to automate software builds'.
• Have a build verifier: This can be a software tool or a manual method of verifying the built software deliverable for correctness. No matter how much caution you have taken while building/packing the software, believe that there can always be errors in doing that and hence verification is very much required. The verification typically has elements such as necessary of deliverable and their version numbers are correct or not, verifying unit test execution results etc.
• Smoke Test the build: Certain build errors can be beyond what build verifiers do. In that case, certain smoke test cases can be performed to possibly detect the build mistakes. These smoke test cases high level test cases covering main functionality of the software itself.

Build errors/Mistakes can cause schedule slippages and hence a dedicated build engineer who understands the software system and is aware of the automated build scripts, recent software changes etc is pretty much required.

Android OS does not support Ad-Hoc wifi network (Nokia Joikuspot)

Yes, this is very disappointing fact. Though linux OS support ad-hoc networks, the Google has disabled this feature in its android OS! The reason is not published from Google yet for this. (If anyone knows the reason, please post).

I had no idea on this when I bought Nexus 7. I use Nokia C6-01 and have installed Joikuspot which converts the phone to wifi hotspot. I use this wifi for my laptops, but nexus 7 just does not identify this network and so with any android phones or tablets. The limitation of Joikuspot is that it can only generate ad-hoc wifi but android hates this type of wifi network.

See what users saying at
https://code.google.com/p/android/issues/detail?id=35629

There are workarounds to get rid of this restriction posed by Android OS. I just spent some time researching on that and thought of sharing the same in this post.

Solution1:  Root your android device to get admin rights. For instructions read. Be extra cautious for this method.
http://forum.xda-developers.com/showthread.php?t=1591207

Or relative posts in above site. You can trust the instructions in the above website.

Solution2: There is an app called BlueVPN which you can install in your android device and pair your  phone with android device. For instructions see below link.
http://techupdatenow.blogspot.in/2012/09/connecting-your-nexus-7-using-symbian.html

Solution 3:  Use standard wifi networks. I am saying this because, rooting your android device may some other limitations. For example, your google wallet may not work because your network will not be secure etc.

Hope this post helps.

Problems and Best Practices for Successful Execution of PSI (Potentially Shippable Increment) - Scrum Methodology

Agile method of software development is a proven customer oriented software development methodology that's being adopted by many software organizations. In this methodology, the software is released/demo-ed to the customers incrementally so that customers can see the software that they requested for and give early inputs if they are not satisfied with the software. The engineers plan the software development in such a way that the software is a working and users can play with it. As engineers, how to plan the software development activities so that its shippable to customers is tricky task. In this post, I’m going to explain some of the best practices to follow while planning the software activities for potentially shipping software.

PSI planning is coming up with objectives and committing to them with the business in agreement with Product Owners(PO), Marketing, architecture team, System testing team and the targeted customers. Product owner will pick the features from the backlog and assigns a business priority. The top software features will be presented to the team by product owner.

The most common problems that are encountered during PSI planning is the estimation part. Since the software features are very high level and the developers may not realize the depth of the problem by reading once, the teams end up committing to the features, however in reality the effort required is more. Again this depends on the maturity of the scrum team. If the features that are going to be implemented are of the similar kind that was executed by the scrum team in the past, probably the team is pretty confident on the estimation. It’s true that each sprint is time-boxed and the team need not worry if a particular feature is not completely implemented due to incorrect estimation done; but the PSI end goal will be to ship something that's working and the customers can use it. To improve on this hurdle, have a look at Estimation Accuracy.

Another problem is that some feature that is partially implemented that can be shown to the users. Or the feature is completely implemented but the supporting hardware is not yet available. In this scenario, the effort spent in implementing a particular feature holds good, however the partially implemented feature can be 'hidden' from showing up to the customers and unhide when the feature is fully functional. To avoid this, plan and anticipate all the problems that may occur to release a planned software feature as potentially shippable increment.

It may so happen that after fully planning the PSI, new tasks may pop in during sprint executions such as a critical customer issue which comes as a very high priority from the management. Taking up unplanned activities must be minimized as much as possible to smoothly execute the PSI. Otherwise very low priority objectives from the PSI can be moved to the backlog and new task can be taken up but this has to be on case by case basis and not a good practice any way. There is another problem if new, unplanned activities are taken up during the PSI, that is, other dependent teams also need re-planning such as System Testing team to test the planned task if that is impacting the systems.

Make the scrum team members aware of the features that are in the backlog. This is usually during "Backlog Grooming". By letting people know the work that the team is going to take up, allows teams to think about the tasks and realize the depth of the tasks before even planning and thus helps a great deal during PSI planning.

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” - http://scaledagileframework.com

The importance of Code Reviews in Software Development Life Cycle - Few thoughts & Suggestions.

This is a debatable topic. Different people have different opinions about the code reviews. Some people think code review task does not add any value to the customer. You can't say that I spent 300 hours reviewing the code because customer does not understand and does not care as long as he/she gets what he/she wanted. Also, some people will not feel comfortable having peer programmers reviewing their code. That said, there are people who think code review is important; it helps find the bugs, subtle design issues also helps find the impacts of the code change in a huge existing system.

So both categories of people are right here, because several parameters are considered before saying if the code review is really needed. Consider for example a team where programmers are in different experience levels and the software system the team is dealing with is legacy system. Relatively modifying the legacy code written by somebody else some time back with no good documentation, comments is prone to pose the impacts on software functionality if the code changes are not reviewed with someone who understands the design of the entire system. So these are just few parameters that I'm mentioning and it varies between team to team and nature of the project in hand.

There are third category of people who think that its programmers responsibility to code it perfect from quality perspective. The review sometimes does not guarantee that all the software defects/impacts are found. It’s the programmer who is coding has to gather as much information as the programmer wants to better understand the existing as well as the system before changing something in the system. Of course this takes a while for newbie programmers to be expert programmers or coders. This can be achieved with coaching the team members about coding, system and the domain.

Then who are the best reviewers? Is it somebody other than who coded? How difficult is the code review task? Why is code review really needed? Answers to these questions have to be found before taking up the reviews. The best person to review is the one who has knowledge about the entire software system, including sub-systems. Based on the past experiences of the nature of issues found in the system, the reviewer thinks towards if there is chance of something not working or a problem with the code that makes it not function with other sub-systems or if there is any security vulnerability or loop hole in the code.

So it does make sense to define the review focus. Of course the review can focus on several aspects, but based on the nature the software and its past performance; the review focus should be defined. For example, for legacy system, it’s about finding the impacts, for network related software, the review focus will be on finding security vulnerable etc. In my opinion, review is required; however, the review focus has to be defined. Review is a tough task sine the reviewer has to put himself into the mind of the programmer who coded and then think how the code is going to work.

How To Debug From Eclipse The Remote Java Applications - Improve Development Productivity

Debugging code you have written would be a very time consuming process if not debugging techniques are not used. Eclipse IDE is most preferred for developing Java Programs these days and eclipse comes with the feature of configuring and using the debugger.Using debugger, developer need not spend time placing Sys out statements in the code, run the program and see the console for print outputs. This method of debugging becomes a nightmare when you are dealing with complex java projects. Building and running such applications take considerable amount of time. In this post I'm going to show how to configure and debug the remote java programs.

1. Build the Java Application Jars using -g command line argument to generate only some debugging info
2. Run the remote java application using JVM debug options as java @agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=y -jar remoteJavaApp.jar
3. Start remote debugging through eclipse with source code attached. From debug configuration create settings for 'Remote Java Application' using the port address and attach the source code of our application.

Under Eclipse define debugger as shown in the following picture,

 

Configure External (Remote) Java program as shown below

  

 

Enter remote Java application details in the new configuration as shown below.

Click run button to launch the remote java application and then attach the Eclipse debugger from the "Debug" icon and there you go debugging your remote java application.