It's the end of a long weekend, and alas I was not running the marathon or partying like a rockstar. I was either building flat pack furniture for our forthcoming baby or working on my project for this class. The simple fact is that with a baby due in a few weeks, it pays to be ahead of the game. That I am. But this bit is always easy, throw loads of words at the page in some kind of roughly aligned organizational structure. But then I must spend the same about of time implementing grammar, referencing, getting below the word count. Oh what it must be if one was a professional writer, and you could "throw it over the wall" to an editor, or indeed a team of editors in my case :D [as developers are so keen on doing, throwing their dodgy code over to QA teams!]
The Microsoft case study for this week is interesting. But its nothing new to me, really. We look at three teams at Microsoft, they adopt a new practice and are diligent about it. They are monitored pretty closely. I think any team of skilled people, [..with the eye of Sauron on them] will do well working with practices which break out their work and have clear tasks like this.
On this week's readings, Kent Beck is this week's interesting fellow. He was one of the brains behind the agile manifesto [so I have read in a few places, but I hazard a guess that more than person has that said about them], and was one of the initial folks who put their name to it. Now we move onto one of his earlier papers dealing with Extreme Programming. In my working life XP is a bit of a joke, a term of derision. But what he is clearly doing is pulling good ideas from here and there, and making a new thing. Not unlike Henry Ford coping meat packing practices when he wanted a way to make more cars, and make them cheaper.
But if you read what he is actually saying it's the direction a lot of software companies have gone. They work on loads and loads of small iterations. They want to get the software to their production servers as often as possible, many times a day if you are doing it right. You design, code, build, test and then deploy many tiny things, rather than big huge monolithic things [as Waterfall tended to do]. That way, if your Microsoft working on Office 365. You have a story to take advantage of 3D printing or something like that. You design that one thing in isolation. You get the team to code it. Then you release said enhanced printing function without having to patch a billion copies of office, or doing another release or something. You make your enhancements, release when it's ready, patch your host servers and you are done. Customers have enhancement. Back 5 or 10 years ago, that would be a feature lost in a big bang version of office which hit your desks every 3 or 4 years.
Monday, 26 October 2015
Monday, 19 October 2015
A Perfect World
I really enjoyed the Fishman paper, “They Write the right stuff” as it was an interesting view on ‘how the other half live’. You can see that if we had a tour of the NASA software development center that they do indeed work to the highest possible standards, and may indeed work to the strictest possible letter of the law of some set of standards like the CMMI guidelines which Royce describes in one of this week’s other papers.
A number of years ago I was building a testing team for a company who had previously not really cared about software testing. That company had previously believed that agile development meant that they did not have to test their code. They thought that they could push rapid fixes to their live environment, and this negated the need for any formal testing structure. [Note: This may seem almost funny now, but a lot of people and companies really thought at that time]. In building that team I interviewed a gentleman who worked for a company who wrote the software which tested artificial hearts and lungs. Imagine, my companies bug will cause us to need to push out an emergency fix out of office hours. His companies bug will potentially kill people! It’s a different mindset.
I think when we look at Fishman’s Nasa example anyone in “commercial” software development. The software at Nasa cannot have any errors, plain and simple. They have spent the time planning, and clearly have the people time and processes in place to ensure that it is perfect. As the article mentions “It is an exercise in order, detail and methodical reiteration”. I have spent my career in development teams at rapidly growing commercial software companies. Our focus is on getting “this” feature out, at the best quality possible in the time available, and to move onto the “next” shiny object feature. Our resources and timelines are driven by commercial reasons. The resources and timelines at Nasa are clearly driven by the need to get it right.
If you go to the next level of information in the article. One line jumped out at me, they speak about how they get to the near zero defect rates, “Packet data and view graphs on a line by line basis”. I read that and I genuinely wonder how ANY complex code can get passed that. But I have never worked in a zero defect environment, and clearly wont ever! In commercial software development, we fix any critical defects. We have logs, and basically ignore things below error level, any warnings or info notifications don’t even get logged in the defect system. Clearly at Nasa, they want the logs empty of anything. I cant emphases enough how huge of a mindset change this would be for most people.
Finally, there is one last thing to be pointed out. The article quotes someone at Nasa as saying, “Don’t fix mistakes, fix what permitted the mistake”. This is one of those things that everyone knows, but virtually no one follows through and puts into place. It's like when I lost a lot of weight a few years ago. People are disappointed when I tell them I exercised more, ate smaller portions and made my own food. Folks want a story about a magic pill. They simply don’t want to know solutions that a 5-year-old could tell you. In this scenario, you have a defect and any developer could tell you that you don’t just fix the issue, but you fix the root cause. But I have done proper root cause analysis a tiny number of times in a 15-year career around software development [Mostly around times around defects which resulted in LARGE financial loss for the company!]. We all know we should do it, but no one takes the time to do it properly.
A number of years ago I was building a testing team for a company who had previously not really cared about software testing. That company had previously believed that agile development meant that they did not have to test their code. They thought that they could push rapid fixes to their live environment, and this negated the need for any formal testing structure. [Note: This may seem almost funny now, but a lot of people and companies really thought at that time]. In building that team I interviewed a gentleman who worked for a company who wrote the software which tested artificial hearts and lungs. Imagine, my companies bug will cause us to need to push out an emergency fix out of office hours. His companies bug will potentially kill people! It’s a different mindset.
I think when we look at Fishman’s Nasa example anyone in “commercial” software development. The software at Nasa cannot have any errors, plain and simple. They have spent the time planning, and clearly have the people time and processes in place to ensure that it is perfect. As the article mentions “It is an exercise in order, detail and methodical reiteration”. I have spent my career in development teams at rapidly growing commercial software companies. Our focus is on getting “this” feature out, at the best quality possible in the time available, and to move onto the “next” shiny object feature. Our resources and timelines are driven by commercial reasons. The resources and timelines at Nasa are clearly driven by the need to get it right.
If you go to the next level of information in the article. One line jumped out at me, they speak about how they get to the near zero defect rates, “Packet data and view graphs on a line by line basis”. I read that and I genuinely wonder how ANY complex code can get passed that. But I have never worked in a zero defect environment, and clearly wont ever! In commercial software development, we fix any critical defects. We have logs, and basically ignore things below error level, any warnings or info notifications don’t even get logged in the defect system. Clearly at Nasa, they want the logs empty of anything. I cant emphases enough how huge of a mindset change this would be for most people.
Finally, there is one last thing to be pointed out. The article quotes someone at Nasa as saying, “Don’t fix mistakes, fix what permitted the mistake”. This is one of those things that everyone knows, but virtually no one follows through and puts into place. It's like when I lost a lot of weight a few years ago. People are disappointed when I tell them I exercised more, ate smaller portions and made my own food. Folks want a story about a magic pill. They simply don’t want to know solutions that a 5-year-old could tell you. In this scenario, you have a defect and any developer could tell you that you don’t just fix the issue, but you fix the root cause. But I have done proper root cause analysis a tiny number of times in a 15-year career around software development [Mostly around times around defects which resulted in LARGE financial loss for the company!]. We all know we should do it, but no one takes the time to do it properly.
Wednesday, 14 October 2015
Monday, 12 October 2015
People are strange...
As I am tending to do over the last few weeks, there is one part of the week 6 readings I want to place my focus.
Before we do that, as a second-year student, one of the clear advantages we have already encountered a lot of the seminal papers in the areas we are working. Last year I used to HATE when a second year said in class, "oh yea, we did that last year" and the lecturer would skip over it. So Im trying to avoid doing that. So many of the papers referenced in this week's readings have been covered in modules we have already completed, which makes it easier for us second years to grasp. We have already spent 6 weeks trying to get our heads wrapped around bloody structuration theory!!! So for that reason, I'm not going to talk about the classic Curtis, Krasner and Iscoe paper [one of my favourites from the course so far, for what it's worth]. My project shall indeed use it, as I do love their core point that we should not see requirements as things to be dragged from users heads. But that often requirements don't exist and have to be constructed from various human interactions.
In the Fiction of Methodological Development paper, Nandhakumar and Avison say,
Jim Morrison said it best, "people are strange.."! That is what is important to remember in all of this. You adapt process around all processes, but especially development to what team you have. One team will do Kanban, with many tiny tasks in an ever flowing board. With another team you have a small number of bigger tasks, reviewed monthly or something. It all comes back to the people! You want to look at the people on your team [& who your customers are, and who they have], and how you get the best from them. You adapt to your people and environment. I would not go full on Myers-Briggs with specific labels. But I cant argue with their general point, and how it drives who will work best with who [all things being equal].
In our Iona case study it seems to be clear [to me!] that as they became bigger and more successful, they lost some of that fun start-up culture. It was not fun anymore. But the other side of that start-up culture is that often bad processes often become embedded and at times you will get a hero mentality, of people and teams taking on huge burdens in an effort to be seen as "the best", and that also looks like it happened at Iona. That is where you need to step back at times and look at what you are doing, and why you are doing it. You need to examine who you have, if they are doing their best and if they are happy [and if not, how can you make things better for them and your customers. This is tied to the points above. Its about the social context of folks actions. At times its VERY important that a leader takes a step away. The leader needs to look at things being in place for the sole reason that person x did it this way once, and this becomes the process everyone else must follow. No knows why we do it, or why we expect that its slow or manual. But every time we do this slow manual process put into place by mister x it gets reinforced [in the Iona case, its the stupid long hours to support products!]
Before we do that, as a second-year student, one of the clear advantages we have already encountered a lot of the seminal papers in the areas we are working. Last year I used to HATE when a second year said in class, "oh yea, we did that last year" and the lecturer would skip over it. So Im trying to avoid doing that. So many of the papers referenced in this week's readings have been covered in modules we have already completed, which makes it easier for us second years to grasp. We have already spent 6 weeks trying to get our heads wrapped around bloody structuration theory!!! So for that reason, I'm not going to talk about the classic Curtis, Krasner and Iscoe paper [one of my favourites from the course so far, for what it's worth]. My project shall indeed use it, as I do love their core point that we should not see requirements as things to be dragged from users heads. But that often requirements don't exist and have to be constructed from various human interactions.
In the Fiction of Methodological Development paper, Nandhakumar and Avison say,
"There is one particular part of the "The development process therefore, far from being a life-cycle process, involves complex human actions and interactions. As Orlikowski and Robey (1991) claim, developers ``do not act in a vacuum'', but are influenced by various issues in the organizational context, such as their knowledge about methodologies and implicit social norms, the resources available to them and the organizational form and culture. Drawing on Giddens' (1984) structuration theory, we may see the development process in terms of cycles of interactions between developers' actions and social context in which the developers draw on their knowledge about organizational context and methodologies. Activities of the EIS team members, in turn, helped to reinforce this social context"I think this raises critical points which are easy to miss. We often obsess with methodologies and process or indeed with technology "we need to port this to the cloud, and all our problems will go away". As their study finds, is that it's all about people. A team of people who are people shy introverts will often be doing things very differently day to day than another team of extroverts shooting nerf guns at each other! These are extreme examples, but you find these kinds of teams in every large company. I once managed a team of developers in Kiev, and if micro-managed their work was excellent. But if left to their own devices, their work was sloppy and sub-standard. They needed to be told what to do at every level, and that was what they were used to. Contrast that with the team I worked with in Cape Town, South Africa. If I tried to micro-manage them I would have serious problems. They are much louder and stronger personalities. I gave them requirements and deadlines, and from then by and large got updates in morning stand-ups and at no other time.
Jim Morrison said it best, "people are strange.."! That is what is important to remember in all of this. You adapt process around all processes, but especially development to what team you have. One team will do Kanban, with many tiny tasks in an ever flowing board. With another team you have a small number of bigger tasks, reviewed monthly or something. It all comes back to the people! You want to look at the people on your team [& who your customers are, and who they have], and how you get the best from them. You adapt to your people and environment. I would not go full on Myers-Briggs with specific labels. But I cant argue with their general point, and how it drives who will work best with who [all things being equal].
In our Iona case study it seems to be clear [to me!] that as they became bigger and more successful, they lost some of that fun start-up culture. It was not fun anymore. But the other side of that start-up culture is that often bad processes often become embedded and at times you will get a hero mentality, of people and teams taking on huge burdens in an effort to be seen as "the best", and that also looks like it happened at Iona. That is where you need to step back at times and look at what you are doing, and why you are doing it. You need to examine who you have, if they are doing their best and if they are happy [and if not, how can you make things better for them and your customers. This is tied to the points above. Its about the social context of folks actions. At times its VERY important that a leader takes a step away. The leader needs to look at things being in place for the sole reason that person x did it this way once, and this becomes the process everyone else must follow. No knows why we do it, or why we expect that its slow or manual. But every time we do this slow manual process put into place by mister x it gets reinforced [in the Iona case, its the stupid long hours to support products!]
Monday, 5 October 2015
SDLC, Waterfall versus the rest of the world!
The readings we had this week were very interesting. They are all pretty old by computer standards, [which is depressing, in that one was published the year I left school]! You look at them all and the universal theme is that how teams were doing the software development lifecycle is bad. You scratch below the surface, and you see they are all operating in a world of waterfall. In that sole subject area they are correct. But I have a problem, read on to learn why.
I have worked in a waterfall world. Put simply we have a big bang release every year. I worked for a games company. The game went to customers for Christmas, and we cut our master in November. So we developed code all year, and in the month before we cut our release we all worked 20 hours a day and 7 days a week to get things done [not unlike our friends in the soul of a new machine book IMHO!]. When we had an issue we went back to the start, and it was an utter nightmare. I think back and I'm amazed how we got things done, and Im also amazed as how terrible our software really was at the time. But we got away with it, as people loved it, and also we had a dedicated team of work-a-holics who fixed issues quickly.
So in this waterfall world the Software Development Lifecycle [hereafter SDLC] is indeed pretty rubbish. As a simple example, you design something, you write many months code [maybe several thousand[s] of lines], and then in test you find an issue[s]. Of course this is stupid and terrible, as the bug could be anywhere and could take a long time to find and fix [think finding a needle in a stack of needles!]. This takes time, and is very costly in terms of human time, build and deploy time and time, this is time not spent adding other value to product, and basically costs money on any metric you care for.
This is why many companies have moved to an agile world [which we speak about later in the course]. It is why the software world is slowly moving to micro-services and continuous delivery. In this world, the SDLC is fantastic.
Let's take an imaginary payments service, from an online company. In a Waterfall world you will have a massive service doing all kinds of payments, incoming and outgoing . This old school payments service could be dependent on other services or indeed other services may be dependent on it. So you can break other stuff, and other stuff can break you. This service does many things, so most of it can work fine, and one small bit can cause havoc. You would likely build and release it to live every month, quarter, year or something like that. If it's broken you won't send or receive any payments. Your company is dead and losing many euro every minute, in terms of hard cash and customers going somewhere else.
In the modern world, you won't have a single payments service, you will have 20 [or so] 'micro services'. Using last week's reading, your development team will have spent time untangling the payments ball of wax. Each of these micro services can be built on their own. They should work on their own. So ifor another easy example, 'Payments.Outgoing.CreditCard.Visa' is broken and therefore, your automated outgoing payments to visa may not work, 'Payments.Incoming.CreditCard.Visa' should still work and is totally unaffected, you folks paying you with Visa works fine. Not to forget that 'payments.*.mastercard' was never affected.
In this world, the issue is very localised. You should know the exact problem and location quickly. Therefore you should be able to identify who is needed to examine, code and test a fix. You should not require 20 people in a room! It should not take months. Its quick and easy [..most of the time!] :)
So my personal issue with this week's readings is that, they are outdated. When the papers were written, the issues were very real, Now, these issues don't exist in the modern world as even companies I know of who release in a waterfall manner, develop behind the scenes in an agile world and want to break up and untangle their services. [But that being said, these papers are good for academic study such as ours, in class!].
Subscribe to:
Posts (Atom)