It’s always good to get the 100-foot view, especially when learning about rapid application development in the breakneck-speed technology space. We spend so much time just a couple feet from our monitors, working hard to complete this project so we can hurry to the next one, that it takes a little effort to step back. And if stepping back means a few hours’ worth of reading? Tough to justify those hours, just to gain an overview, when a deadline looms just two feet away.
But a few minutes? That might work. Then, if what you see is promising (pronounced, “potential to make you more productive, or more profitable”), spending time afterward to get more detail becomes an investment. With less risk, and more upside. After all, if you could eventually spend less time on each project, you could take on more projects… or have time to be a couple feet from something else. Like the beach.
The expanzPLATFORM Architecture video is designed to be just that: an overview of expanzPLATFORM that explains how it works, and why you should care, delivered in just a few minutes. Imagine your code base—your .NET code base—reaching all those client devices out there, without recasting or recoding for each platform. I know, sounds impossible, even if it would be panacea. We’ll come back to that. How about imagining your .NET code base running on-premise, or on Azure, or Amazon, or Rackspace, without any additional code work. As in: get an Azure account, move your app over with the flip a switch, and your code runs in the cloud. No re-writes, no cloud-specific code of any sort. In fact, here are some concrete examples of what expanz does for you, with no effort required on your part:
- expanzPLATFORM abstracts the need to specifically create scalability architecture, by doing the following for you:
- adheres to best-practice architecture security principles, such as pushing the application server into the trusted zone of an intranet
- provides database concurrency and row versioning
- load-balances session management through using a site manager
- provides auto-scaling architecture, without reworking or adjusting any facets of the architecture
- expanzPLATFORM provides diagnostics out of the box, which is configurable at runtime… turn it on and then off, and see how servers are performing… in real time
- expanzPLATFORM provides global logging from all server instances via table storage
- expanzPLATFORM’s custom types leverage Azure’s functionality; the expanz BLOB image type can be selected in expanzSTUDIO and then, for free, developers get access to that BLOB via BLOB storage, and have access to it via the CDN… all of which is taken care of within the type
- you don’t need to know the requirements or implementation nuances of the Azure platform… just create your application on expanzPLATFORM without having to worry about any of these things
Rather than having to do all this yourself, expanzPLATFORM just works. And then… after you’ve moved it to a cloud provider, move it back if you want, or to another provider, just as easily. Sound interesting? Sound better than figuring out how Azure works, its nuances, and comparing that to Amazon Web Services, or Rackspace, or any other provider? Are you starting to see the beach?
Back to those clients, those seemingly new-device-every-month clients. You know them. Let’s take an example, and extend it from there.
Let’s say you create an application for your customer on expanzPLATFORM. The customer wants to access the application on her iPhone and iPad. You model the app in expanzSTUDIO, add some code to the models to meet her requirements. Next you design just the UI elements for iOS, using the tooling support that’s built into the expanz client SDKs, enabling drag-and-drop native UI design right in the Xcode IDE, just like you would design any iOS UI. But it’s easier yet, because that tooling support also surfaces the associated server-side field names automatically — right in the Xcode IDE — so they’re ready and waiting, again enabling you to concentrate on your UI. And all the code runs on the server, so you simply need to enable her to interact with her app from her iPhone and iPad, so it’s user controls and the like. But no business logic there. You finish, and one week later she gets a Windows Phone. Now what? Simple: take those UI elements you created for iOS, and recreate them – natively – for Windows Phone. Just like before, the tooling support in the expanz client SDK for Windows Phone 7 surfaces the associated server-side field names. And you’ve already design the UI for iOS… so you get to reuse that design effort, not reinvent the business logic code behind it (because there isn’t any on the client). You don’t have to think through the layout all over again… you did that when you designed the UI for iOS. Just replicate, or reuse, the iOS UI layout in the native Windows Phone 7 development environment. No additional business logic is needed, because it’s all on the server. Just replicate the UI on the other platform, in its native IDE using ready-made expanz client SDKs, and you’re done. That’s it. It’s ready to roll. A month later she calls during lunch, from an Android phone. “Can my app…?” “No problem,” you say. You’re getting good at recreating that UI, because the design is already done. Since the business logic is on the server, you don’t have to touch that. Just the client UI. Grab the expanz client SDK for Android, fire up the Eclipse IDE, and by the end of the day she’s running her app on her Android phone. You’re her hero, and more than that… you’re looking at getting a tan.
It really is that straightforward. It might sound easy, and it is for you, but there’s a lot of heavy lifting done behind the scenes and under the covers. The platform itself is the culmination of years of work, pounded on by enterprise-class applications that scale to tens of thousands of concurrent users and our inherent knowledge of cloud providers that obfuscates all their individual requirements for you. Sounds simple, maybe, but simplicity and elegance are almost always the result of hard work and thoughtfulness behind the scenes. But you know that, already. You’ve lived it, had to code it. Why not make all that difficult work go away, so you can concentrate on what makes you most successful? And don’t worry, you can take all the credit. Finish your projects faster, extend their reach—to any cloud and any client device that strikes your customers’ fancy—and be happier.
How does expanzPLATFORM do all this? With rock-solid architecture, designed to make your life easier and your apps more scalable and robust, enabling you to be more successful. So take a look at the architecture video and see for yourself.
We have more videos coming soon and an entirely new website design in the works, with all the drill-down detail you’ll want to see after you view the architecture video.
If it seems interesting to you, give the prerelease of expanzPLATFORM a try. It’s free, it has a Getting Started guide that has you creating completed clients in under five minutes, and it’s the first step toward getting your toes in the sand.
Remember the Monty Pythons ...
and their Albatross sketch? What a talented group they were! They used every comedic tool to the max, from slapstick to irony and even shock/suspense: "Your highness is like a stream of bats piss" [the King] "WHAT!!!!"; "Like a shaft of gold when all around is dark" - phew, relief. But I digress; which you claim is impossible as I have not yet started. Oh but I have - did you read the title?
Managing expectations
One of the issues we have at expanz is managing the expectations of developers and helping them understand what you get with the expanzPLATFORM (eP) - what does it do? Do you get wafers with it? Can you login with your Facebook ID? etc etc. The answer is actually very simple, but different to what you might expect. In fact, the answer is exactly the same as the answer to the question "What does c# do?". The answer can by 'anything' or 'nothing' or 'whatever you want'. Most developers have at some point been forced to use a 'framework' to help build their apps. And have come across the typical 80-10-10 rule where the framework makes 80% of their work quick and easy, 10% hard and 10% impossible. The eP is framework-like but is based on object-oriented design principles so everything is virtual which makes anything possible.
The answer is always Yes.
No need to ask for wafers
Here's the big difference: the eP allows and encourages extension and development of the framework. Kind of a meta-framework. Stop thinking 'what do I get?' - no wafers here - and start thinking 'What can I build?' - in terms of components.
Out of the box, you get quite an extensive set of server and client side components, all of the ones we used to build our ERP proof point that the eP works. The client SDKs cover all the major technologies - WPF / Silverlight / WP7, Adobe Flex, Android, iOS and HTML5 / JavaScript. Most importantly, everything is extensible. The existing components and framework can be tweaked, and new components can be added, resulting in an uninhibited UX and rapid server development because of the extreme reuse achievable.
Seeing is Believing
The eP is not a simple short term kick-starter code gen here ya go now you're on your own framework. It is a long term strategic shift in the way you build apps, that just happens to outperform any code gen tool even in the quick build of a simple app. Watch the marketing video to get the idea
Try it if you don't believe me. Take a closer look at our architecture (really topology showing security, scalability features and differentiators) and sign up for free Prerelease Download.
We are keen to hear your feedback and how you are using our platform.
expanz offers 1st look at Client SDK for Apple iOS
Just like the expanz Client SDKs for Android, Windows Phone 7, Silverlight, WPF, WinForms, JavaScript and Adobe Flex, the expanz Client SDK for Apple iOS enables you to rapidly deploy a native mobile app frontend for an expanz .NET application server, using a familiar and platform-independent process.
If you’ve planned or worked on a cloud-based application that has to run on multiple devices, each of which needs a native look and feel, then you know how challenging it is to achieve that kind of portability and reach. Those requirements demand a broad range of skillsets, either to acquire or to hire, plus frameworks to select, concerns about performance, scalability, and other considerations that can keep you up at night. Seems like a lot of effort for what supposed to be a fairly straightforward, common set of requirements in today’s development world.
Here at expanz, we agree and - it doesn't have to be that hard! We’ve done the infrastructure work for you, so you can concentrate on your business logic and UX, the things that get you ahead. Why not see for yourself? We have a couple applications running on our demo apps server, just waiting for your iOS User Interface. You create the interface, and we'll take care of the heavy lifting and the nitty-gritty infrastructure details. You’ll be able to get your iPhone application up and running in minutes. Literally.
Prerequisites
To try out the expanz iOS SDK, you will need
Once you have those basics up and running, you're ready to fire-up Xcode (or your favorite iOS IDE) and create a new expanz-based project.
Create Your Own!
If you want to go even further and create your own iOS app plus a server application with expanz, we are happy to help you promote your app via guest blog and on expanz' facebook page! Looking forward to hearing from you.
First things first - let's go and get the full tutorial and SDK download:
Too tired & lazy today to bother with another well-composed and elegant blog. Sorry :). Instead a quick quiz – to separate the abstract thinkers from the concrete thinkers.
Who can tell me the difference between a number and a numeral?
A number is an abstract concept, while a numeral is a concrete representation (instance) of that concept.
When people are modeling (OOAD) the problem and solution space for a system they are developing, some can go straight to an abstract class model while others need concrete assistance, such as screens and reports and then the business classes are re-engineered from those. Both of these methods are equally valid – it’s all about the final product, not how you got there (quite the opposite of life which is all about the journey eh).
In our quest for achieving an assembly line paradigm for software development, abstraction is king. Anything concrete is tough to reuse. Development starts with OOAD and modelling, and so necessarily needs to be abstract, and should be done by someone familiar with the business domain to help identify reusable patterns from now and before.
This brings to me to the real point of this post. If I titled it ‘Multiple Inheritance (MI) vs. Single Inheritance (SI)’ no one would read it. After many years of debating MI vs. SI I start by stating: MI is like sight or hearing. If you have it and lose it its devastating, but if you’ve never it (born blind or deaf) had you don’t know what you’re missing.
Another word: orthogonal. Look it up. MI is oh so useful during the analysis and design phase – an astute analyst will pick out the 3 or 4 important orthogonal aspects to a business domain and, using MI, arrive at a succinct and elegant model. You might have things that go at different speeds and things that are different shapes. So if I want a fast circle I inherit from the ‘fast’ class AND from the circle class. A slow square from slow and square. The concepts of shape and speed are orthogonal. I so wish .NET had true MI, and I am willing for the compiler to spit at the slightest hint of a diamond pattern (ignoring object of course).
If you model and so draw diagrams using MI but cannot implement in MI, it gets real messy, so I don’t do it. I have to think different without MI and that bothers me. I grew up – spent my formative years with it – so having lost it hurt. And still hurts. I'm sure I'll get over it... one day.
Have a great weekend.
|
Normally there is a lovely ocean breeze blowing in Manly - home of expanz - but today it’s hot and the wind is out of the north west. So we’ve got the fan on. Every time it gets hot the global warming debate heats up, and then the IT world talks of ‘green IT’.
My take on green IT is pretty much my take on the current world of IT as a whole – we’re doing it wrong! OK, not wrong, but far less than optimal – we’re not being smart about it. We’re taking the safe shortcuts, not investing in anything but the very short term and certainly not thinking outside the square.
That’s why the eP is here. It’s different and it’s long term. And it’s very, very green (IMO of course). How? In many ways… It’s an assembly line, so it reduces development effort – less A/C, lighting and PC power for the dev team. The AppServer, being stateful, is far more efficient than a typical stateless model (for business apps) and so the server room uses far less power.
But most importantly, and what most people miss – fail to see – is that it can be used to build systems that are a 100% fit to a business and so optimize that’s business’s work flows. This of course is not solely the domain of the eP – this is an area of ‘green IT’ that is inevitably overlooked. The fact that a business’s IT systems can greatly alter their overall efficiency is clear and simple, but a significant portion of that is related to sustainability.
I love our ERP system and the clients we have – let’s do a short case study on one of them purely from a ‘green IT’ point of view. A distributor of organic food & drinks adopted our system and here are a few improvements we have made: first, the sales reps are now online with mobile devices, so rather than having to return to the warehouse, cradle & sync the orders, they leave their last customer for the day and drive home, not to the warehouse then home. Next of course is real-time visibility and accuracy of the orders, so the warehouse becomes more efficient in its stock planning and movements. Our forecasting module is so highly tailored for them that their wastage is greatly reduced (they do a lot of perishables that are seasonal) but they almost never short supply either. We save a lot of paper as well – taking POD electronically – signature capture on the mobile devices, using screen PDF’s and other reports vs. hard copy. Delivery route optimization is easy these days as well – here’s a list of addresses I need to visit, combined with a good real-time mapping and traffic system and you spend far less time stuck in traffic. Needless to say, mush of this data is captured and displayed on mobile devices, another area where the eP shines - makes it trivial to do mobile or cross platform development.
I believe that businesses adopting new IT systems should think more laterally in ways that a new system can improve and optimize their overall day to day activities, rather than taking an inflexible package and keeping the status quo. Continual improvement.
Green IT should focus more on the real world savings a tailored system can provide rather than simply reducing server CPU cycles.
And of course the eP makes it very practical to build 100% custom fit solutions that otherwise would be served by a one-size-fits-all generic solution where the business must change to fit the software.
BTW a lovely southerly wind just came through a dropped the temperature 10 degrees!
|
Blog Entry
|
I went on a run this morning and so had time to reflect on the past week or two. At some point I went through my Christmas checklist:
· drink too much – check
· eat too much – check
· have fervent religious debate – nope!!!
Now as an atheist I am finding it harder and harder to have good religious debates, even at Christmas. What is one to do, when one loves so much to argue fiercely have a calm open-minded discussion? Start one yourself! So here I go: is this thing called Software Development (or Software Production as the marketing guys would like) more Art or Science?
I want your opinion (no I just want an argument) but first you’re gonna get mine.
I’ve come full circle on this: at first I felt it was art, then decided it was probably science, but have since realized it’s a bit of both but more heavily weighted towards art. When I sit in Visual Studio, or Eclipse, or Blend, or Photoshop – I feel more of an artist with a canvas and a palette than a scientist with a lab and instruments. It’s creative. Sure there is some component of known algorithms and simple best practices, but it’s highly creative and inventive.
Whether you are writing device drivers for Linux, a 3D audio rendering engine for WoW, a cost-center P & L accounting report, or an online blogging engine GUI, it is a highly creative exercise. If it wasn’t, we’d get a machine to do it.
Which brings me to the other reason (apart from wanting to argue): this thing – Software Development – is being rebranded as Software Production by the marketing guys because we have invented the assembly line pattern for software as the manufacturing industry did for hardware. And cars and toasters are not developed on an assembly line, they are produced. So as a Software Developer Producer I feel that it is taking away my artistic rights and freedoms. Which as someone who knows that it is an art starts to feel uneasy about it.
Having sat on both sides of the fence – as tools/platforms producer and consumer, I know how important flexibility and openness is to a platform, both pragmatically and emotively to the developers (oh I just can’t call them Producers) using it.
So to the marketing guys – maybe ‘Production’ needs a second thought, and to the developers – your artistic freedoms are intact and in fact more highly regarded than ever.
Your thoughts?
That kid needs a good listening to…
A dear friend of mine, who I spend a lot of time walking, kayaking and of course talking with comes up with up the occasional gem, a real pearl of wisdom. For example, in reference to modern surfing competitions, he says ‘In my day, the best surfer out there was the one having the most fun’. Hmmm not sure if everyone will get that or not.
My favourite of his gems is this, in reference to an unruly or disruptive person: ‘That [person|kid|...] needs a good listening to!’ Instead of ‘sit down and shut up and listen – you need a good talking to‘, it goes ‘sit down and start talking – I’m listening – you must have something on your mind’. I have had the opportunity to use that a number of times, all with tremendous success. People generally become disruptive when they are bored or oppressed, when no one will listen to them, when they have no way to vent their thoughts. The internet and blogging of course, are modern remedies for that.
I needed that introduction, because, as you will have just guessed, I have something on my mind I need to get out.
In a moment.
Discovery vs Invention
First, let’s make sure we can discern between discovery and invention. Discovery is the uncovering of an existing truth, something consistent with the known rules and laws of math, science etc. at the time. Invention is using those known rules and either changing them or adding to them to come up with a new ‘truth’. Reading between those words is the idea that invention is dynamic and constantly open to reinvention.
OK, onto what’s on my mind, right after we answer a quick question. Was object-oriented software development discovered or invented? Restated: is OO technology a naturally occurring thing or is it man-made? If you believe it to be discovered, please leave a comment.
So what’s on my mind?
The ardent reader by now will have seen it coming – I have re-invented object-oriented software development methods. With a little help from my friends of course. Or maybe de-invented, as it is my opinion that when OO techniques first came to the fore, in the early 90′s, there was great promise that it would revolutionise software development, which it clearly has not.
OO history - have we gone the too easy path?
Those early days were focussed on simplicity – an object is simply data + methods, and that approach to be pervasive throughout – so your analysis and design is done in an object oriented way (OOAD) and then you program that way (OOP). In those days, tools & technology let us down; there were no useful OOAD capable modelling tools, nor were there any languages that were capable of properly implementing all of this.
Again, those who will claim that c++, Smalltalk, Eiffel etc. were all capable languages in the early 90′s are welcome to state their case. The closest IMO was a 3 1/2 GL called Gupta or later Centura SQLWindows. In 1993, it was a WYSIWYG windows designer and full MI OO language. Sadly, it was interpreted, not compiled, and more sadly, had no dynamic instantiation - it was GUI based, so you could create windows objects on the fly, but not abstract classes. As we moved through the 90′s, we got Delphi, Java and eventually .NET.
And don’t forget VB. Wasn’t exactly object oriented (lacked polymorphism) but it was easy to use and had some good stuff. It was the beginning of the end. Back in the 80′s, when we were doing Cobol CICS and IMS on IBM mainframes, we were basically programming abstractly – we were treating streams of bytes from 3270 terminals as formatted data and applying business rules and persisting that data.
Then along VB, Delphi and even good ole Gupta, and suddenly we could code directly against the ‘real’ data – on a form – we could trap OnLostFocus and apply formatting and rules to the contents of a textbox on a screen. Too cool! Too easy. Far too easy in fact. We had stopped programming abstractly, and coding rules directly in screens. At the cost of all reusability.
Separate Presentation and Business Logic!
Didn’t we hear that its best practice to separate the presentation layer from the functional layer? Coding OnLostFocus rules on a screen does not abide by that. But luckily some of us hung on to that abstraction. It was tough for a while, but we rode it out. The rest of the world went on to MVC, MVP, MVVM, n-tier architectures and so on. When .NET came along, we finally had a platform that had fantastic OO features (apart from MI – later on that!) and no real business application development platform or paradigm to cause legacy issues (as Java does with J2EE). I can see those ‘leave a comment’ buttons clicking furiously now…
Sticking with a model of OO simplicity – data + methods – and focusing on abstraction leaves you with a very simple 2-tier architecture: the business or model layer and the presentation layer. The presentation layer can change data or invoke methods of the business layer. All rules, formatting, persistence, everything happens inside the business layer, in a wonderful world of ultimately reusable components.
Inventing the Software Factory, Overcoming the Workshop pattern.
OK, here it comes – deep breath – at expanz we have invented the software factory pattern, as opposed to the workshop pattern, where the gains are greater than the gains of manufacturing assembly lines vs workshops.
As far as I know, nobody else has.
One of the signs of a true reusable architecture is code normalisation – every rule is embodied in a pattern and that pattern is a reusable component and so every discrete rule is only coded once, and reused. No ctrl-c/ctrl-v. Reused by simple declaration (and decorations I suppose), in a model. MDD to the max.
Extensible abstract types based DSL – no code gen!
DSLs are a wonderful thing, but why not make the DSL based on an extensible set of abstract Types, and why not allow a modeller or studio to fully understand the DSL, to bring it to the domain of the analyst rather than just the developer? Model Driven Development based on an extensible (uninhibited) DSL with no code gen, only declaration. With client side agnosticism - strap on a Silverlight, Windows Forms, Android front end without any code changes – the presentation layer is simply a subscriber to various data + methods of the business layer. Sound too good to be true? It isn’t, cause I’ve been building systems this way for literally decades.
Good to finally get that off my chest...
One of my favourites, and hopefully everyone’s: Testing. Why? Because we can sleep well knowing our software works and tonites upgrade will go smoothly. We tested it. I have so much to say here I don’t know where to start.
Testing as a cost factor
First, 'testing' itself is pretty big and has many variations, but is only a small part of the larger beast called Quality Assurance. QA is the process and governance that results in high quality output and the rest of the world seems to have embraced it rather successfully. If not, planes would drop out of the sky and buildings would collapse too often. Those things do happen, but infrequently enough to be negligible. However, software continues to be plagued by defects, even though today software teams have equal numbers of developers and testers. This means the software costs are quite high. What are we doing wrong? Or rather, what could we be doing better?
Other industries do way better
Quality Assurance in the software world has not been as widely adopted as standard practice as it has in other industries like car manufacturing as an example. QA would dictate that the development team creates a checklist of steps to ensure quality, based on their combined experience and the specific domain and environmental constraints of the software they are building. Sticking to LOB-style apps, this would invariably include design and code walkthroughs - and testing, no doubt. Hands up those who regularly do code walkthroughs… OK, those who plan to do it but just don’t get around to it… Right, I now see a few hands :-)
Testing starts early – with Design
Referring back to the guys in automotive, they know – if the cost for fixing a bug in design phase was let’s say $100, the cost for fixing the same issue during construction already sits at $1,000. If you have to fix it, once the Car has already begun shipping, you look into $10,000 for fixing the same mistake or way more, once the suing game has begun...
In SWD, design walkthroughs, as a group, serve the purpose of clarifying the design with a wide range of team members as well as testing the design for defects at the earliest stage in production after the requirements have been validated.
Apart from looking for dangerous/fragile code, these walkthroughs, either as a group or one on one, serve other purposes, too - such as learning new language constructs and patterns.
Catch22 - Are we too busy writing tests?
So why don’t we do early walkthroughs? Because we are too busy. Too busy testing! Writing unit tests, maintaining all manner of infrastructure to keep our tests relevant. We write too much code, and spend far too much effort in that thing called unit testing. It colours the way you code, and distracts you from the business problem you are solving. TDD - Test Driven Development - as an approach - is great; many times a developer will ask how do I know my code works? TDD answers that implicitly. But to drive all development based on unit testability might not be the best approach. Focus on quality, do the walkthroughs, stomp out bugs before they are written.
Appropriate Testing Methods
My theme of late has been to adopt a reusable component factory approach to software development. Imagine what that will do for quality! Sure it would reduce development time, cost and effort greatly, but it would also all but eliminate the need for unit testing, as all the units are prefab and fully tested. All that is needed is integration testing. Remember the 'test' to see if you were reusing code - any instance code was not reusable; everything should be declarations and decorations. But for now we still do write some instance/integration code, but that is all that needs testing.
Automated Testing – of course
And who should do this testing? Of course the developer needs to test their work (here is where TDD shines) but then a tester needs to test it. That tester is not a technical resource, but a specialised business resource who knows testing theory - boundary conditions etc. as well as the business domain. But really, a machine should be testing it. Test Development is like coding - it needs to be done - ONCE! Write once, reuse! Test once, reuse! A tester should be able to record their tests and have a machine play it back over and over, looking for errors – deltas against the last playback. Throw in a few Wobblies now & then to see how the software responds. Maybe even generate some crazy data and throw it at the software. Pretend to be 1,000 or 100,000 simultaneous users. All of this should be executed by a machine, not a person. A human needs to set this up, script it and record it once.
Unit Testing is Vital!
So what do we do with unit testing? We unit test our reusable code as much as possible. That’s where unit testing belongs - in the 'units' or components – not into assemblies. Unit Testing is vital and for best outcome, you will have to do intense unit testing for components. The adoption of truly reusable component based architecture will necessarily change the way software is developed and tested. This requires a mindset change, not a technology change. Aim for reusable componentry, unit test that componentry, and integration test the application and you will develop at much lower cost, in much higher quality :-)
That was my take, now over to you!
I think I better clarify my last post, as it was pretty out there.
An analogy to start with.
You are building a house, and the workers are pouring their own bricks, cutting trees and hand sawing them to size. Clearly that won’t work - will take far too long. But in reality, that is exactly how it used to be a hundred or so years ago. Today you can get a prefab home! Of course most are still built on site, using prefab components. But every house really is different and some parts need to be made to fit, or at least assembled in unique ways. Very much like software. So imagine if your builder used hand tools to do some of the heavy lifting custom work. You would be appalled. Now that doesn't happen in software development. We have terrific power tools at our disposal. But what we don't have is truly reusable prefab components. Most people of course will tell you they do reuse code, so I have a test, well a theory really, to see if you reuse code.
The test is this:
Any instance code you write is NOT reused. Simple. If you build an app, and you write 5000 lines of code, any line that is not a simple declaration (or decoration) is not reused. Truly reusable code would be all in library somewhere (of Types primarily) that you would assemble declaratively with some decorations/metadata as required - no code at all according to the test.
But as above, software is all slightly, subtlety different, so we generally need some code to assemble the components in our unique way. All of the 'plumbing' should be in the components, and silly things like horizontal scaling should be part of the infrastructure - you should not need to code for it.
If we now revert to the building analogy,
lets examine the roles and relationships between the architect and builder. The architect is the same as a BA, talking to you - the users - about what they need and want in a house. They examine the terrain and local laws and regulations, and draw up your house. The builder then interprets and executes these drawings as best they can. One of the main steps they do is to look for patterns, and similarities in those patterns and existing prefab components to make the building easier.
Its that approach we need to take when building software. Start analysing for patterns very early on - this will actually make the analysis easier, and make the artefacts smaller and more concise. No more copy & paste. A few pictures and a few words (with references to the patterns) rather than a book and lots of words The developers can then use their components to implement this quickly, adding a minimum of instance code, only as required. And wouldn't it be wonderful if the BA could actually do some of this work - rapid prototyping - themselves, and having those prototypes evolve rather than throw away. They should be able to as ...
...there is no code required - only declarations.
Is that any clearer on the concept of a software factory?
Tomorrow: everyone's favourite topic - testing.
While out shopping the other day,
I stumbled upon a stack of toasters on display – I don’t think it was a sale or special – just a display stand. $ 12.95. OK, to be honest, I don’t get out much (shopping-wise) but to retail a toaster for $ 12.95 is pretty amazing. Having fixed and cleaned various toasters in the past (the mister-i-can-fix-it deep inside us) I know what makes up a toaster. And I just cannot believe the price. This got me thinking and took me on a journey where I was ultimately able to refine my Christmas wish from yesterday.
I want as assembly line and componentry for software.
My journey began by decomposing the costs of the toaster (all balanced against the final quality) into buckets. Raw materials, labour, packaging, transport, stocking etc. What I realised was that the labour component has to be minimal. $ 12.95 doesn’t buy a lot of labour. This is clearly the result of some form of automation/assembly line and componentry where labour costs are minimal. Let’s call this the factory pattern. The other way of making toasters would be in a workshop, where the input is pretty much raw materials such as sheet metal. The inputs to the factory are a variety of prefabricated components and designs, which are assembled by hand or by machine. In a workshop, the design is executed on an individual basis, with components made from the raw materials as required. If toasters were made this way, you would need to move the decimal in the price a few spaces over; they would cost $ 12,950.00 as they would have a huge labour component. Now as time went on in a workshop, power tools of increasing quality may be introduced, and some componentry such nuts and bolts, which would reduce the labour and thus costs. So now our toaster is $ 1,295.00. Still pretty expensive. Some clever person then decides to take it to the next level – let’s design a bunch of reusable components, make a factory to produce 1000′s of sets of these components, and then some robotics to assemble them as required, into a few different models as sales forecasts predict. Clearly there is a serious investment here, in the tooling, design and preparation of this toaster factory, but in reality a large number of components (screws, nuts, springs) are already being produced for another item that they can reuse. So this is not imagination land – this is real – $ 12.95 toasters.
[Harsh realisation warning!]
The world of software development still runs on the workshop pattern.
We have not invented a software factory!
I actually find that quite embarrassing - I always thought IT folk were pretty clever. How come we haven’t copied the manufacturing world into the factory pattern?
It gets worse, too. I did warn you. Manufacturing consumes raw materials. Building software does not! I can conjure as many 1′s and 0′s in fancy patterns as I need at zero cost. So we in software development actually have more to gain from the factory pattern than manufacturing does! Rock bottom coming here (I warned ya!): imagine if you have made a factory to produce 2-slice toasters and then demand grows for a 4-slice toaster. You will need to redesign and implement some tooling to produce larger face plates and such. What can we do? Inherit! SidePanel4Slice : SidePanel2Slice { this.size = 2 * base.size; }. You get the picture. Manufacturing got a huge benefit from the factory pattern, orders of magnitude, and the world of software development has more to gain from the adoption of a factory pattern than manufacturing. It’s embarrassing that we haven’t done so yet.
It’s time to stop demanding bigger and better power tools from the vendors, and
demand a software factory.
Redmond, are you listening?
... read on - Inexpensive Software