It doesn’t work like that in enterprise
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 170 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/50855 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Enterprise architectureComputer fontSoftware developerComputer configurationConstraint (mathematics)Process (computing)PlanningStandard deviationData managementSoftware developerPower (physics)Cartesian coordinate systemForm (programming)Core dumpPhysical systemType theoryProduct (business)Domain nameData conversionInformationRange (statistics)SoftwareInformation technology consultingConfiguration spaceFrustrationContext awarenessBuildingWeb browser1 (number)BitClient (computing)Enterprise architectureComputer fontSphereLine (geometry)Metropolitan area networkWeightOperator (mathematics)Service (economics)Computer virusExpert systemWeb 2.0Application service providerWeb applicationFunctional (mathematics)FrequencyDifferent (Kate Ryan album)Computer animation
04:58
SoftwareSet (mathematics)Enterprise architecturePhase transitionComputer configurationControl flowProcess (computing)FrequencySoftware developerEnterprise architectureFrustrationProcess (computing)Roundness (object)Lattice (order)Phase transitionSpacetimeWhiteboardMultiplication signClient (computing)Group actionResultantMarginal distributionSoftware maintenanceCodeUniverse (mathematics)Context awarenessComputer configurationComputer scienceGoodness of fitMomentumProduct (business)DivisorBitElement (mathematics)SoftwareSpiralInformationLogicPoint (geometry)Archaeological field surveyForm (programming)Game controllerDifferent (Kate Ryan album)Physical systemComputer programming1 (number)Meeting/InterviewComputer animation
11:20
Perfect groupComputer scienceSoftwareCodeSoftware developerGravitationSoftware maintenancePoint (geometry)Procedural programmingInterface (computing)Form (programming)PermanentTraffic reportingFrame problemMultiplication signClient (computing)AreaField (computer science)BuildingElectronic visual displayOrder (biology)Sign (mathematics)Domain nameClassical physicsProcess (computing)Application service providerStandard deviationCodeDivisorSystem administratorCache (computing)Particle systemCartesian coordinate systemDatabaseWave packetConnectivity (graph theory)Constraint (mathematics)SequelCASE <Informatik>MultiplicationComputer animation
14:22
CodeProcess (computing)Projective planeElement (mathematics)Keyboard shortcutSound effectCapability Maturity ModelSoftwareMultiplication signSet (mathematics)Key (cryptography)Film editingSoftware developer
15:34
Enterprise architectureProcess (computing)Control flowSoftware developerPlanningIntegrated development environmentInternet forumWeightApplication service providerHuman migrationPersonal digital assistantWeb pageInstallation artVideo gameDifferent (Kate Ryan album)Process (computing)Multiplication signSoftware developerCartesian coordinate systemLattice (order)Line (geometry)AreaEnterprise architectureSign (mathematics)FrustrationImplementationOcean currentCodeBitMereologyPosition operatorData managementFrequencySpreadsheetCycle (graph theory)InformationGame controllerProduct (business)Compilation albumAnalogyTerm (mathematics)Limit (category theory)CurvatureCategory of beingSoftware maintenanceError messageIntegrated development environmentPerspective (visual)Statement (computer science)MathematicsCurveDependent and independent variablesWeightVisualization (computer graphics)Application service providerWeb pageSphereClient (computing)Computer animation
22:43
Application service providerInternet forumWeightPersonal digital assistantHuman migrationWeb pageInstallation artEnterprise architecturePlanningData managementCodeControl flowSoftwareStandard deviationSoftware developerData managementDecision theoryRule of inferenceServer (computing)Computer programmingSlide ruleCASE <Informatik>BitProcess (computing)Client (computing)CodeMereologyGame controllerExclusive orConfiguration spaceLine (geometry)Data dictionaryEntire functionVideo gameWebsitePhysical systemEnterprise architectureTest-driven developmentPoint (geometry)Software testingSoftware bugStrategy gameObservational studyContinuous integrationFrustrationInformationData conversionProjective planeSystem callSoftwarePower (physics)Goodness of fitLine codeImplementationDomain nameMultiplication signForm (programming)INTEGRALStructural loadRight angleSingle-precision floating-point formatMaxima and minimaRoundness (object)Basis <Mathematik>Computer animation
29:53
Standard deviationProcess (computing)Data managementCodeProjective planeSoftware testingClient (computing)PlanningTouchscreenSoftware developerPlastikkarteGame controllerSet (mathematics)Element (mathematics)Greatest elementControl flowSource codeCompilation albumSoftwareMultiplication signComputer fileData miningVirtual machineCausalityConfiguration spaceSlide ruleMechanism designGodFrictionImplementationWordServer (computing)Point (geometry)TendonDecision theoryTask (computing)Revision controlOffice suiteIntegrated development environmentConnectivity (graph theory)Database transactionWebsiteLetterpress printingFormal languageRight anglePower (physics)Enterprise architectureLine (geometry)SequelDemosceneDirected graphMultiplicationNumbering schemeNetwork topologyMathematicsDirectory serviceCore dumpService (economics)GoogolHuffman codingDomain nameLocal ringProbability density functionArchitecture1 (number)Social classSingle-precision floating-point formatHookingVisualization (computer graphics)Remote procedure callComputer animation
37:03
Client (computing)Control flowCoding theoryData managementThumbnailPoint (geometry)Differenz <Mathematik>Revision controlPhysical systemLine (geometry)Software developerClient (computing)FrustrationCausalityDependent and independent variablesInformationBasis <Mathematik>WorkloadElement (mathematics)Process (computing)Division (mathematics)Uniform boundedness principleStandard deviationArithmetic progressionTerm (mathematics)1 (number)Different (Kate Ryan album)Wage labourLevel (video gaming)Solid geometryMultiplication signGame controllerShared memorySheaf (mathematics)Sound effectImplementationSystem callExpected valueArchitectureComplex (psychology)Observational studyInequality (mathematics)Data structureRight angleLabour Party (Malta)Structural loadComputer animation
44:40
Data managementSoftware developerStaff (military)Control flowStandard deviationRule of inferenceEnterprise architectureSoftware developerImplementationDependent and independent variablesProcess (computing)Game controllerSoftware maintenanceCASE <Informatik>Rule of inferenceStandard deviationProjective planeRotationOrder (biology)Point (geometry)Natural numberDesign by contractStrategy gameRunge's theoremHierarchyDomain nameBranch (computer science)BitData structureExpected valueDecision theoryElement (mathematics)Drop (liquid)Feature Driven DevelopmentFunction (mathematics)Client (computing)Latent heatForm (programming)Multiplication signMathematicsCodeReal numberRight angleComputer animation
51:47
Control flowGroup actionData integrityMathematicsGame controllerCodeComputer configurationFocus (optics)PermanentSet (mathematics)Forcing (mathematics)Data conversionPosition operatorDependent and independent variablesMathematicsSoftwareGroup actionTable (information)Digital photographySoftware developerProcess (computing)INTEGRALBitPhysical systemData managementComputer animation
54:30
Game controllerProcess (computing)Server (computing)Enterprise architectureMultiplication signNumberBasis <Mathematik>Video gameFeedbackProjective planeWordPerturbation theorySurface of revolutionPlastikkarteComputer animation
56:01
Computer-generated imageryMaizeEuler anglesDean numberSymmetry (physics)Human migrationFeedbackPlastikkarteStatisticsComputer animation
Transcript: English(auto-generated)
00:00
Hello. Can everyone hear me okay up there? Yep? Brilliant. Thank you very much for coming along, despite of Messrs. Edwards and Fowler over there in the other room talking about very exciting technological things. So my name is Peter Smith. I'm an ASP.NET consultant,
00:21
specializing in browser-based applications and web APIs. I've been a developer for just over nine years, and pretty much the whole of my career I spent working on enterprise or line-of-business applications. And within that particular sphere, I'm an expert on what I like to call emergent domains.
00:43
Now, a lot of these companies who have an in-house development team are working towards a holy grail, so to speak, of a configurable application where non-technical business users can make tweaks to the functionality to be available to a customer's domain without the coders getting involved.
01:01
So they typically do this through configuration forms in the application itself, and they can do all kinds of powerful things with this. Now, I'm not actually here to discuss whether or not this is a good idea or a bad idea, but what I do know is that I've got a lot of experience working with these types of companies that want these systems built,
01:23
and also a lot of experience with the types of people behind the companies who are asking these things to be built as well. So you can see the outline, well, not quite behind me, above me here. But this talk is probably going to be a little bit different
01:41
from some of the other ones you'll hear today. I'm going to start by saying if you're expecting any kind of one-size-fits-all solution as to how to fix enterprise development, if you're looking for a magic bullet, then I do not have that information. So if that's what you're expecting, then feel free to leave now.
02:01
It's intended to be very light-hearted. I'm going to summarize a handful of what I believe are the common frustrations facing enterprise developers in our kind of day and age. And for each one, I'm going to tell you a story from my own personal experience. Now, these are not going to be objective really in any way.
02:23
They're going to be very personal, very kind of, very much my own experiences. And then I'm going to tell you what I learnt from each one and what you guys might be able to do if you're in a similar situation.
02:41
So, whenever I give this talk, someone always comes up to me afterwards or I'll overhear a conversation, and someone will be saying, that's not enterprise development. I work in enterprise. Enterprise is different. This is not relevant to me at all. And so I've taken the liberty of defining what I believe enterprise development to be,
03:01
at least for the context of this talk. So, to start with, I believe it's to do with non-technical companies that might have an in-house development team. So they're working on software that is pivotal to their business, but it's not their core product. They don't sell this software. They use it purely internally.
03:21
I've also extended my definition to include, say, software as a service or applications that have already been built. Perhaps they do have an emergent domain, and they are merely now in the business of bringing on new clients, configuring an off-the-shelf piece of software for a new client.
03:41
So they're not necessarily building features. This still happens, but it's not necessarily their primary purpose. And finally, I've constrained the context of this talk to small- and medium-sized enterprise companies. Large companies tend to have their own unique problems,
04:02
and they tend to be able to throw money and consultants at problems. So either they bring these consultants and contractors in, and they do things very, very well, or terrible, terrible things happen that are way beyond my remit to suggest anything to do with it. So out of everyone here today, how many of you work in an enterprise situation?
04:26
Quite a few of you. And how many of you have heard the phrase, such as the title of the talk, it doesn't work that way in enterprise? How many of you have given that advice to maybe a junior?
04:41
A couple of very brave people admitting that there. So regardless of if you haven't experienced this, then you've been very, very lucky. But we all know that enterprise development elicits a wide range of emotions. Confusion, fear, occasional periods of happiness,
05:07
but mainly frustration. And I'm sure we've all got our own personal stories of frustration. I mean, one of my very first things I remember from one of my first kind of employments was I'd heard of this very exciting new technology.
05:22
It was going to revolutionize everything we did. It was called Ajax, and it was very futuristic and brilliant. And so I'd knocked up a quick autocomplete form, and I took this to my technical architect. I was like, look at this. Look what this does. This is amazing. It's brilliant. And they looked back at me and they said, I'm sorry, Pete.
05:41
You're going to have to take that out. And I have no idea to this day why they told me this. The only advice they could offer was that, oh, they said a client might see it and that they might want it. And I didn't quite understand that logic. It seems very backwards to me because surely the clients benefit from what the developers do
06:00
in their facing element of the system anyway. So we all know that there are these incredible frustrations in enterprise development. So what can we do about it? Well, first, I think we need to understand a little bit about why enterprise is different from, say, working for a software house or maybe a large bespoke vendor.
06:23
So no one ever sets out to build bad software. We know this. Everyone starts out with the best of intentions. But often, businesses start out with a startup mentality where code quality kind of takes a back seat
06:43
because if you don't get this feature ready to secure your next round of venture capital funding, then your business is over. You always have to manage the technical debt and come back to it. So in this respect, actually, startup and enterprise can be quite similar. But it's very important that you transition
07:00
out of that phase correctly and come back and deal with the technical debt that you built up. And if that doesn't happen, then that's a surefire way to end up with a kind of typical enterprise ethos. Now, within the enterprise, problems, I believe, are much more pronounced. You're in this kind of microcosm where everyone is encouraged to think in the same way and maybe lots of people have frustrations,
07:21
but they don't voice them. And these just kind of, you reverberate off each other, and these things mount up and they start to seem much more significant than perhaps they actually are. I believe there's a lack of competition within the enterprise space. If you have an internal development team,
07:42
there's no one else competing with you to build this product. There's nothing driving, no outside factor driving innovation. So whereas you might have, if you've got direct competition, if you're trying to pitch a product and there are various competing ones that do the same thing, then you're going to take much more care over it
08:00
and there's more impetus to do things correctly. And finally, I think that sometimes companies suffer from an excess of funds. Now, this might sound completely backwards, but the fact is that we know that writing software well and writing good quality maintainable code is cheaper in the long run.
08:20
We all know this. It may be hard to convince the business of this, but we know it. But if the company that you're working for has a certain profit margin that they're aiming for, if they've got things that they've set down in their board meetings, and if they can achieve those by still writing bad, unmaintainable, tightly coupled code, then they're still going to do it
08:40
because chances are that it's slightly easier to manage. They don't have to worry about ensuring that these processes happen. So they're going to take the path of least resistance, and as long as they're making enough money, then they don't really have any direct reason to write any better software.
09:00
So you're pretty much left with two options at this point. You can leave. If you do leave, then you have to make sure you're going to find a better job that's not just a lot of the frustration. So I'm going to talk about today a comment across all tiers of enterprise. So if you do leave, then you need to make sure you're going to find somewhere better. That's vitally important.
09:22
But of course, I guess leaving can sometimes seem like, we all sometimes get that feeling where you're like, I really should just find a new job. This is ridiculous. But you can stay, and you can try and take control of the situation. It's not going to be easy. We all know how easy it is to sit there
09:40
and kind of think to yourself, oh, they should put me in charge. Then they'd see how software development is supposed to work, you know? I would change this, then I would do that, and then things would be different. So this is going to be, this is not the easy approach. So I'm going to touch on both of these for each of my stories that I tell you.
10:01
I'm going to tell you my best war stories, which are pretty much situations where, actually looking back on it, I really should have left at the time. But perhaps I didn't, you know, kind of not necessarily recognize that. But yeah, as I say, I'm also going to try and tell you what I would do differently if maybe the situation hadn't been quite so severe.
10:23
So suffice to say, if you think you've got it bad and you think you've got frustrations, then you probably haven't heard anything yet. Okay, so let's have a look at some of the issues we might face day to day as enterprise developers. So I'm going to start with a very basic complaint in the enterprise,
10:42
and that is whereby practices or processes, or maybe the lack of them, in fact, more often than not, practices and processes are being prescribed by stakeholders of the business that really have no business telling developers how to work. You know, development teams should be able to decide for themselves whether they're going to do
11:01
pair programming or TDD. As long as they deliver the results to the company, the company should really not be meddling. But as we know, this is not the reality of the situation. This is not how it works at all. So I did computer science at university, like I'm sure quite a lot of software developers did. And I remember being struck by kind of
11:21
how haphazard everything seemed to be. There was very little emphasis on code quality in the course material, particularly the assignment seemed to be about all about building something, but not too fussed about what the quality of you built as long as the computer science was there and you had essentially fulfilled the requirements of the assignment.
11:42
So I remember thinking to myself, blimey, when I get to be a professional software developer, I bet things are different. I bet you if someone's business is riding on the software that I create, then I'm going to have to write it perfectly. There will be no excuse for anything less than perfection. So did I mention I was naive?
12:02
So imagine my shock when I get to my first permanent employment and things aren't perfect. In fact, they are far from perfect. There is no time set aside for refactoring, no coding standards to speak of, just these piles and piles of procedural classic ASP code.
12:25
So this company that I worked for employed an emergent domain. They say they could configure this application from within the admin area of the application itself. So this was really quite powerful stuff. If you could even control what was written to the database,
12:42
what was actually persisted in the SQL backing store, it would regenerate itself and you could build reports and data access forms, all kinds of things. But there was a catch, quite a significant one, and that was that these maintenance forms were very, very slow. So everything used a frame set,
13:00
and so you would edit. Say you wanted to build a data entry form and you have to compose it out of multiple fields which had maybe a label and a display order. You would kind of click one and you'd wait for both frames to load and then you'd hit save and wait for both frames to load again. And it was incredibly tedious. I mean, I cannot even begin to convey the gravity of that situation.
13:20
I should note at this point that actually our customers received interfaces built on exactly the same components, yet it must have been a sign of the industry that we're in, that they didn't seem to complain. But this was awful. And so as developers, we would often kind of just skip this process and go straight to the database, but that was error-prone
13:41
and certainly for the junior guys, you know, they could make horrendous mistakes in this way. But the fact of the matter is that the established way of doing your job of building a maintenance form for a client involved using these very, very slow maintenance forms. There was this constrained,
14:01
artificially constrained process. So, you know, we would often try and bypass this where we could, as I say, but the fact of the matter is the mandated approach was essentially you use these maintenance forms. So, of course, I hated this.
14:20
You know, around this time, I discovered that I'm a very lazy developer. And when I say lazy, I don't mean I cut corners and, you know, went to lunch early. I'm referring to this quote from Philip Leeson, is it Leeson? So I would, wherever possible, try and take little shortcuts to speed up the work I did by, you know, having little pet projects
14:42
or side projects. And that, in turn, afforded me more time to do my job and do other side projects. And you get this snowballing effect whereby, you know, you can innovate as well as doing your day job. Now, the fact that these guys had such an artificially constrained process, they were not only stifling innovation,
15:03
but they were also kind of diminishing the morale of their developers. And both of these things, especially the innovation, is a kind of key element to driving your business forward in the long run and to also keeping you competitive, you know, in years to come when your software is, you know, more mature.
15:21
So here was this kind of incredibly constrained process, and no one seemed to care. And the one set of people who maybe could have done something about it, the developers, well, their hands were tied by this process. So the reality of the situation is that, unfortunately, frustrations that maybe involve subpar tooling
15:42
or poor processes are pretty much par for the course in the enterprise sphere. As long as a suboptimal process is profitable overall, it's probably gonna be allowed to continue. As I say, if they're meeting their targets, then they're gonna have an Entbroke, why fix it kind of mentality.
16:02
There's always gonna be some kind of process in place, but it should never come at the cost of innovation. This is the warning sign that suggests if you're experiencing this, then maybe there's, you know, you can try, but maybe there's not a huge amount you can do if they are kind of risking everything for the sake of this process.
16:23
So you can take control of the situation. Don't stop being a lazy developer, even if all the other people around you are just doing what they're told. If you try hard enough, you'll always be able to find ways to speed yourself up, regardless of the process that's in place. As long as you take the care
16:41
and have the due diligence to make sure that you're still delivering. Most of the developers in the company are probably just gonna do exactly what management tell them. You know, don't be one of those guys. Be an outlier and do your best to fix the situation regardless of the process that's in place.
17:01
Now this one's gonna be possibly a little bit contentious, but if you are absolutely determined to help your company and if you want things to improve, then you may well need to consider putting in some of your own time to solve these problems. As we know, often as there's a learning curve involved in a new process
17:21
or something might kind of, your productivity might may dip before it goes up, so you need to make sure, if you want your company to take you seriously, you need to make sure that you negate that dip and try and keep your productivity flat until the benefits kick in. So finally,
17:41
keep innovating. You know, it is your duty as a developer to help your company innovate despite how difficult they may make this. If they see that you continue to innovate, that will put you above, you know, the next guy or girl and again they're more likely to kind of respect your viewpoint and take you seriously when you do suggest
18:01
improvements in the future. So, I mean this is, this is really all about doing the best you can, but also recognizing situations where maybe you couldn't try as hard as you might and there is literally nothing that you can do. I mean, I like to use the analogy that I think trying to better your enterprise company,
18:21
you know, from within as a regular developer is a bit like investing in Bitcoin. You've got to be prepared to lose your entire investment. You know, it may not come of anything and you have to be ready for that situation and ready to recognize where perhaps you need to move on to benefit your career. But you're not always going to know that you've reached that position
18:40
until you have tried. Okay. So now I'm going to look at another area where I believe a lot of enterprise frustrations arise and that's to do with maintainability of an application in the long term, but also with response to that term
19:01
that we all love to hate, technical debt. So this particular story begins when I had been with another company for about a year or so. Perhaps I think this was around 2006 or 2007. And the company then used classic ASP
19:23
and they decided that they would embark on an ambitious upgrade from ASP to ASP.NET. Now this was pretty spectacular in itself. This was going to be the single largest change this company would ever have endured. And they were entering into it willingly. So this kind of seemed like
19:40
pretty exciting stuff. And as I still were kind of junior dev, I saw this as kind of my time to shine. I had .NET experience while doing my dissertation. And in fact I learned something very important while doing my dissertation. And that was to never ever, ever do C++.NET. It's terribly confusing and it will only end badly.
20:01
I'm sorry if there are people doing C++.NET. So I managed to persuade these guys to hold off on their upgrade. ASP.NET 2 was just around the corner and they were quite thankful for that information and everything seemed good so they would skip another upgrade cycle. So time passed pretty slowly
20:21
as it does in the enterprise world. But then sure enough, as we approached the less busy part of our year when we had slightly less client implementations to build than usual, we were called into a meeting where we were told that the upgrade was imminent and we were all given various different MSDN articles to go and read to familiarize ourselves with the process.
20:41
So there were reams and reams of information coming out of Microsoft at this time about this upgrade path. And I managed to find one of the original documents we were given, which pretty much summarized all of the advice into one handy statement. So I'll read it to you. Most developers will probably choose to rewrite existing ASP applications to gain the performance, readability,
21:01
and maintainability improvements of the new development environment. As bearing in mind, we didn't have Visual Studio before, we didn't have proper debugging tools, and all the rest of it. So this seemed to suit us. This advice seemed, from my perspective, to suit us very well. We had no hard deadline. This is only an internal process. The only limitation we had is that we would do it in the two or three months
21:23
that we had on our kind of downtime period. And it seemed pretty open and shut. Here was the advice. Let's go and do it. So we're forgetting one very important thing here, and that is that it doesn't work that way in Enterprise. These guys had a much better idea,
21:43
and that was based around this. So I don't know if everyone can see this at the back, but this is the download page for a command line tool that converts ASP into ASP.NET. So we were going to undertake this mission-critical upgrade by converting our code line by line
22:03
verbatim with no structural changes whatsoever. Brilliant. And so we began. ASP code went in, .NET code came out. Horrible, horribly broken .NET code. So a spreadsheet was made of all of the compilation errors that resulted.
22:23
This is fun stuff. Look, we can compile everything ahead of time now if we want, and we can get build errors. This is brilliant. So this spreadsheet was divided up amongst the five or six developers we had in the team at the time. And then the next 12 weeks, by the time we were finished, of my life and the life
22:40
of all the other developers in the team consisted of fixing individual compilation errors in this 250,000 line code base. And then when that was done, when that was done, we had to fix the runtime errors as well. And to do that, we pretty much had to hit every single line of code. We had no tests.
23:00
We just had to manipulate the UI, put data in, use the system to basically hit every single line of that system to ensure what we had done was correct. Now, I think as developers, we often make jokes about how our jobs are going to cost us our sanity. But during this period, many of us actually dreaded coming to work. It was so monotonous.
23:21
And the worst part was that we could see how much better we should have been doing things, yet this decision was kind of just imposed upon us from above. So this is obviously a very extreme case of a company not planning correctly for the future.
23:41
But the fact is that I think a lot of enterprise companies are guilty of doing this, at least to some extent. Firefighting, as much as we dislike it, is much, much, much more common than actually proper, proactive working. I think there's maybe only one company I've worked for
24:01
in my entire career that I can truly say genuinely worked proactively. Sometimes there's no management of technical debt whatsoever. And as much as we hate this, this is unfortunately the reality of the situation.
24:21
And finally, it can be very difficult to accurately convey the value of writing good software. If the company has never experienced this kind of correct process or the correct way of doing things, correct in quotes,
24:40
then they've got nothing to compare it against. And we don't, unfortunately, have any studies or any kind of information that is guaranteed to convince your directorship if you did put it in front of them anyway. So once again, take control of the situation.
25:04
Start the conversation. I think this is possibly the most important point I have in possibly my entire slide deck today. Software development is kind of a little bit like politics in the way there are a lot of people, although they have a say, they do not have a direct ability
25:20
to influence the rules that are made from above. Yet it's vitally important that we all have the conversation. It's important that we all know the issues that are facing our country or our development team today and that we all talk about them so that if enough of us feel the same way, then our voice cannot, it can't not be heard
25:40
by the management or the powers that be. Don't forget it's vitally important that you lead by example in these situations. If you are lucky enough, it's not always possible if you're working as part of a larger team, but if you are lucky enough to have a project at work
26:01
where you can kind of call the shots a little bit, then stick to your guns. Write the software how you know you want to and in the way that you know is best. It will be a self-fulfilling prophecy in the end because they will suddenly realize, oh, hang on, this guy's software has got loads,
26:20
there's hardly any bugs in it at all. He did it in a week less than all our other teams seem to be able to. So you have to do this and you have to stick to your guns. So I mentioned how often there's no management of technical debt whatsoever in a company. But it's also true that there may well be a strategy in place
26:42
that maybe you can't see. Now, try and ask your architect or your development manager what the shelf life of your code base is. This is a good way to check to see if there is any management at all. If they turn around and say, oh, well, in two years, I think we've probably got two years max,
27:00
and then we're gonna rewrite it and include all the lessons that we've learned in the process. Now, I'm not saying this is a good way of managing technical debt, but it is a hell of a lot better than a company that turns around and answers that question with, well, this is the software. What are you talking about? You know, this is not a good thing. So that can often be a good way to find out.
27:23
And yes, as long as there is some impact, some understanding of the impact of technical debt, then possibly your frustrations aren't actually as bad as they may have first seemed.
27:41
Okay, so this story I'm gonna tell you now is probably the one I feel most strongly about. How many of you have worked for a company that seemed absolutely insistent that their approach was correct and they would doggedly follow this to the exclusion of all outside advice because they knew better?
28:02
Lots of you. So I'm sure it was something probably quite complicated, right? I mean, something that maybe companies could be forgiven for getting wrong. Perhaps it was they were new to continuous integration or they were trying to find the best way in which to apply pair programming
28:20
or test-driven development or, well, perhaps that was the case. But actually, sometimes companies can struggle much more with actually the basics, the things that you would never expect companies to run into. I worked for another company that had an emergent domain.
28:41
And the process for building a new client system, the bread and butter of the business, was that you would receive a data dictionary from the project manager. You would work on your project yourself and a project manager. You would enter in using the configuration forms. You would enter in all of the client-specific details.
29:00
And then this site would go on a rack server with a few other sites. So I had this process pretty well done. As a lazy developer, I had a process that I would apply and was a good kind of, across the life of a two- or three-month project, it was a good three or four days faster. And I wanted to build this process
29:21
and I wanted to build a tool around this process. But once again, the company had a better idea. They had a more pressing issue. Because of the emergent domain, the actual code base that each of the client implementations would use
29:40
was 90% the same across all of the sites. There were only actually two or three things that you would actually use coding to do. Most of the time, these were developers that were essentially hired to mostly do data entry and some SQL and some support. So they decided that they needed to fix this problem
30:02
and that they had all of this duplicate code which was clearly bad. So how would we solve this problem? This isn't actually a trick question as much as it may seem that way. So you would use a class library, right?
30:21
If you're using static languages, you can compile your code ahead of time, distribute it to each of the sites, reference it. It's nice and opaque to the actual implementation. Jobs are good, right? It doesn't work that way in enterprise. At least it didn't, according to these guys.
30:42
And thus, the concept of base was born. Now, base is one of the most difficult things I've ever had to explain to anyone outside of that company, let alone an audience at a conference. But basically what they did is they took that 90% of the code and then they designated that.
31:01
So this code is now base. It's not gone anywhere. It's not read-only. It's still there in your code base. But you just have to know that you're not allowed to change it. And if you are caught changing it, then you're chastised. Or if you're a senior developer who knows that that's not what you're supposed to do, then you might even get a bollocking.
31:22
So this caused a lot of friction between the developers and the project managers. Salespeople being salespeople, whenever they went out to a client, they would often say, oh, yeah, yeah, you want this in your client, you know, your customer logo colors? That's fine. We don't really support that. But they would sell it to them anyway.
31:41
And so that was easy beforehand. With a couple of lines of code, we'd have to make sure we kept track of it. But it was easy, and the project managers knew this. So with this new process in place, all of a sudden, they get told, no, we can't do that. And then they have to go back to the client and deal with all of the fallout. So this naturally made them very angry.
32:02
At the same time, two or three of the developers were taken off the implementations, and they formed the new base team. So these guys are working on new features while everyone else is still configuring their emergent domains. Not only that, they're still working on new features,
32:21
and they don't really understand versioning properly, so they would release minor versions with breaking schema changes. So you have to know ahead of time what version of the software you're going to put a given client on. So now suddenly you can't just roll out a new version to a client anymore. And of course, occasionally clients would want
32:43
new versions and new features that weren't available to their particular configuration or the set of features available as per the emergent domain. So they would have to have an entirely new project. If you wanted to roll out a minor version to your client, it would be a new project, two months of a developer and a project manager.
33:03
So I mentioned how companies can struggle with the much, much more basic things. The source control, you would think, is pretty much a basic skill of even junior developers. If they don't have it when they join, they learn it pretty quickly.
33:23
These guys eventually gave up on source control altogether. It wasn't so much a conscious decision, thank God, as more of a kind of slide into disuse. But once we were at the bottom of the slope, there was certainly no... They weren't in a hurry to put it back.
33:42
So with the advent of Base, we now essentially have a situation where despite all of the industry knowledge that says this is a terrible idea, source control is one of the basic elements on the Joel test, what we would do now to start a new client implementation,
34:00
we would find the folder on the server called 4.2, and we would copy that folder and then begin work from there. Now, if that's not ridiculous enough, we wouldn't copy that folder to our local machine. Oh, no. The configuration process for a development environment on one's local machine
34:21
was seen as far too complicated for a developer to be undertaking. There were various kind of PDF printing components and all kinds of dependencies that weren't managed correctly, and so this did make it quite tricky, but if we'd actually had a process document, it wouldn't have taken much more than an hour. So they decided that developers should be working
34:41
on much more important things, client-facing things, than faffing around with their development environment. So you would copy that folder to another server, which was sat in the corner of the office, the development server, and then you would edit your code in place where it was hosted, and you would hook in via Visual Studio's remote debugging feature
35:01
and then do all your work that way. And if the server goes down, then no one can work, and this did occasionally happen. I said how we had the base team that worked on the new features, and the no local policy extended to these guys too.
35:21
So how many of you are familiar with Google's approach to source control, where they have a kind of single monolithic code tree with multiple languages, millions of test runs a day, and everyone commits to master? So these guys were all working on the same code base, and I'm not just talking about the same set of source files.
35:42
These guys were all working together, five or six developers by this point, on the same physical directory on the server. Let that sink in. So if Jane comes along and opens a file, and Bob opens the same one, and remember that this is the same code base.
36:02
So if anyone breaks the build or causes a compilation error, all six people get a yellow screen of death. And they were literally, it would be kind of, oh, ha ha ha, who's broken the base now? And I'd be, no! No, this is not funny. This is a terrible, terrible situation. And they would actually have to organize how they worked to schedule the tasks
36:23
in their backlog, for want of a better word, around this mechanism. And finally, this only worked at all because we had a website project where the code would dynamically recompile when it was changed.
36:41
So now what we have is a situation where we are locked in to certain architectural decisions, can't be changed because of a purely organizational concern that was set down by the development team itself. So this is obviously not a good situation to be in.
37:04
As an aside, when I first gave this talk, a friend of mine, who may or may not be in the audience somewhere today, told me about a story from his company where source control for them was a thumb drive. So they would put their hands up when they wanted to merge and be like, can I have the thumb drive?
37:20
I need to check in. And they would do it with a diff tool, plug the thumb drive in, and then give it back. It's what I wouldn't have given for a thumb drive at this point. My kingdom for a thumb drive. Okay, so the moral of this story is that you probably shouldn't worry too much if your company has misunderstood semantic versioning
37:42
or thinks they have a better versioning system or thinks that TDD isn't going to bring them value or something along those lines. There are many, many, many worse things that could happen. But companies do often tend to shy away, I think, from things that might seem too trendy or too modern, especially if they're overly risk-averse.
38:06
Then things that are kind of shiny are going to scare them a little bit. And I'm not saying that this is correct, and you should always do all you can to try and negate that opinion. And possibly the best way is to, as I said earlier, to lead by example and show them that these things
38:21
aren't going to be a problem. Individuals often overlook the simple answer because they're looking for a complex one. You might want to demonstrate, it's not a conscious thing, but subconsciously everyone wants to be clever, and they want to show their new skills and they want to show what they can do.
38:41
But often we miss the glaringly obvious solution that's right under our noses. But most teams generally manage to get around these problems. Generally the client will always come first. Most companies luckily don't have those crazy situations where organizational aspects of the development team
39:02
dictate the architecture. So as long as your client can respond, sorry, as long as your company can respond to client demands in a reasonably cost-effective manner, then your frustrations again probably is maybe not as bad as first seemed. How are we doing, 20 minutes?
39:22
So, take control of the situation. Time again, this is what you can do. Share your knowledge. Again, make sure that if you know something, that you talk to other people about it.
39:41
Demonstrate, I initially wrote cool here, but I changed it to useful. You want to demonstrate the technologies and the practices that will bring value, that will have demonstrable value to your company. If you don't show them these things, then chances are that although you're doing your job correctly,
40:01
keeping your ear to the ground, studying, learning, these guys, they may not be. It's very important that you know the why as well as the what and the how for the various architectural styles or tools you may want to use or you think may benefit your company.
40:21
You need to be able to produce when asked all of the relevant information as to why should we use this particular process or practice. What are the benefits? What are the disadvantages? What are the situations it doesn't work in? If you don't have this information to hand, then it just, again, you just seem like you're trying
40:41
to bring some cool new thing that you want to work with. Introduce people to the wider community. These guys may not even realize that there's a community out there and help people discover that actually there is an art and a joy to coding. You know, I find this especially senior developers can get entrenched.
41:04
They may have worked for a single company for their entire career, and they've never seen that anything is or can be done any differently. So it's up to us to introduce them and show them and say, actually, this is how things should work. If developers have the correct level of freedom
41:20
to undertake their job in the way that they are supposed to, then actually this becomes a lot of fun. Now, rejection of industry standard knowledge, unfortunately, is a very hard habit for a company to break, and it's a very hard thing for you to crack as an individual. So you need to try taking a slightly different approach
41:42
and fight the cause of the problems rather than the symptoms. Typically, the frustrations and the firefighting and the working late, these are all symptoms of the problem and not the underlying cause that perhaps the company doesn't have the right mentality or the right approach.
42:07
Okay, so final section. I've talked a lot about the technical pitfalls that companies can fall into, but the fact is there are just as many social and personal ones.
42:20
Social, personal aspects that companies can overlook. Now, the good news, the good news for this is that typically if a company is successful and they have a poor technical outlook, then the chances are that the social side of the company, the personal side, is going to be much better.
42:41
The reason for this is that there's got to be something preventing excess labor turnover. There's got to be something that keeps your developers coming into work every day in the absence of solid technical career progression and opportunities. Of course, just because a company has a good social side to it doesn't necessarily mean that it's best for your career in the long term.
43:03
But the fact is that leaving a company is always the hardest thing to do. Staying is always the path of least resistance. If you work with your friends and maybe they pay for you to go on outings and you go to the pub regularly and you have loads of fun,
43:20
then you've got to be reluctant to leave regardless of the technical situation. But flip this on its head and if the company has, if there's bullying or discrimination, inequality, then it doesn't matter how good the technical side is. You're going to be out of there pretty quickly. So one of the companies, in fact this is the same company
43:41
that had the base idea. One of the things that attracted me to this company in the first place was that they were founded on a really impressive ethos. The directors had previously worked for companies where they were expected, they were developers themselves and they were expected to work long, long hours with little to no reward, certainly no overtime pay.
44:03
But this was kind of standard and this is just what they had to deal with on a day-to-day basis. And so they decided that their company was going to be different. They were going to be fair. You could come in and do your 9 to 5 and then you could go. And this was their central philosophy and I thought this was very benign and I was quite impressed.
44:23
So they started off with quite a flat structure and as the company grew, the need arose for them to be able to delegate responsibility to multiple people so that they could split the workload. So they thought that the base element of things was quite a good division to make. So they took all the developers
44:42
and they created three teams. So two to manage implementations and one for the base team. The implementation teams were headed up by freshly promoted members of senior development who are now team leaders. Likewise, there's a team leader in the base team. But anyway, these guys are off building their new features
45:02
and these guys are still doing their implementations. So because they were keen to keep everything fair, they knew that the place to be was going to be in the feature team. They knew that people were going to much prefer to work in that team. So what they decided was that they would rotate developers through the teams.
45:23
So you would finish an implementation and if a slot came up, it would pretty much rotation would be every three to six months and you would be given the opportunity to move from an implementation team onto the feature team. Which seems really benign and it sounds like a great practice, right? But in reality, it was absolutely terrible.
45:43
And for two reasons. One, it created a real us and them mentality between the base team and the implementation team. Inevitably, client requirements would change at the last minute. A client might sign a contract early and suddenly, suddenly, Jane with three years experience,
46:02
oh no, sorry, now you have to do another project. And that would be another six months of implementation work for you. Sorry, last minute. There's no other way to do it. And then Bob, who'd been with the company three months, now gets to go on the implementation team. Sorry, the feature team. And so this is just now completely backwards and just as a developer gets up to speed
46:24
working on the feature team, they are taken off again. And so just as they've learned the skills they need, just as they've managed to shake off the fact they've been using maintenance forms for the last six months, they're taken back off. And so there's pretty much no, not many people remain in the team long enough
46:42
to really be properly productive. So it's kind of become obvious to me as I've made this journey, that a lot of enterprise companies, they seem to be, they seem to treat their developers as a liability rather than a resource.
47:02
They seem to be living in fear of what their developers might do. It's like they put all of these stringent practices and hierarchies and processes in place to try and limit the amount of mistakes their developers can make. I guess it's a kind of, oh, if we don't give them the opportunity to fail,
47:20
then they won't. Now, of course, this goes against the very basic element of human nature where we learn by making mistakes. If developers aren't afforded real responsibility, then their morale drops and so on. And again, you lose this innovation that your company requires to remain competitive in the long run.
47:44
When you have such a stringent structure in place, you get what I call the rungs of the ladder promotion strategy. You can only climb up the ladder so far until there's someone above you. And then from that point on, the only way for anyone to be realistically promoted
48:01
is either for someone above you to leave or for them to grow enough so they add more rungs underneath the ladder and then you can move up as the hierarchy branches upwards. And finally, people with responsibility will often tend to protect that. Again, I don't believe this is a conscious thing.
48:20
Perhaps there are some terribly vindictive people out there who deliberately limit the careers of their juniors in order to protect their own interests. But people are not going to be willing to train someone up to the point that they then replace them. I think this is one of the underlying problems
48:40
of enterprise development that is not gonna go away in a hurry because it's tied to fundamental human nature. I mean, in the case of the company I talked about just now, that whole situation could have been solved just by empowering the developers, just by giving them some more real responsibility. But instead, the only way to promote people
49:01
and to keep them interested was actually just to give them new job titles with no real change in actual responsibility. So there was a role called technical architect which reported to the real technical architect. And their job was to write functional specifications.
49:20
And these specifications would actually be so concise that they would say things like, go to this, open this file, and change this method. So if they just told the developers, instead of saying you don't earn this 90% of code, do exactly the opposite. Say this is your code, you own it. Then they could have done so much better.
49:44
Okay. So once again, take control of the situation. Remain true to yourself on your own standards. Again, don't get bogged down by what everyone else wants you to do.
50:01
You need to stand up for yourself. And if these guys are trying to push something that is not right, then you need to say this is not right. You need to say no. I saw a really great talk by Uncle Bob at NDC London last year, but I know it's a talk he's done many times where he sets out expectations he has
50:22
if he's going to come and be your new CTO. And one of them is to say no. And I think this is vitally important. I think if more people followed Uncle Bob's advice, then the enterprise world would be a very different place.
50:42
So finally, I've mentioned how it's important that you have to identify where maybe you should leave a company and how this can often be a difficult decision to make for various reasons. So this is my golden rule. It's not my golden rule. I think it's probably a more well-known rule.
51:02
But if you are not still learning things that are going to benefit you outside of the domain you're working in for your career as a whole, if you cannot answer yes to this question, then you should probably look to be dusting off your CV. It is vitally important that you do this. If you get stuck in a rut
51:21
where you're not learning anything because your company is resistant to change or what have you, then it's going to make it very difficult for you to move on further from that. So this is maybe the bit that you've all been waiting for. What is the solution? What can we do to fix enterprise development,
51:43
bearing in mind that I've already told you that this is not a magic solution? You guys are the solution. Every single member of the audience here today, you have the control. You may not always be able to control what other people do, what your management do,
52:00
or what your team does, but you can always control what you do. As I said, stick to your morals, say no, start the conversation. All of these things are things that we can directly do, even if you're not in a position of responsibility directly to change things. It is up to us. If we think about it,
52:20
if your system has entropy and technical debt, whose fault is that? It's the developer's fault for writing the software in that way in the first place. It doesn't matter that you can't claim that you were told to do it by someone else. Ultimately, we are all responsible for the quality of the code that we write, and this should be our primary focus.
52:44
One thing I learned when I made the transition from being a permanent employee to a contractor was, as a permanent member of staff, I saw it as my responsibility to instigate change, and when it didn't happen, this upset me, and I kind of felt, well, why aren't you letting me do this?
53:00
I guess I ended up being a bit whiny, being like, oh, you really should do this. Why haven't you done this yet? Why haven't you done this yet? As soon as I became a contractor, and now I'm paid to give advice and to get something done, so I would now come in, and I would say, well, your options here that you've put down on the table, they have these failings, and they have these pros,
53:22
and now I have this approach, which has these failings and these pros. It's up to you to decide, and I suddenly found that actually I got so much further with trying to instigate change than I ever had done when I was being really pushy and trying to get these things pushed through.
53:45
And linked into that is never compromise your own integrity. If you end up being the whiny developer who doesn't get their own way, then that's how they're gonna see you, and they're not gonna respect your opinion, and you're much less likely to have your voice heard.
54:03
And finally, I'm sure you've all heard this term, but change your job or change your job. If you are unable to make the changes despite your efforts, then find a new job. It's not anywhere near as difficult as some people may have been in the past.
54:20
They're pretty much falling over, falling over each other to hire people these days, so if you recognize that situation, change your job. Okay, so I mean that's pretty much it. I can tell you that it does work that way in enterprise if you really put your mind to it. I've worked in companies that have done things right,
54:43
and it worked, and it's been brilliant. So it can be really easy to get disheartened when you have people telling you, oh, it doesn't work that way in enterprise the whole time. But don't believe it. It's just simply not true. It is one of the greatest fallacies in our industry.
55:01
Stand up for what you believe in, take control of the situation, and hopefully you'll find things get better. But if they don't, then you need to, the priority needs to be number one, and you need to go and find a new job. It's literally as simple as that. So I'm gonna leave you with one final anecdote.
55:23
I mentioned I wanted to build a tool earlier on in one of my stories to encapsulate a process. I did eventually build this tool, and when I left, I left it in the capable hands of one of the really snazzy junior guys who was really good. I met up with him a few months later for some beers,
55:42
and I said, how's it going? You know, how's the project? Because it was really revolutionary stuff. And he looked back at me and said, well, we don't use it anymore. I was like, why not? Why not? He's like, well, the VM that it ran on made the server room hot, so we turned it off.
56:00
And with that, thank you very much for listening. Thanks to the conference for letting me have this opportunity, and please leave the feedback in the cards. And if you have any questions, either come and see me, or I think we've got a couple of minutes.
56:24
Or if anyone likes stickers, I have some down here. Not related to the talk, but just nice stickers.