The simplest way to put this is:
1)
Within a few years you are going to be programming in someone else's framework in a very limited capacity (frameworks are too expensive for one corporation to maintain properly)
2)
You are going to be helping write a framework but it won't be on behalf of any company - it will be for ALL companies
Software Adoption Options Businesses Now Have
Businesses traditionally have to make a choice when they bring technology in-house to solve a business problem:
They can build from scratch to solve their problem
-
This provides the MOST flexibility for future needs at the MOST cost now
They can buy an off the shelf product -
This provides the LEAST flexibility for future needs at the LOWEST cost now
They can buy an off the shelf product and customize it-
This provides the best of both worlds PROVIDED that the software is extensible where it is needed and costs for adoption and customization are low
That's how it used to be. Yet there are two OTHER fairly new options now:
-
They can apply an Open Source Framework and get a substantial level of flexibility at almost NO cost now-
They can create a picture, via MDA, and GENERATE the EXACT software they need for minimal cost and use that model that they create to MATCH their software DIRECTLY to their business process (so that their class models are directly understandable by the business, usually thought to be blasphemy, and not just the Software Engineers). There is a significant time investment here but the focus of the Software Engineer changes to one of understanding the business model vs. dictating what the company they work for can and cannot do with the software they create "because it's too inflexible" - no, the engineer who wrote it just didn't understand the business process fully (and probably enough stakeholders were not involved - which is common - the whole "just go build it and we can complain about what you gave us - but we weren't really involved in the first place routine").
I single these two out as different because THEY CAN BE USED TOGETHER.
The Open Source Framework, such as the Castle Project or the Transparent Framework, or both, used in conjunction with one another, are at the PSM (Project Specific Modeling) level of work. This can evolve or change independent of the Business Model because frameworks in general provide a level of "services" to any application that use them.
Oftentimes you need to know how to use this framework and invest the time to do so but you DO NOT necessarily need to understand them fully. This is a key idea I will address later in this post, but let me just say this: the level of knowledge about software engineering you need to have to write a framework is a lot higher than the level of knowledge you SHOULD need to have to use it (i.e. it should be do X, Y an Z and watch what happens). Anyway, here's what we know about software in general:
1. There is a Data Layer
2. There is a Business Layer
3. There is a Service Layer
4. There is a Personalization/Security Layer
5. There is a Presentation Layer
A good framework lets a business focus on JUST the Business Layer - i.e. how to get their job done at the lowest possible cost per unit (to maximize the amount of money going to the shareholders as we discussed previously).
A good framework also lets you extend the OTHER 4 layers via applying simple patterns of code (and handles all the wiring for you). So for example, the Monorail sub-project in the Castle Project framework uses an MVC architecture that allows you to CREATE new pages just by creating a new class, inheriting from a base class and then overriding a some kind of rendering method (you still need to populate the controls on the page yourself - which Transparent when used in conjunction, abstracts for you).
Finally, a good framework DOES NOT make assumptions about how you are going to use it - it tells you what you can and cannot do and hopefully allows you to pick and choose what parts of it you do and do not want. It also is constantly evolving based on user input (which is why communities are a better place for these kinds of things - as they involve frequent release cycles and almost constant feedback which is very difficult for even a software company to manage).
Now, if the framework you use is constantly evolving to provide new features to you, the business model is just the opposite. It evolves as you understand and redesign your core business classes around your new understanding. Although it does need to be frequently evaluated for internal consistency, once it is formed it CAN be relatively stable for a time.
Unfortunately the thing that throws a monkey wrench into this perfect picture is programming languages and standards. As these change often you have to take your whole application and re-write it in some other language or you get "application incompatibilities". But what you CAN do in this situation is to just regenerate your business model in the target language and go and find a compatible framework. This is the concept underlying POCO's (Plain Old CLR Objects) as opposed to building RICH business objects. If you want RICH then wrap the POCO - but I am getting into design here and I do not want to do that.
The point is that this whole ugly "increase shareholder value legal obligation of Corporations is actually your friend" - IF you design your applications from this perspective I am advocating here because it FORCES you to design well - the only caveat is that the corporation MUST measure profitability long term and not just short term - and that ALMOST goes against the increase shareholder value mandate...however, it is your worst enemy if you do not design your applications from the perspective I am advocating.
So What Kind Of Developer Are You?
If you are "from scratch" developer and start with a VS.NET blank slate every time you go to code - like you are ready to free your mind, be creative, and draw on a fresh sheet of paper, this next section is for you. Do you like Design Patterns - the Gang of Four, often talk about architectural trade-offs of applying design patterns, attend user-groups, favor Eric Evans Domain Driven Design (actually get excited about this stuff)? Are you really interested in quality and applying true proven software engineering practices to your work? Do you model new architectures in your sleep and grab a notebook and scribble how you can apply a decorator with an MVC controller and an Extender to get an extensible UI framework? Are you one of those people that cares about the code you write? Do you look around you and just say "I can apply a design pattern here and clean up all this bad code"? Do you also say why won't THEY give me the time to do a "black-ops" project, under the radar of the project planning folks in a "refactoring window" with some of my peers and get us out of this sea of bad code? Don't they care that it takes us 5 times as long to get anything done because everything we do breaks brittle code?
You my friend, are like me. You really want to "improve" the environment that you are in. That's a BIG problem. Shame on you :) Unfortunately, that kind of thinking does not USUALLY belong in a corporation - they can't afford you AND make a profit - so you MAY want to re-evaluate why you became a software engineer in the first place. Or let me put this another way, they can't afford you and make a SHORT TERM profit for their shareholders.
Why, you ask? Well, I had to learn this one the hard way:
There is a substantial cost to ideas
This is where the worlds of the Pragmatist (who is about being effective) and the Idealist (who is about seeing a vision) collide. Actually, we have BOTH aspects in each of us but corporations encourage the pragmatist (even the blind pragmatist) but spend lots of money to get the idealists only to put them into a place full of pragmatists and purely pragmatic - risk avoidant thinking (or process heavy environments, in an attempt to manage risk) - but that is a different blog (it's also one of the practices that go against the corporate legal mandate because they are frivolously wasting shareholders money and should be taken to task for it - how much did YOU with all your idealistic vision cost? and here they are WASTING resources).
Consider that you may be in design pattern oriented thinking and your manager last programmed using COBOL. First of all, they are not going to trust you - so you have to build up a lot of "respect capital" to even begin to float ideas as earth shaking as design patterns. You then have to prove you can dig a ditch their way (yes, I know they didn't hire you to dig a F#$%#T#@ ditch - just dig the ditch). So by now, 3-5 years have passed (if you dug the ditch), you have proven yourself on some projects, and you get your opportunity only to be told that your job is being outsourced to India (and they should - you wasted their money by NOT sharing your ideas or sharing them - I get so confused about this point). So you never get around to that design pattern that was going to revolutionize their environment (or worse you actually believe that you CANNOT do that - when you most certainly CAN). Oh, guess what? You get to start all over again - lucky you :)
What you may not realize is that since ideas cost time and money for people to understand them - and if you are a poor communicator you are really screwed - you end up fighting a POLITICAL battle when you are NOT a political animal. This has a LOT of implications. For example you have to "champion ideas" so you better be a really good orator - that's why you decided to lock yourself in a dark room with a computer right? You were good at public speaking? Masterful at the art of persuasion? Not likely. You are just damn good at what you do. However, BECAUSE you made the attempt to float an idea (I pity those that never at least try to float an idea), because you did that, you actually, unbeknown to you, have invoked the wrath of the increase shareholder value legal mandate of the corporation.
YOU are costing the company money for having an idea, taking up people's time on the clock with your idea (so you should share ideas only in your off time :)) and trying to make a difference and BE a stakeholder in that environment (in other words, care)!
So there is a substantial deterrent in corporations that do not rely on Agile processes, where risk is minimized by shorter release cycles instead of processes designed to manage risk by taking away your initiative.
ALL corporations, unless they follow agile processes, MDA OR have software as part of their core competency - and everyone right up to the president of the corporation wholeheartedly embraces that as a key differentiation strategy of the corporation, have this kind of environment.
So most likely, you are working for a company who has just added your "pursuit of what is right" to the cost of selling their widget and if you AND your team can't justify WHY what you are doing will benefit the company - have fun. I personally did not spend the last 10 years of my life doing software engineering because I really wanted to go into politics. In fact, MOST software engineers I know HATE politics - but are of course, very opinionated about it.
To my credit, I now have learned the hard way what not to do and hopefully you will take away some of that knowledge by reading this blog. I now KNOW how to work in Government and the Private Sector and with companies that are in COBOL - Procedure Oriented mindsets and so on. They were some hard lessons learned, let me tell you.
That substantial deterrent also impacts your family, because it affects your financial well being - so you better NOT have ideas - or share them unless you can point to a graph and say:
"see here - this is where by doing this design pattern we shave off X amount of loading time and that translates into .50 cents per transaction and therefore with 10,000 transactions a day this improvement saves $5,000 a day!"
That is exhausting - to make change you have to be a business analyst, orator, programmer and a salesperson. Lucky you.
Any good businessperson worth their salt is going to have you justify to them how what you are doing affects the bottom line. Yet an alternative way to handle this is to do the change and SHOW THEM the results - but for that you need smaller release cycles (and you really need those smaller release cycles because THEY ONLY THINK THEY KNOW WHAT THEY WANT). If your stakeholders only saw that it made a 30 cent improvement and the project was for a 50 cent improvement per transaction then rewrite it - only agile organizations operate this way however. In most organizations, you need to justify it, it has to get approved by 5 people and then you can apply it to a DEVELOPMENT environment - that's the whole CMM Level 3 - whole lot of disconnected waterfall documentation - type stuff - it's also the reason the Dot Coms, in the Dot Com Boom, demolished the big 5 Consulting firms because by the time that the Big 5 Consulting firms got the approval for the 5th person, the market had moved. It's also why the Linux Open Source types have rocketed past the existing software development companies who sat on their laurels for a while thinking that their market dominance could not be challenged.
So bottom line, having ideas exposes you to risk - If you are someone with a lot of ideas then you need to know how to channel them and Corporations are NOT the place to find out how to do that.
The only exceptions I have seen to this are organizations that:
1) Embrace Agile Development
(shorter iterations allow you to "try" things)
2) Embrace MDA
(because the business is looking at you as MORE THAN just a engineer - your modeling and understanding of what dumb computers need to know to do things leads you to be precise and this is necessary in assisting at defining a model)
3) Derive their core competency from the work you do
Now, #3 is a little tricky and I really don't trust it. Because it is NOT ENOUGH to have the organization JUST derive their core competency THEY HAVE TO UNDERSTAND THAT THEY DO. I had one company I worked for that hired on a new financial person and a new director of IT, who did not understand that the SOA, BizTalk, aggregation architecture we had implemented WAS DIRECTLY TIED TO our core competency and therefore sought to outsource it (of course :) - I now know why my architectural mentor at that company became so cynical - he took things too personally - so did I at the time). Yes, it was retarded to do so, as they saw things as "too complex". Granted, there was some unnecessary complexity there but we were not dealing with Microsoft Access here either - this was a mid-size company that was RUNNING off of this architecture and that had phenomenal growth from a start-up, integrating all the "stove pipe" systems and the people who ran those systems, but who never actually talked to each other (yet dysfunction manifests in IT), BECAUSE of it. All we needed to do was reduce some of the complexity and not throw the baby out with the bathwater. So what I am trying to say is #3 implies a lot of things and if you do end up working for a company in that category make sure that the commitment to "a world class software team" is IN the company mission statement - and if the IT Director leaves - get ready to leave too - IF you really care about this stuff that is.
The short answer here as to why you should care because everything is moving towards the Framework based approach where you just make SMALL code changes to a pre-existing infrastructure that somebody else needs to maintain - so they don't need you full time in a programming capacity.
Even SharePoint, a product, is actually 1) a product 2) a framework and 3) a platform. So this is not really in the category of buy and customize (such as Oracle is), because it is all inclusive. You need to really determine what kind of developer you are and very quickly plug into that level.
If you are content just working through existing extension points, then get as much of that work while it is still available - you should not need a lot of software engineering experience to do that (but also that means your job can be easily outsourced and before long some smart person in Open Source will write a program to write your code using reflection).
However if you want to actually WRITE quality software we are fast approaching a time where that WILL NOT be able to be done in all but a few corporations (the corporations that have the vision to see its benefits, can wrap their business processes around customized software, adopt agile, adopt MDA and take software engineering seriously) - everyone else should just go get SharePoint - (or Drupal for the Open Source community), and leave the real software engineering to the people who want to do it.
As always, I look forward to your feedback (and the links are on the right).
