Allan Kelly

CORE

Consutlant, coach, guide in all things agile at Allan Kelly Associates

London, GB

Joined Jun 2010

https://www.allankelly.net

About

Allan started his career as a coder, one day he realised the code wasn't the challenge: it was the way companies were set up and run. So he began a new journey, to help the coder he was. Today he specialises in better ways of working through agile approaches and OKRs. He partners with growing technology focused businesses to enhance effectiveness and predictability through improved organization, product focus, and delivery. He has written several books including the best selling "Succeeding with OKRs in Agile" and "The Art of Agile Product Ownership". He most proud of the badly named "Business Patterns for Software Developers".

Stats

Reputation:	1665
Pageviews:	1.3M
Articles:	11
Comments:	36

Articles
Comments

Articles

5 Steps To Tame Unplanned Work

Stuff happens, even if it shouldn't. Just because it happens randomly does not mean your response should be. Five simple steps can bring a lot of order.

November 27, 2023

· 4,163 Views · 5 Likes

What Is the Right Size for a User Story?

What constitutes right is dependent on you, your team, and how you play the game.

August 2, 2019

· 74,737 Views · 6 Likes

Do We Really Need a Product Owner?

If you want to maximize value for your customers, yes.

July 2, 2019

· 11,698 Views · 4 Likes

Dealing With Unplanned but Urgent Work Through DevOps

What's the best way to handle the common problem of unexpected but urgent tasks?

Updated October 5, 2018

· 5,404 Views · 1 Like

The Product Owner Refactored: the SPO/TPO Model

Read about this model for the PO on the go who may not have time to singularly dedicate themselves to product ownership.

May 4, 2018

· 9,186 Views · 1 Like

What Product Owners Should Not Do

Now that we've told you what to do as a Product Owner, here are some behaviors that you'll want to avoid in the future.

April 19, 2018

· 18,088 Views · 8 Likes

Use the Staffing Pyramid to Structure Teams

Use a pyramid to determine how manager managers, programmers, testers, and requirements engineers should be structured on a team.

January 28, 2016

· 13,495 Views · 2 Likes

Self-organizing, Self-directing, Self-managing, and Authority

The differences between self-organizing, self-directed, and self-managed team in an agile environment.

September 24, 2015

· 7,126 Views · 1 Like

Agile is Punk - Agile is Democracy

From time to time I’ve been heard to say: “Agile is Punk.” But I’ve never explained myself. I’ve also been heard to say things life “Agile is about democratising the workplace” but I’ve never explain myself there either. Let me try… What I mean when I say this is: Agile (software development) has a lot in common with Punk rock. To me the important thing about punk rock was that it was about people trying it - music, their own thing. Anybody trying to play music, anybody forming a band, anyone who had a novel idea trying to get a record contract. Yes, even if they couldn’t play an instrument they could have a go, and who knows, maybe they would learn as they went. (I should say that while I’m old enough to have been around when punk was I’m not old enough to have been there. Both post-punk and post-disco influences were at work in the New Wave music which was common when I came music listening.) Punk had a democratising effect on music. Music has aways been of the people, anyone can listen, anyone can try to sing - although I’m not very good at it even I can try! But the music industry was something different, performing, recording - there were barriers there! Punk tore down barriers. Punk opened up the recording industry. Punk opened up music. Agile opened up the software process industry. Before Agile official software processes were pretty locked down. You had to be an academic or expert/consultant to dabble in that space. Programmers who worked in under official software processes were on the receiving end. Agile said: “Your opinion is important too.” In truth music has always was been open to everyone, just not the recording industry. And in software development processes were open to anyone, most programmers did not work under an official process, mostly it was common practices which, if they worked, were probably more effective than official ones. Unfortunately these unofficial work practices came with guilt: because we did not do it the way the books said we should. When faults occurred we blame ourselves for “not doing it properly”. Agile says: “Everyone involved with software development should have a voice in deciding how to work, it can be improved and you don’t need to be an expert, academic, consultant or certified member of some body to express that view.” That also makes it democratic. I don’t mean democratic in the sense that we all get to vote, I mean democratic in the sense that it is power is vested in the hands of the collective people. Everyone has a voice, everyone can participate, and those who hold executive power do so by the will of the people. Agile is about giving everyone a voice. Like Punk that means accept that those who don’t have much skill are also entitled to a voice. Funnily enough, I’ve long held that any punk band that made a second album weren’t punk anymore because they were part of the industry, they were now experts! The same is true with Agile, hang around for long enough (like me) and you are no longer an outside but an insider, an expert. Increasingly we see Agile heading outside of software development. When this happens it becomes necessary to ask: What is Agile? My answer is: Democracy. Agile is about valuing everyone, agile is about giving everyone a voice, agile is about putting the power to change the workplace (process, systems, norms) into the collective hands of the people who work there. Yes at times it feels revolutionary, but there are fellow travellers, it is all a Theory-Y movement.

June 28, 2015

· 4,897 Views · 2 Likes

Programmers Without TDD Will be Unemployable by 2022

New year is traditionally the time of predictions, and several of the blogs I read have been engaging in predictions (e.g. Ian Sommerville “Software Engineerng looking forward 20 years.”). This is not a tradition I usually engage in myself but for once I’d like to make one. (I’ll get back to software economics next time, I need to make some conclusions.) Actually, this is not a new prediction, it is a prediction I’ve been making verbally for a couple of years but I’ve never put it on the record so here goes: By 2022 it will be not be possible to get a professional programming job if you do not practice TDD routinely. I started making this prediction a couple of years ago when I said: “In ten years time”, sometimes when I’ve repeated the prediction I’ve stuck to 10-years, other times I’ve compensated and said 9-years or 8-years. I might be out slightly - if anything I think it will happen sooner rather than later, 2022 might be conservative. By TDD I mean Test Driven Development - also called Test First (or Design Driven) Development. This might be Classic/Chicago-TDD, London-School-TDD or Dan North style Behaviour Driven Development. Broadly speaking the same skills and similar tools are involved although there are significant differences, i.e. if you don’t have the ability to do TDD you can’t do BDD, but there is more to BDD than to TDD. The characteristics I am concerned with are: Developer written automated unit test, e.g. if you write Java code you write unit tests in Java... or Ruby, or some other computer language The automated unit tests are executed routinely, at least every day This probably means refactoring, although as I’ve heard Jason Gorman point out: interest in refactoring training is far less than that in TDD training. I’d like to think that TDD as standard - especially London School - also implies more delayed design decisions but I’m not sure this will follow through. In part that is because there is a cadre of “designers” (senior developers, older developers, often with the title “architect”) who are happy to talk, and possibly do, “design” but would not denigrate themselves to write code. Until we fix our career model big up front design is here to stay. (Another blog entry I must write one day...) I’m not making any predictions about the quality of the TDD undertaken. Like programming in general I expect the best will be truly excellent, while the bulk will be at best medicare. What I am claiming is: It will not be acceptable to question TDD in an interview. It will be so accepted that anyone doesn’t know what TDD is, who can’t use TDD in an exercise or who claims “I don’t do TDD because its a waste of time” or “TDD is unproven” will not get the job. (I already know companies where this is the case, I expect it to be universal by 2022.) Programmers will once again be expected to write unit tests for their work. (Before the home computer revolution I believe most professional programmers actually did this. My generation didn’t.) Unit testing will be overwhelmingly automated. Manual testing is a sin. Manual unit testing doubly so. And I believe, in general, software will be better (fewer bugs, more maintainable) as a result of these changes, and as a result programmer productivity will be generally higher (even if they write less code they will have fewer bugs to fix.) Why do I feel confident in making this prediction? Exactly because of those last points: with any form of TDD in place the number of code bugs is reduced, maintainability is enhanced and productivity is increased. These are benefits both programmers and businesses want. The timescale I suggest is purely intuition, this might happen before 2022 or it might happen after. I’m one of the worst people to ask because of my work I overwhelmingly see companies that don’t do this but would benefit from doing it - and if they listen to the advice they are paying me for they start doing it. However I believe we are rapidly approaching “the tipping point”. Once TDD as standard reaches a certain critical mass it will become the norm, even those companies that don’t actively choose to do it will find that their programmers start doing it as simple professionalism. A more interesting question to ask is: What does this mean? What are the implications? Right now I think the industry is undergoing a major skills overhaul as all the programmers out there who don’t know how to do TDD learn how to do it. As TDD is a testable skill it is very easy to tell who has done it/can do it, and who just decided to “sex up” their CV/Resume. (This is unlike Agile in general where it is very difficult to tell who actually understand it and who has just read a book or two.) In the next few years I think there will be plenty of work for those offering TDD training and coaching - I regularly get enquiries about C++ TDD, less so about other languages but TDD and TDD training is more widespread there. The work won’t dry up but it will change from being “Introduction to TDD” to “Improving TDD” and “Advanced TDD” style courses. A bigger hit is going to be on Universities and other Colleges which claim to teach programming. Almost all the recent graduates I meet have not been taught TDD at all. If TDD has even been mentioned then they are ahead of the game. I do meet a few who have been taught to programme this way but they are few and far between. Simply: if Colleges don’t teach TDD as part of programming courses their graduates aren’t going to employable, that will make the colleges less attractive to good students. Unfortunately I also predict that it won’t be until colleges see their students can’t get jobs that colleges sit up and take notice. If you are a potential student looking to study Computer Science/Software Engineering at College I recommend you ignore any college that does not teach programming with TDD. If you are a college looking to produce employable programmers from your IT course I recommend you embrace TDD as fast as possible - it will give you an advantage in recruiting students now, and give your students an advantage finding work. (If you are a University or College that claims to run an “Agile” module then make sure teach TDD - yes, I’m thinking of one in particular, its kind of embarrassing, Ric.) And if you are a University which still believes that your Computer Science students don’t really need to programme - because they are scientists, logisticians, mathematicians and shouldn’t be programming at all then make sure you write this in big red letters on your prospectus. In business simply doing TDD, especially done well, will over time fix a lot of the day-to-day issues software companies and corporate IT have, the supply side will be improved. However unless companies address the supply side they won’t actually see much of this benefit, if anything things will get worse (read my software demand curve analysis or wait for the next posts on software economics.) Finally, debuggers are going to be less important, good use of TDD removes most of the need for a debugger (thats where the time comes from), which means IDEs will be less important, which means the developers tool market is going to change.

January 9, 2014

· 122,155 Views · 2 Likes

3 Styles of Agile: Iterative, Incremental, and Evolutionary

When I’m teaching training courses (as I was this week at Skills Matter) or advising clients on the requirements-side of software development (which I’m doing a lot of just now), I talk about a model I call the “3 Styles of Agile.” Incredibly, I’ve never blogged about this -- although the model is hidden inside a couple of articles over the years. So now the day has come… I don’t claim the “3 Styles Model” is the way it should be, I only claim that it is the way I find the world. While “doing Agile” on the code side of software development always comes back to the same things (stand-up meetings, test/behavior driven development, code review/pair programming, stories, boards, etc.) the requirements side is very very variable. The advice that is given is very variable and the degree to which that advice is compatible with corporate structures and working is very variable. However, I find three reoccurring styles in which the requirements side operates and interfaces to development. I call these styles: Iterative, Incremental and Evolutionary, and I usually draw this diagram: I say style because I’m looking for a neutral word. I think you can use Scrum, XP and Kanban (or any other method) in any of the three styles. That said, I believe Kanban is a better fit for evolutionary while Scrum/XP are a better fit for Iterative and Incremental. I try not to be judgmental, I know a lot of Agile folk will see Evolutionary as superior, they may even consider Evolutionary to be the only True Agile but actually I don’t think that is always the case. There are times when the other styles are “right.” Let me describe the three styles: Iterative In this style the development team is doing lots of good stuff like: stand up meetings, planning meetings, short iterations or Kanban flow, test driven development, code review, refactoring, continuous integration and so on. I say they are doing it but it might be better to say “I hope they are doing” because quite often some bit or other is missing. That’s not important for this model. The key thing is the dev team are doing it! In this model, requirements arrive in a requirements document en mass. In fact, the rest of the organization carries on as if nothing has changed, indeed this may be what the organization wants. In this model you hear people say things like “Agile is a delivery mechanism” and “Agile is for developers." The requirement document may even have been written by a consultant or analyst who is now gone. The document is “thrown over the fence” to another analyst or project manager who is expected to deliver everything (scope, features) within some fixed time frame for some budget. Delivery is most likely one “big bang” at the end of the project (when the team may be dissolved). In order to do this they use a bacon slicer. I’ve written about this before and called it Salami Agile. The requirements document exists and the job of the “Product Owner” is to slice off small pieces for the team to do every iteration. The development team is insulated from the rest of the organization. There is probably still a change review board and any increase scope is seen as a problem. I call this iterative because the team is iterating but that’s about it. This is the natural style of large corporations, companies with annual budgets, senior managers who don’t understand IT and in particular banks. Incremental This style is mostly the same as Iterative, it looks similar to start with. The team are still (hopefully) doing good stuff and iterating. There is still a big requirements document, the organization still expects it all delivered and it is still being salami sliced. However, in this model, the team is delivering the software to customers. At the very least, they are demonstrating the software and listening to feedback. More likely, they are deploying the software and (potential) users can start using it today. As a result, the customer/users give feedback about what they want in the software. Sometimes this is an extra feature and functionality (scope creep!) and sometimes it is about removing things that were requested (scope retreat!). The “project” is still done in the traditional sense that everything in the document is “done,” but now some things are crossed out rather than ticked. Plus some additional stuff might be done over and above the requirements document. I call this incremental because the customers/users/stakeholders are seeing the thing grow in increments -- and hopefully early value is being delivered. I actually believe this is the most common style of software development -- whether that work is called Agile, waterfall or anything else. However, in some environments this is seen as wrong, wrong because the upfront requirements are “wrong” or because multiple deliveries need to be made, or because the team aren’t delivering everything they were originally asked to deliver. Evolutionary Here again the development team are iterating much as before. However, this time there is no requirements document. Work has begun with just an idea. Ideally I would want to see a goal, an objective, an aim, which will guide work and help inform what should be done -- and this goal should be stated in a single sentence, a paragraph at most. But sometimes even this is missing, for better or worse. In this model the requirements guy and developers both start at the beginning. They brainstorm some ideas and select something to do. While Mr. Requirements runs off to talk to customers and stakeholders about what the problem is and what is needed, the tech team (maybe just one person) gets started on the best idea so far. Sometime soon (2 weeks tops) they get back together. Mr. Requirements talks about what he has found and the developers demonstrate what they have built. They talk some more and decide what to do next. With that done, the developers gets on with building and Mr. Requirements gets on his bike again, he shows what has been built and talks to people -- some people again and some new people. As soon as possible the team starts to push software out to users and customers to use. This delivers value and provides feedback. And so it goes. It finishes, if it finishes, when the goal is met to the organization decided to use its resources somewhere else. Evolutionary style is most at home in Palo Alto, Mountain View, and anywhere else that start-ups are the norm. Evolutionary is actually a lot more common than is recognized but it is called maintenance or “bug fixing” and seen as something that shouldn’t exist. Having set out the three styles I’ll leave discussion of how to use the model and why you might use each style to another entry. If you want to know more about each model and how I see Agile as spectrum have a look my 2011 “The Agile Spectrum” from ACCU Overload or the recently revised (expanded but unfinished) version by the same title: “Agile Spectrum” (the 2013 version I suppose, online only).

October 1, 2013

· 23,838 Views · 0 Likes

Comments

3 talks you should watch

Feb 21, 2014 · Tony Thomas

Thanks Jeff, that story is most illuminating.

One thing that intrigues me is: what was the bug count like?

Both overall and from the different developers, did the one who practices TDD religiously have a significantly different number is issues to those who didn't?

You said the TDD'ed code was slower to write, I would argue that while code may well be slower to write initially it will be faster to complete, i.e. clear testing and need less rework, and this will save time and money when it is deployed. Again it would be good to know more about this case.

What I take from the story is this: even those who practices it less often knew how to do it, they made a (hopefully) informed choice of when to do it and when not.

To me, this is what we want: there may well be occasions when it makes sense to not do things test first but that decision can only be informed when those doing the work understand the options and are capable of proceeding by either route.

My objection is when developers say: "This code can't/shouldn't be done test first" without really understanding what is involved.

3 talks you should watch

Feb 21, 2014 · Tony Thomas

Thanks Jeff, that story is most illuminating.

One thing that intrigues me is: what was the bug count like?

Both overall and from the different developers, did the one who practices TDD religiously have a significantly different number is issues to those who didn't?

What I take from the story is this: even those who practices it less often knew how to do it, they made a (hopefully) informed choice of when to do it and when not.

My objection is when developers say: "This code can't/shouldn't be done test first" without really understanding what is involved.

3 talks you should watch

Feb 21, 2014 · Tony Thomas

Thanks Jeff, that story is most illuminating.

One thing that intrigues me is: what was the bug count like?

Both overall and from the different developers, did the one who practices TDD religiously have a significantly different number is issues to those who didn't?

What I take from the story is this: even those who practices it less often knew how to do it, they made a (hopefully) informed choice of when to do it and when not.

My objection is when developers say: "This code can't/shouldn't be done test first" without really understanding what is involved.

3 talks you should watch

Feb 21, 2014 · Tony Thomas

Thanks Jeff, that story is most illuminating.

One thing that intrigues me is: what was the bug count like?

Both overall and from the different developers, did the one who practices TDD religiously have a significantly different number is issues to those who didn't?

What I take from the story is this: even those who practices it less often knew how to do it, they made a (hopefully) informed choice of when to do it and when not.

My objection is when developers say: "This code can't/shouldn't be done test first" without really understanding what is involved.

Programmers Without TDD Will be Unemployable by 2022

Feb 21, 2014 · Allen Coin

Thanks Jeff, that story is most illuminating.

One thing that intrigues me is: what was the bug count like?

Both overall and from the different developers, did the one who practices TDD religiously have a significantly different number is issues to those who didn't?

What I take from the story is this: even those who practices it less often knew how to do it, they made a (hopefully) informed choice of when to do it and when not.

My objection is when developers say: "This code can't/shouldn't be done test first" without really understanding what is involved.

Programmers Without TDD Will be Unemployable by 2022

Feb 21, 2014 · Allen Coin

Thanks Jeff, that story is most illuminating.

One thing that intrigues me is: what was the bug count like?

Both overall and from the different developers, did the one who practices TDD religiously have a significantly different number is issues to those who didn't?

What I take from the story is this: even those who practices it less often knew how to do it, they made a (hopefully) informed choice of when to do it and when not.

My objection is when developers say: "This code can't/shouldn't be done test first" without really understanding what is involved.

Programmers Without TDD Will be Unemployable by 2022

Feb 21, 2014 · Allen Coin

Thanks Jeff, that story is most illuminating.

One thing that intrigues me is: what was the bug count like?

Both overall and from the different developers, did the one who practices TDD religiously have a significantly different number is issues to those who didn't?

What I take from the story is this: even those who practices it less often knew how to do it, they made a (hopefully) informed choice of when to do it and when not.

My objection is when developers say: "This code can't/shouldn't be done test first" without really understanding what is involved.

Programmers Without TDD Will be Unemployable by 2022

Feb 21, 2014 · Allen Coin

Thanks Jeff, that story is most illuminating.

One thing that intrigues me is: what was the bug count like?

Both overall and from the different developers, did the one who practices TDD religiously have a significantly different number is issues to those who didn't?

What I take from the story is this: even those who practices it less often knew how to do it, they made a (hopefully) informed choice of when to do it and when not.

My objection is when developers say: "This code can't/shouldn't be done test first" without really understanding what is involved.

3 talks you should watch

Jan 30, 2014 · Tony Thomas

Good points. (A reply to Dave Beck).

You bring us back to the "people or the system" argument. I have heard many people say "its the people" and I agree with them, and I've read Deming and he say "its 98% the system" and I agree with him. I think the whole industry is stuck in this double-think.

Let me suggest that the best programmers gravitate towards TDD, OK, its my opinion, but all the programmers I respect practice it. It may be that doing TDD is a filter. Or it may be that the best people conclude that it is effective.

Unraveling cause and effect here is beyond me.

Programmers Without TDD Will be Unemployable by 2022

Jan 30, 2014 · Allen Coin

Good points. (A reply to Dave Beck).

Unraveling cause and effect here is beyond me.

3 talks you should watch

Jan 19, 2014 · Tony Thomas

Thanks Darryl,

I couldn't have said it better myself!

I think you've put your finger on something here, something I'll have to follow up in a later blog. In my experience, when presented with a coherent argument most managers get it. As I said, this deserves more discussion, another blog

allan

3 talks you should watch

Jan 19, 2014 · Tony Thomas

Thanks Darryl,

I couldn't have said it better myself!

allan

Programmers Without TDD Will be Unemployable by 2022

Jan 19, 2014 · Allen Coin

Thanks Darryl,

I couldn't have said it better myself!

allan

Programmers Without TDD Will be Unemployable by 2022

Jan 19, 2014 · Allen Coin

Thanks Darryl,

I couldn't have said it better myself!

allan

3 talks you should watch

Jan 15, 2014 · Tony Thomas

Burabari, doing TDD is improving your coders.

TDD - and no other method I know of - guarantee's software will be bug free but all the evidence I have tells me it reduces - sometimes vastly reduces - the number of bugs that are there.

If not TDD then what?

Manual Unit tests?

If not manual unit tests then what?

Static analysis tools, code reviews and similar are good but you can use all these techniques, they are not exclusive.

3 talks you should watch

Jan 15, 2014 · Tony Thomas

Burabari, doing TDD is improving your coders.

TDD - and no other method I know of - guarantee's software will be bug free but all the evidence I have tells me it reduces - sometimes vastly reduces - the number of bugs that are there.

If not TDD then what?

Manual Unit tests?

If not manual unit tests then what?

Static analysis tools, code reviews and similar are good but you can use all these techniques, they are not exclusive.

Programmers Without TDD Will be Unemployable by 2022

Jan 15, 2014 · Allen Coin

Burabari, doing TDD is improving your coders.

TDD - and no other method I know of - guarantee's software will be bug free but all the evidence I have tells me it reduces - sometimes vastly reduces - the number of bugs that are there.

If not TDD then what?

Manual Unit tests?

If not manual unit tests then what?

Static analysis tools, code reviews and similar are good but you can use all these techniques, they are not exclusive.

Programmers Without TDD Will be Unemployable by 2022

Jan 15, 2014 · Allen Coin

Burabari, doing TDD is improving your coders.

TDD - and no other method I know of - guarantee's software will be bug free but all the evidence I have tells me it reduces - sometimes vastly reduces - the number of bugs that are there.

If not TDD then what?

Manual Unit tests?

If not manual unit tests then what?

Static analysis tools, code reviews and similar are good but you can use all these techniques, they are not exclusive.

3 talks you should watch

Jan 15, 2014 · Tony Thomas

Steven,

Thanks for your comment. What you describe is exactly what I believe. Its good to have someone else describe it from direct experience.

I probably over did it in my comments on manual testing, I believe there will always be an element of manual testing - exactly as you say after the automated tests. But I so rarely see true exploratory testing, usually it is manual testing in the absence of any automation.

allan

3 talks you should watch

Jan 15, 2014 · Tony Thomas

Steven,

Thanks for your comment. What you describe is exactly what I believe. Its good to have someone else describe it from direct experience.

allan

Programmers Without TDD Will be Unemployable by 2022

Jan 15, 2014 · Allen Coin

Steven,

Thanks for your comment. What you describe is exactly what I believe. Its good to have someone else describe it from direct experience.

allan

Programmers Without TDD Will be Unemployable by 2022

Jan 15, 2014 · Allen Coin

Steven,

Thanks for your comment. What you describe is exactly what I believe. Its good to have someone else describe it from direct experience.

allan

3 talks you should watch

Jan 14, 2014 · Tony Thomas

Programmers Without TDD Will be Unemployable by 2022

Jan 14, 2014 · Allen Coin

3 talks you should watch

Jan 10, 2014 · Tony Thomas

Thanks for that Jarek,

Interesting to note that in the Twitter stream about this article (no hashtag, you'll have to look at @allankellynet and the interactions) many area expressing pessimism that this will come to pass by 2022. But from what you, and a few other people say, this is already the norm in many many places.

Programmers Without TDD Will be Unemployable by 2022

Jan 10, 2014 · Allen Coin

Thanks for that Jarek,

3 talks you should watch

Jan 09, 2014 · Tony Thomas

Thanks for pointing that out Barry, it a while since I (re)read MMM.

A reasonable observation - one I hope is wrong.

In 1974 processor cycles were expensive and few people had easy access to machines. Brooks could see the benefits but the argument didn't catch. Hopefully now CPU cycles are dirt cheap and we all have as much power in our pocket as he had in a room automated testing has more chance.

I sometimes wonder if the while "agile" movement is about correcting a wrong turning the industry took somewhere about 1980.

Programmers Without TDD Will be Unemployable by 2022

Jan 09, 2014 · Allen Coin

Thanks for pointing that out Barry, it a while since I (re)read MMM.

A reasonable observation - one I hope is wrong.

I sometimes wonder if the while "agile" movement is about correcting a wrong turning the industry took somewhere about 1980.

Web Design Trends: Call To Action Buttons

Jun 09, 2013 · Tony Thomas

Wow, sounds like Lego have something of the Disney about them!

8 Reasons You Should Be Using Terracotta, not Oracle Coherence

Apr 03, 2013 · Taylor Gautier

Exactly! Great example

And god help us, literally, if anyone decides to refactor or rewrite DNA without a damn good set is tests!

Sun freshens Solaris 10 for new iron

Feb 21, 2013 · Tony Thomas

Florin,

Thanks for the comments, I think there is much to what you say. Particularly about complexity, I don't know who made the comments originally but they are repeated and re-invented in many forms. The enemy is complexity.

Big Ball of Mud is a very deep pattern, and its even debatable how far you can prevent it, or even if you want to. My (<a href="http://www.allankelly.net/patterns/encapsulatedcontext.html">Encapsulated Context pattern http://www.allankelly.net/patterns/encapsulatedcontext.html</a>) had something to say about that. (Continue the argument far enough and it becomes Dick Gabriel's "Worse if Better" discussion.)

Back to SOA. I think most of what you say applies to large system and modularization/decoupling in general. SOA is just the latest, and perhaps largest, tool to be through at this issue.

While I am sure that for you, and many other programmers, SOA - and web APIs in general - are really about decoupling I don't think that is how the debate plays out at the highest level. I don't think CIO and CFOs sign-off on multi-million dollar efforts to decouple their systems. I think they do sign-off on multi-million dollar efforts to reuse services and expose mainframe to the web.

And that is exactly where I see the problem. First you have mixed understanding of what SOA is for (programmers see it as decoupling, those paying the bills see something else.) Second I don't think spending millions and millions of dollars on will pay back, specifically in re-use terms.

As per the other comments: I stand my ground when we are talking about bolting on SOA, retro-fitting it to an existing system.

When its a case of building a system from the ground up with exposed APIs, whether we call it SOA, web services, or whatever, the case is more complex and may make commercial sense.

Sun freshens Solaris 10 for new iron

Feb 20, 2013 · Tony Thomas

I've also been told about an example at Amazon

http://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/

Although I immediately have reservations about any strategy that puts a gun to people's head: do it or be fired.

I think your onto something about the not bolting it on afterwards, build it with hooks, services, APIs, call it what you will.

Second, a common theme, maybe, from Netflix and Amazon may be that it was wide: many teams, if not all, did this. The SOA I've seen is a team sat in the corner and tasked with coming up with services for others.

Sun freshens Solaris 10 for new iron

Feb 19, 2013 · Tony Thomas

Jurgen,

Your reply doesn't seem to address any of the points raised in my piece. Rather it reads like a regurgitation of the usual arguments for SOA.

You mention BPM but I prefer the original name: BPR, lets be honest, Business Process Reengineering was an utter disaster. If you are saying SOA supports BPM/BPR I'll add that to my list of reason NOT to adopt SOA.

Sun freshens Solaris 10 for new iron

Feb 19, 2013 · Tony Thomas

Jurgen,

Your reply doesn't seem to address any of the points raised in my piece. Rather it reads like a regurgitation of the usual arguments for SOA.

Sun freshens Solaris 10 for new iron

Feb 19, 2013 · Tony Thomas

Mark,

Thanks for your comments. Do you have a link to something about the Netflix SOA you say is right?

I'll agree SOA is not all about reuse, however it is often presented as that - especially to developers and probably to the business too. Perhaps the first thing to get straight when you look at SOA is: Why? - what are you hoping to achieve?

The SOA initiatives I have seen are bolting on after exercises. In particular: bolting the mainframe to the web. I've actually started to wonder if really SOA is a cover story for just this.

As for maintenance: if you have separate teams they can at least handle issues themselves. When you link teams together you need to coordinate these fixes. At that point dis-economies of scale really cut in.

Reading Documents on your Screen Effectively

Jun 07, 2010 · Tony Thomas

Thanks for your comment, can I reply in reverse order?

I whole heartedly agree with your final point. There are many different types of projects, many different type of developers and many different ways to fail. When you look at projects that work certain common patterns and practices emerge. As Tolstoy wrote "All happy families are happy in the same happy way, all unhappy families are unhappy in ther own unique way."

The greatest mistake is to blindly follow anything to the extreme without questioning it and asking "Does it apply to me?". For that reason I often talk about Agile as a set of tools in a toolbox and you select the ones that apply.

This piece, from the picture on, is a discussion of things you could do to improve your code quality. This is a list of tools: pick some. Its not a comprehensive list, I ask for more suggestions, nor is it a mandatory list, its a list for you to pick from.

As to pair programming I do not believe it doubles cost at all. On the contary, I find that pair programming enables deep thougt because it provides someone equallly dedicated to share the thinking. True, if two developers are not compatible there will be problems, but, there will be problems if two incompatible programmers are working on the same project anyway. Pair programming will simply highlight the problem sooner.

As to TDD assuming the design is 100% complete before you start coding nothing could be further from the truth. Not only does TDD not assume this but it greatly assists in helping designs to emerge over time. In the long run TDD is an essential completement to refactoring and emergent design.