SOGETI UK BLOG

carlosmendibleblog_img_20161013_185558_01

I started the day in a coffee shop and I got a nice spot right next to a window. As I take out my Surface Book and turn it on, in a matter of seconds my face is recognized so there is not need to use the keyboard to login. A couple of minutes later Cortana reminds me that I have to write this post, so I ask her what’s trending, and of course she pops an Edge window with some interesting news about cybersecurity issues and privacy.

I’m wearing a Microsoft Band, my fingerprints are known by my OnePlus 3 smartphone, Cortana knows where I live and where I work, my favorite team and, just like Amazon, she knows exactly what I like!!! All of those things make my life more comfortable and allow me to focus on more important things, it makes me more “intelligent”. But at what cost?

In cities such as Copenhagen, thanks to a wireless network of streetlamps fitted with sensors it’s possible to go around the city, in bike, avoiding the red lights just by following a string of green lights in the bike path. Some predictions state that by 2020 there will be around 26 billion “things” in the Internet of Things so it’s a fact that sensors are and will be all around us.

So how do we know those street lamps are not recording more than traffic congestion? How can all of us be sure that all this data we feed into the great corporation’s datacenters will not be used against us? What are the trade-offs of this new era?

This week, I attended the Microsoft Summit in Madrid. The message was clear that Microsoft is betting on AI as the 4th industrial revolution. Their Azure SaaS offering is incredible and the fact that anybody with a credit card can have access to Machine Learning, Big Data solutions and cognitive services such as face recognition is and will continue to be a driving force for this new era. Other companies such as Apple or Google are working on the same direction.

Therefore, stopping or slowing down IoT, Big Data and AI is out of the picture, so the Important question is, how we can provide the protections we need for our privacy, our security, and our safety?

Cortana just told me I have to go downstairs and pick up my daughter and since it’s almost lunch time she also showed me a selection of restaurants near my location which offer the food we love.

I have to go and while I close the Surface I can’t escape this scary feeling that my privacy is dead.

Carlos Mendible AUTHOR:
Carlos Mendible has been .Net Architect for Sogeti Spain since 2012. He is Head Solutions Architect in, one of our major clients, A3 Media, and is also responsible for assisting with the sales process as Pre-Sales Engineer and for conducting workshops and training sessions.

Posted in: Behaviour Driven Development, Big data, Business Intelligence, Digital strategy, Human Behaviour, Internet of Things, IT Security, privacy, Security, User Experience, user stories      
Comments: 0
Tags: , , , , , , , , , , , ,

 

Over the last couple of months, I’ve noticed that a lot of companies are trying to hire DevOps Engineers or DevOps Experts and I have to ask what are these companies looking for?

DSC_0951-2

Reading some of the job descriptions I found out that some are looking for experts on the tooling associated with infrastructure automation such as Chef or Puppet while others search for Developers with infrastructure knowledge.

Some posts you can find all over internet suggest that those who want to become a DevOps should start to study the language associated with the automation platform of their choice. Some IT academies go as far as specifying that a “DevOps Analyst” is someone with the following expertise: BPMN, ITIL Foundation, Cobit Foundation, Scrum, Microsoft Visual Studio, Suites DevOps (Puppet), CompTIA Security+, CompTIA Linux+, MCSA Windows Enterprise (70-688), MCSA Windows Server (70-411 and 70-412).

Do you see the problem with that? Is it a Dev or an Ops that organizations are looking for? Or a blend?

Now, I think that we all can agree that:

  • DevOps is a hot trend.
  • DevOps is a culture
  • DevOps is about people communicating with each other, collaborating, changing their mindset so it’s possible to improve and automate every process involved in software delivery.
  • DevOps is not a movement just about a specific ALM or automation toolset or about creating a new role or isolated team.

Read my Tweet

So in my opinion it’s impossible to hire a DevOps. Just like hiring SCRUM Masters won’t make your organizations Agile, hiring an automation or an “all-in-one” expert won’t do the DevOps magic.

According to Puppet Labs 2015 State of DevOps Report: “DevOps initiatives launched solely by C-level executives or from the grassroots are less likely to succeed.” That gives us another clue that for organizations to implement a good DevOps practice they must change their culture in order to ease the collaboration between teams that usually work in their own silos. A change that no one can achieve on their own.

Organizations should be looking for people with the right set of “soft” skills: communication, teamwork, collaboration, problem solving, critical observation, conflict resolution, which all are core to DevOps.

Organizations should check their hiring processes, ask themselves, according to their needs, what and why are they looking for, and may even get surprised to learn that the people they need are right there, under their own umbrella.

 

Carlos Mendible AUTHOR:
Carlos Mendible has been .Net Architect for Sogeti Spain since 2012. He is Head Solutions Architect in, one of our major clients, A3 Media, and is also responsible for assisting with the sales process as Pre-Sales Engineer and for conducting workshops and training sessions.

Posted in: architecture, Automation Testing, communication, DevOps, Digital, Infrastructure, Innovation, IT strategy, Research, Scrum, Software Development, Transformation      
Comments: 0
Tags: , , , , ,

 

Image 1You just inherited someone else’s code and you feel like the task is going to be impossible. You are overwhelmed by the lack of documentation, you also find out that there are no tests in place and you wonder how on earth you will make the requested changes without breaking things. Yes you are scared!

I’ll try to help you with these 4 guidelines:

You will come out stronger from this experience.

As humans, we find ourselves in this never-ending learning journey… take a moment for yourself, calm down and be sure that you’ll get something in return after you conquer the inherited code or application.

Perhaps, you don’t know anything about the business the application is intended for. Grasp anything you can and expand your knowledge base. You never know when those key things you learnt will come up handy in another situation, project or even landing your dream job.

Maybe it’s your lucky day and the code, you just inherited, was written by a more experienced developer, and therefore you’ll learn new ways of doing things … yes, I know … sometimes it can be difficult, frustrating, and confusing, but believe me, once you finish the job you’ll have more things in your toolbox so when the next project knocks on your door, you’ll have different ways to approach it.

In the worst case scenario, you’ll find yourself trapped in the middle of some serious spaghetti code … in such a case you’ll learn that you have a responsibility to those who follow, because you don’t want anybody complaining about your code, or do you?

Understand The Big Picture.

You’ve just become responsible for a code base, you know nothing about. So where do you start? Let’s remember that Agile, SCRUM, PMP ITIL, etc… all begin with some sort of planning or assessment as described in the Deming PDCA cycle.

You need a plan, you need to know where you and the current code are standing. Don’t jump into those first keystrokes before making your point that is important to step back for a moment to get a glimpse of the project, an overview of what the software is supposed to do. Ask for any available documentation, functional requirements, user stories, anything that stakeholders may have that will help you plan where and how to start.

Don’t act like a robot, ask what the expectations are and document your findings. Once you have a good understanding of the big picture, you are a step closer to working your way through the code.

Don’t start over.

I know that feeling. You look at the screen, you curse in any language you know and the first thing that comes to your mind is: I’ll start from scratch.

For instance, in this stage you probably can’t know all about the business rules or knowledge embedded in the code base and therefore you cannot be sure your “new” software will work or perform better than the first.

Unless you are making a major architecture or technological change, work with the legacy code, as long as you can. Fix whatever you find is not working as expected, and just start to think about rewriting when you have tests in place to assure that you’ll not break existing functionality.

Debug it and Test it!

Master the art of debugging. Go step by step through that code you don’t understand. Use breakpoints, watch variables and learn what the code is intended for. Once you get the picture, of what the code is doing and what it is supposed to do, you are clear to start with your changes.

“… Even if your code was written yesterday, if there are no unit tests to characterize or define the behavior of the code, then the code is legacy, and will be difficult to change without introducing bugs…”

Do create tests for your code. Sometimes you’ll find it difficult because of many types of constraints (i.e. time, budget) but make your case, remember you don’t want anybody reading this article because they just inherited your code!

Hope it helps!

 

Carlos Mendible AUTHOR:
Carlos Mendible has been .Net Architect for Sogeti Spain since 2012. He is Head Solutions Architect in, one of our major clients, A3 Media, and is also responsible for assisting with the sales process as Pre-Sales Engineer and for conducting workshops and training sessions.

Posted in: Agile, Application Lifecycle Management, Business Intelligence, functional testing, Innovation, Quality Assurance, Robotics, Scrum, Software Development, Software testing, Test environment      
Comments: 0
Tags: , , , , , , , , , , ,

 

Kilroy Was Here-StyxMaybe I was 12 when I listened to ‘Mr Roboto’ by Styx for the last time. The song was recorded for the album ‘Kilroy Was Here’ in 1982. That was 11 years before the first release of the Mosaic web browser, 17 before the term ‘Internet of Things’ was coined and approximately 30 years before the rise of IoT.

“… My heart is human, my blood is boiling, my brain I.B.M…” — Styx

It’s fascinating how the song talks about some kind of cyborg and also gives a glimpse of the possible impact of social media technologies and the very existence of IoT, not to mention the ‘time machine effect’ that the song still has over my mind.

“The problem’s plain to see, too much technology Machines to save our lives…” — Styx

The world in the 1980’s, as Styx knew it, was transformed into this hyperconnected place we live in today, where computers are omnipresent.

Nowadays, we are doing anything and everything to enhance or merge ourselves with technology. We’ve learned about Google Glass, Microsoft HoloLens and more recently about a hacker who implanted an NFC chip in his hand to bypass security scans and exploit android phones. We also know about how Amazon is trying to fill our skies with drones to deliver products to customers; Doctors implanting pacemakers with WiFi capabilities, so they can monitor their patients; and toothbrushes, light bulbs and coffee machines being web-enabled to send information to Cloud, Big Data and Machine Learning enabled services. Furthermore, the way we interact with the Internet of Things or should I say Internet of Addictions, makes us all behave like tech junkies.

“…So if you see me acting strangely, don’t be surprised…” — Styx

It’s clear that the disruption created by Social, Mobile, Analytics, Cloud and Things (SMACT) is reshaping / transforming our world really fast. So fast that the thought of the hypothetical advent of artificial general intelligence, as stated by the Technological Singularity theory, is no longer considered a taboo.

The question, here, is not whether the Singularity will happen, but WHEN will it happen?

“Domo arigato, Mr. Roboto…” — Styx

Watch the original video for the song

To read the original post and add comments, please visit the SogetiLabs blog: When will Singularity happen?

Related Posts:

  1. Ray Kurzweil and the Singularity in 3 minutes
  2. Expert Talk: Ted Dunning on singularity, privacy and consumers in a Big Data world (part 2)
  3. Big Data, changing business models and singularity
  4. Starbucks puts Bucks in connecting machines

 

 

Carlos Mendible AUTHOR:
Carlos Mendible has been .Net Architect for Sogeti Spain since 2012. He is Head Solutions Architect in, one of our major clients, A3 Media, and is also responsible for assisting with the sales process as Pre-Sales Engineer and for conducting workshops and training sessions.

Posted in: Big data, Cloud, Social media, Social media analytics, Technology Outlook, Transformation      
Comments: 0
Tags: , , , , , , , , , , , , ,

 

Vulcan saluteAny application that is critical to running the mainstream operation of a business can be considered a mission critical application. These applications should be sustainable, maintainable, flexible and adaptable to keep up with the pace of today’s evolving nature of business. “Change is the essential process of all existence.” — As aptly stated by Mr. Spock in Star Trek: The Original Series.

As architects or developers involved in these types of software projects, it’s important to realise that software design and development often ends up following one of these two extremes: over-engineering or under-engineering.

Over the years, I’ve designed, developed and reviewed many software projects and have always found areas or specific pieces where the software was either too complex or such, where simplicity, bad habits, business rush or developer turnover had led to a messy situation.

If you can’t explain your code to someone else in a minute or two, then you have made the code too complex.

So, how can we avoid such problems? Here are four principles that can help address these issues:

KISS

The Keep It Simple Stupid (KISS) principle states that most systems work best if they are kept simple.

Unnecessary complexity should be avoided.

You should try to solve the problem in the simplest way you can. Ask yourself or your team: Do we really need to build the USS Enterprise or can a helicopter do the job?

DRY

Don’t Repeat Yourself (DRY) is a software development principle, aimed at reducing repetition of information of all kinds.

Many of the projects I review, have repeated codes throughout the program. When a bug fix, update or new feature is needed, developers are forced to search the entire code base to find any occurrence and make the required changes.

Therefore, a software, designed without the principle of DRY in mind, is harder to maintain and less flexible; which in turn increases the time to market.

YAGNI

You Aren’t Going To Need It (YAGNI) is a principle of extreme programming (XP), which states that a programmer should not add functionality until deemed necessary.

Write the minimum code necessary to solve the problem.

Start out by developing software that does just what is needed and nothing more; but make sure that the code is extensible, so that adding onto it does not become a problem.

SOLID

SOLID is a mnemonic acronym for the following five basic principles of object-oriented programming and design: Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion.

A software designed and developed with these five principles, applied together, should be easier to maintain and sustain over time.

Depend upon Abstractions. Do not depend upon concretions.

To wrap up, keep your code DRY, design and develop only what is needed (YAGNI), embrace a KISS state of mind, work with rock SOLID principles and your mission-critical business applications will Live Long and Prosper.

“Live Long and Prosper.” — Spock, Star Trek: The Original Series

To read the original post and add comments, please visit the SogetiLabs blog: Live Long and Prosper: Apply Four Simple Programming Principles

Related Posts:

  1. Top 10 post: “Code generation… Can it be simple and pragmatic?”
  2. Code generation… Can it be simple and pragmatic?
  3. The service is dead, long live the service!
  4. To Live Long and Prosper

Carlos Mendible AUTHOR:
Carlos Mendible has been .Net Architect for Sogeti Spain since 2012. He is Head Solutions Architect in, one of our major clients, A3 Media, and is also responsible for assisting with the sales process as Pre-Sales Engineer and for conducting workshops and training sessions.

Posted in: Application Lifecycle Management, architecture, Behaviour Driven Development, Developers, IT strategy, Opinion, Test Driven Development      
Comments: 0
Tags: , , , , , , ,