SOGETI UK BLOG

new-32199_960_720

 

For years the .NET Framework used by Microsoft developers has targeted to run on Windows and other Microsoft products.  There has been 3rd party projects such as Mono and Xamarin which allow you to run some applications on Linux, Mac, Android, and iOS.  There has always been many flavors and subsets of the .NET Framework.  Running a subset on another operating system has always felt like a second class citizen.  Now in a complete reversal from Microsoft, they have announced that the new version of .NET Framework which is called .NET Core 1.0 will be able to run on other operating systems.  Microsoft has also released Visual Code which is a software development environment that can run on Windows, Mac, or Linux.    That means a software developer could create .NET web application on a Mac and then run it in Linux.  A developer could create a .NET application on Linux and then run it in Azure.

This is simply great news for the development community.  The .NET Framework, Visual C# language, and Visual Studio are known for increasing developer productivity.  I can’t imagine the kind of positive impact this is going to have in the developer community.  ASP.NET Core 1.0 will most likely replacewhat will be known as classic ASP.NET.

.NET and its competitor Java have been leap frogging each other in features for as long as I can remember.  Java has always had a slight edge because it could run on any platform.  Now the last wall has been broken through.  .NET Core 1.0, coming soon to a platform near you.

 

Greg Finzer AUTHOR:
Greg Finzer is the Custom Application Development Community of Practice Lead for the Sogeti Columbus Region. His duties include identifying technology trends, facilitating access to training & certifications, developing architecture expertise, supporting sales & delivery, and increasing participation in the local developer community.

Posted in: Azure, Data structure, Developers, Human Interaction Testing, Infrastructure, Innovation, Microsoft, test framework, Transformation      
Comments: 0
Tags: , , , , , , , , , , ,

 

skipping requirementsTop 10 Blogs of 2015 :  Blog no. 8 ( Originally published on 13th March 2015)

Running a project with Agile or Scrum methodologies does not mean that it’s ‘OK’ to skip functional requirements. Once, there was a company that gave application mockups to its developers without providing any details about what the application was supposed to do. It was left to the developers to guess what actions the application should perform, based on the mockups. As expected, this led to a lot of iterations and unnecessary exchanges between the business and the developer. Days (of work) were wasted, as the changing functional requirements were communicated verbally to the developer. When the application was ready to be tested, the requirements changed again, because there were former business users in the QA department.

 

Essentially, application requirements should consist of mock ups (also known as wireframes), business rules, a functional description of what each button/link does, and a list of the fields with their types and lengths. Requirements should be completed and signed off by the business before development begins. It is best if requirements are completed in related screens, so that the architect gets a broad view of things and is able to guide the developers accordingly.

I am not proposing Waterfall, where all the requirements of the entire application are addressed up front, while the developers wait. Ideally, this is what needs to happen: The business analysts would have their own iterative requirements cycle, coming before the iterative development cycle. In my opinion, there should be one business analyst for every four or five developers. If there is fewer analysts, it creates a bottleneck.

The goal of having good functional requirements, which are signed off by the business, is to reducescope creep and changes. This in turn will help reduce costs. Also, developers are typically the most expensive resources (after the managers) in an IT department. Therefore, it’s wise to make the best use of their time and skills.

Would you be able to build a car with just a picture and no specifications? I suppose not. So, neither should you attempt to build any software that way.

 

Greg Finzer AUTHOR:
Greg Finzer is the Custom Application Development Community of Practice Lead for the Sogeti Columbus Region. His duties include identifying technology trends, facilitating access to training & certifications, developing architecture expertise, supporting sales & delivery, and increasing participation in the local developer community.

Posted in: architecture, Business Intelligence, Developers, Digital strategy, Infrastructure, Innovation, project management, Quality Assurance, Research, Software Development, Uncategorized      
Comments: 0
Tags: , , , , , , , , ,

 

Source: http://www.riceconsulting.com/public_pdf/STBC-WM.pdf

 

 

This is a follow up to my previous post, “How many defects are too many?”   Now that we are tracking defects, how can we do better?

The earlier that defects can be found in an application, the less expensive      they are to fix.  Defects that are found during QA are ten times more                expensive to fix.  Production defects are one hundred times more expensive    to fix.

 

 

Source:http://www.riceconsulting.com/public_pdf/STBC-WM.pdf

What are some practical ways to improve the quality of application early?

  • Test Driven Development (TDD) – This is where developers create automated unit tests before they create the methods that do the work.  Testing frameworks include NUnit, Microsoft Test, and MBUnit.
  • Behavior Driven Development (BDD) – BDD takes TDD a step further to produce tests a business owner can understand using a tool like Cucumber or SpecFlow.
  • Integration Tests – These are automated tests that hit external systems such as databases and services.
  • Mocking – This is where an integration point is replaced with a mock object so that only one integration point is tested at a time. There are many mocking frameworks available such as RhinoMocks, MOQ, and JustMock.
  • Continuous Integration – This is where tests are automatically run when code is checked in. Unit tests should be run during every code check in.  Integration tests should be run every hour.  Tools include Team Foundation Server, TeamCity, and CruiseControl.NET.
  • Code Coverage – This is a percentage of tests compared to the lines of code. If a developer checks in a bunch of code without corresponding tests, the build can be failed with a tool like NCover or dotCover.
  • Code Reviews – Another developer reviews the code after it is checked in.
  • Automated Quality Testing – There are tools available that can check your application for quality such as Microsoft Code Analysis, NDepend, and Gendarme.
  • Manual Testing – This is where a Quality Assurance tester ensures the application meets the requirements. Tests should include:
    • Positive Testing – The happy path where the user enters everything correctly.
    • Negative Testing – The user enters bad data into every field.
    • Edge Testing – The user enters blank, low numbers, high numbers, minimum dates, maximum dates, and long strings.
    • Double Click Testing – The user double clicks buttons that should be single clicked.
    • Single Quote Testing – The user enters names like O’Reilly which may break some database queries.
    • Performance Testing – Test areas of an application where high usage is expected.
  • Automated Front End Testing – In business critical systems it may make sense to create regression tests that can be automatically run at any time as if a user was interacting with the website. An example of this type of tool is Selenium.

What best practices do you use?

 

Greg Finzer AUTHOR:
Greg Finzer is the Custom Application Development Community of Practice Lead for the Sogeti Columbus Region. His duties include identifying technology trends, facilitating access to training & certifications, developing architecture expertise, supporting sales & delivery, and increasing participation in the local developer community.

Posted in: Behaviour Driven Development, integration tests, Quality Assurance, Research, Test Driven Development      
Comments: 0
Tags: , , , , , , , , , , ,

 

Image 1According to the NY Times and US News there were 600,000 people that left cable in the first two quarters of 2015.  This year is shaping up to be a pivotal year for Cable TV.  I am cutting the cord this month after over twenty years subscribing to cable.  The price is simply out of control.  There are many streaming options that make it worthwhile to switch: 

Roku 3 – This is a tiny streaming box that has Netflix, Hulu, Amazon Prime, PBS Kids, History Channel, NBC News, Fox News, CBS All Access, and thousands of other Roku channels. Image 2

Image 3Tablo – This is an over-the-air DVR.  It is viewable through Roku.  Buy an antennae & hard drive and you now have all the major networks at no monthly fee.  There is a lifetime fee for the Tablo guide.

V-Tech Connect To Cell – This replaces your old land line and connects to up to two cell phones via Bluetooth. Image 4

Image 5Sling TV – Dish Network came out with a package of popular streaming channels for $20/month, far less than normal packages.  You can add other groups of channels for $5.  The downside is that the content cannot be recorded or paused to view later.  This may be an option for sports lovers.  This also works with Roku.

PlayOn – This is a software package that integrates with your PC and Roku.  It allows you to stream from websites to the Roku. Image 6 For example, the HGTV website has episodes of Flip or Flop that you can now watch on the Roku.

Image 7Plex is a software package that allows you to view your collection of pictures and home videos on Roku.  A bonus is that it also has channels like Food Network and Comedy Central.  Plex has a free version too.
The shift away from live content to on demand content is accelerating.  This is as dramatic as the change from Music CDs to MP3s.  Consumers want to pick channels a la cart with instant content.  Providers need to adapt.

If they do not adapt, I can see Netflix as the sole vendor of all video content in the world.  Are you sticking with cable or cutting the cord?  Why?

Greg Finzer AUTHOR:
Greg Finzer is the Custom Application Development Community of Practice Lead for the Sogeti Columbus Region. His duties include identifying technology trends, facilitating access to training & certifications, developing architecture expertise, supporting sales & delivery, and increasing participation in the local developer community.

Posted in: beta testing, Digital, Digital strategy, High Tech, Human Interaction Testing, Innovation, mobile applications, Open Innovation, Research, Social Aspects, Software Development, User Experience, User Interface, Virtualisation, Webinars      
Comments: 0
Tags: , , , , , , , , , ,

 

in flamesAccording to the book Software Craftsmanship, an application should last longer than ten years. Joel Spolsky goes even further to say that “the single worst strategic mistake…rewrite the code from scratch.” Developers, on the other hand, are quick to bring up to their management, the need for a rewrite when they feel that the code is a mess. Should you ever throw the old application into the fire and write a new one?

What drives business is revenue and agility. Here are some business reasons to re-write an application:
1. Rewrite when the code base causes a high turnover in resources. I once worked for a company where the code base was so awful to work with that there was a 70% turnover in the IT Department every year. The turnover significantly impacted the company’s bottom line. I have also seen an entire IT department leave, because no time was being allowed by the business for refactoring. It took the replacement developers twenty times longer to find and change the code.
2. Rewrite when a technology is deprecated by the language vendor. If there is no clear upgrade path to the latest version, this will cause a development resource shortage. I talked to a manager recently where their core business application was written in VB6. They were unable to find any developer resources that desired to maintain it.
3. Rewrite when the maintenance costs are causing a negative net operating profit. There was an application, which had such a high maintenance cost that it caused the company to abandon the product.
4. Rewrite when it affects your customers. If the performance or user experience is causing your business to lose customers to your competitors, rewrite those pieces.
5. Rewrite when it affects the agility of your business. If the maintainability of the application prohibits frequent releases, look into what is causing the delays. Keep track of your competitors. How often do they release? What new features did they add?
6. Rewrite the application when the refactoring cost is higher than a rewrite. Estimate how long it will take to refactor the application versus how long it will take to rewrite it. Long term cost savings will be gained by increasing the maintainability of the application.

What other reasons do you think warrant a rewrite? Share your thoughts.

To read the original post and add comments, please visit the SogetiLabs blog: When should you rewrite an application?

Related Posts:

  1. What are the best practices for improving the quality of an application?
  2. Is Cloud a return to the Stone Age?
  3. Decrease Application Delivery Time by 80%
  4. Be lazy to make your customers happy!

 

Greg Finzer AUTHOR:
Greg Finzer is the Custom Application Development Community of Practice Lead for the Sogeti Columbus Region. His duties include identifying technology trends, facilitating access to training & certifications, developing architecture expertise, supporting sales & delivery, and increasing participation in the local developer community.

Posted in: Application Lifecycle Management, Behaviour Driven Development, Business Intelligence, Technology Outlook      
Comments: 0
Tags: , , , , , ,