If you can accept the idea of a Software Architect the idea of a maintenance architect makes sense. However, in the circles I travel in there is actually some resistance to the idea of a software architect at all.
This resistance is usually driven by a misrepresentation of what the role should be. An architect role should be a mentor and guiding hand in the business' technology related initiatives. The architect should not be about the business of "bossing around" developers.
The Maintenance Architect role makes perfect sense if you look at what the job would be involved in doing. Even in the absence of a Software Architect a Maintenance Architect could still make sense. The Maintenance Architect would basically herd all the "cats" (developers) in a direction. The M.A. would steer a Perl shop (for example) toward exposing their CGI as distinct REST services that could then be fronted with Flex for example. In time you could whittle away at the CGI with Grails applications or another technology that fit your new technical stack. Eventually after a great number of iterations you would be transitioned to the new technology. You would "cook the lobster" if you will... slowly transitioning the shop to one of the 21st century software stacks.
It would be a long sighted goal and it would take a long sighted person to pull that off. The guy you'd look for would be someone with patience, endurance, and commitment. They would have to be a stern guiding hand yet be flexible enough to wait out the many development cycles to see their plan fulfilled. Not an easy order to fill and not a common person to find.
Showing posts with label Software Engineering. Show all posts
Showing posts with label Software Engineering. Show all posts
2008-08-07
2007-12-12
BPM is mostly wrong
In response to:
The Seven Fallacies of BPM
Mentioned in "The World is Flat" book Business Process Modeling systems were supposed to deliver businesses with a glorious future in which Business Analysts could model processes without the need for a programmer's intervention.
The problem is that the modeling process itself is core to application development and utterly central and important to a properly functioning application. You would no more have a Doctor design your house than you would a Business Analyst design a Database or Application. The Doctor is concerned with much different sets of concerns than an Architect is. The Doctor is concerned about wheel chair access and ventilation while the Architect is concerned with whether the building will stand up to a storm or earthquake.
While both a Doctor and Architect could collaborate to create a house you would not have a Doctor build a house unassisted. If you did you would be inviting disaster. And, you would be offended if I suggested that you take dietary advice from an Architect. That would be absurd.
It is true that many small projects are released without the help of a specialist. I'm certain many buildings are built without an Architect... and many diseases are overcome without a Doctor. But, you should ask yourself what your project is? Are you trying to produce a professional product or are you just "hacking around" looking to make something that works? Do you want to create "professional" systems or just "hobby" systems. Are you producing a reliable car or are you creating a dune buggy in your back yard?
If you can honestly answer that the project you are producing is a "buggy" then by all means forgo the professional assistance ... but don't kid yourself... that's not a Toyota you've got.
The Seven Fallacies of BPM
Mentioned in "The World is Flat" book Business Process Modeling systems were supposed to deliver businesses with a glorious future in which Business Analysts could model processes without the need for a programmer's intervention.
The problem is that the modeling process itself is core to application development and utterly central and important to a properly functioning application. You would no more have a Doctor design your house than you would a Business Analyst design a Database or Application. The Doctor is concerned with much different sets of concerns than an Architect is. The Doctor is concerned about wheel chair access and ventilation while the Architect is concerned with whether the building will stand up to a storm or earthquake.
While both a Doctor and Architect could collaborate to create a house you would not have a Doctor build a house unassisted. If you did you would be inviting disaster. And, you would be offended if I suggested that you take dietary advice from an Architect. That would be absurd.
It is true that many small projects are released without the help of a specialist. I'm certain many buildings are built without an Architect... and many diseases are overcome without a Doctor. But, you should ask yourself what your project is? Are you trying to produce a professional product or are you just "hacking around" looking to make something that works? Do you want to create "professional" systems or just "hobby" systems. Are you producing a reliable car or are you creating a dune buggy in your back yard?
If you can honestly answer that the project you are producing is a "buggy" then by all means forgo the professional assistance ... but don't kid yourself... that's not a Toyota you've got.
2007-09-10
Engineering for the Web
"What ever happened to Web engineering?"
This just feeds my assertion that the dot-com boom was the worst thing to happen to software engineering practice in computer history. The bust was harrowing and the good and bad alike were cut down, but, the boom is what fostered the legacy of bad practice and unrealistic expectations that we have to fight today.
The new movement to introduce engineering principles back into web development shops should be unnecessary.
"The problem is, strictly separating designers from developers has resulted in a Web built by people frightfully unaware of the standards and technologies required to make it go. Most Web pages today extend well beyond the limited scope of HTML, and a good many of them bring together a "pure" programming language like Java or C++ (you know, real code with control structures and variables and stuff) with healthy chunks of JavaScript, PHP, HTML, CSS, and oh, don't forget, XML."
This just feeds my assertion that the dot-com boom was the worst thing to happen to software engineering practice in computer history. The bust was harrowing and the good and bad alike were cut down, but, the boom is what fostered the legacy of bad practice and unrealistic expectations that we have to fight today.
The new movement to introduce engineering principles back into web development shops should be unnecessary.
2007-08-30
Where do we go now?
Last year Google dropped their SOAP API and today they announced that You Tube launched a new API. That got me thinking.
This Google-hate-on-SOAP was covered at my NFJS conference, the reason cited was the strong typing issue in SOAP.
As I've written SOAP services I've found that you get tied to the POJO or DTO object that you write. This is okay if you are a small shop and you control both end points (read "me") but it becomes a problem when you have 3rd parties working with your services. The problem gets pretty bad after a half dozen versions...
What to do? Well, apparently if you ar a multi-billion dollar organisation you do this:
Google Data API
Which is the google answer to the problems in SOAP. Now if you aren't Google you could do a few different things... you could just use the GData libraries... reverse engineering your own back end for them since they don't release the server side code for this stuff... or you could do what was suggested by the ThoughtWorks consultant at NFJS... you _could_ do loosely typed SOAP services.
Huh?
A loosely typed soap service is a soap service that takes an XML document as its only parameter. That means your method names change from
to
which doesn't seem all that profound from the method signature but it does introduce a bit of pain. The pain introduced is in the necessity of implementing a strategy pattern...
Strategy Pattern
... in this case you would have a collection of parser or processing engines that would return a result document. The particulars on which result and how we get it are determined by the concrete implementation.
But even this seems a little hackish. But, take a look at this:
stone mind on rest, groovy, and other things
And, I think this sums up where my mind is headed. After spending a lot of time hacking around in the J2EE playing grounds where there are all kinds of horribly stodgy things, conflicting ideas, and just plain crazy ideas... I've come away with a couple of golden nuggets I'll share with you and where I think the technology stack will be in three years.
I don't have an affinity for Python. I don't have a particular love of plain old Java either, but I do have a yen for many tools that Java lovers have. I love their XML handling tools. I love entity manager based persistence engines.
I think Groovy is going to be a major player for shops like mine where we have a need to work with Java and other tool chains too. We need to get things done quickly but we also need to be a bit stodgy at times. Groovy means we can bring in the Java "enterprise" stack without choking on the "enterprise" part.
Grails helps a lot too. It is rapid application development, MVC, Hibernate3, and Spring in a box and you can crank out applications in it once you know what you're doing. The trouble is getting to know what you are doing if you are a PHP programmer. (which we can find... but not JSP programmers)
I think there needs to be a few more Grails books. But I'm adept at figuring things out and I can get by without a book. I'm impressed that Grails has a DWR plugin so that means the best of all possible worlds.
I am looking forward to getting things done with Java, Groovy and Grails in the next couple of months. I think Groovy will take off in the next few years and legitimize the dynamic language on the Java stack. Groovy is just variant enough off of Java to improve development cycle but close enough to Java to keep the barrier to entry low.
This Google-hate-on-SOAP was covered at my NFJS conference, the reason cited was the strong typing issue in SOAP.
As I've written SOAP services I've found that you get tied to the POJO or DTO object that you write. This is okay if you are a small shop and you control both end points (read "me") but it becomes a problem when you have 3rd parties working with your services. The problem gets pretty bad after a half dozen versions...
What to do? Well, apparently if you ar a multi-billion dollar organisation you do this:
Google Data API
Which is the google answer to the problems in SOAP. Now if you aren't Google you could do a few different things... you could just use the GData libraries... reverse engineering your own back end for them since they don't release the server side code for this stuff... or you could do what was suggested by the ThoughtWorks consultant at NFJS... you _could_ do loosely typed SOAP services.
Huh?
A loosely typed soap service is a soap service that takes an XML document as its only parameter. That means your method names change from
@WebMethod
public User getUserByComplex(ComplexObject complex)
to
@WebMethod
public XmlDocument getUser(XmlDocument xml)
which doesn't seem all that profound from the method signature but it does introduce a bit of pain. The pain introduced is in the necessity of implementing a strategy pattern...
Strategy Pattern
... in this case you would have a collection of parser or processing engines that would return a result document. The particulars on which result and how we get it are determined by the concrete implementation.
But even this seems a little hackish. But, take a look at this:
stone mind on rest, groovy, and other things
And, I think this sums up where my mind is headed. After spending a lot of time hacking around in the J2EE playing grounds where there are all kinds of horribly stodgy things, conflicting ideas, and just plain crazy ideas... I've come away with a couple of golden nuggets I'll share with you and where I think the technology stack will be in three years.
I don't have an affinity for Python. I don't have a particular love of plain old Java either, but I do have a yen for many tools that Java lovers have. I love their XML handling tools. I love entity manager based persistence engines.
I think Groovy is going to be a major player for shops like mine where we have a need to work with Java and other tool chains too. We need to get things done quickly but we also need to be a bit stodgy at times. Groovy means we can bring in the Java "enterprise" stack without choking on the "enterprise" part.
Grails helps a lot too. It is rapid application development, MVC, Hibernate3, and Spring in a box and you can crank out applications in it once you know what you're doing. The trouble is getting to know what you are doing if you are a PHP programmer. (which we can find... but not JSP programmers)
I think there needs to be a few more Grails books. But I'm adept at figuring things out and I can get by without a book. I'm impressed that Grails has a DWR plugin so that means the best of all possible worlds.
I am looking forward to getting things done with Java, Groovy and Grails in the next couple of months. I think Groovy will take off in the next few years and legitimize the dynamic language on the Java stack. Groovy is just variant enough off of Java to improve development cycle but close enough to Java to keep the barrier to entry low.
2007-08-21
Sick today & Software Engineering Ignorance
... felt it coming on yesterday. Definitely sick today. For light reading:
Software Engineering Ignorance.
What is the world coming to? I'm really surprised that people are willing to ignore thirty years of accumulated wisdom.
Software Engineering Ignorance.
What is the world coming to? I'm really surprised that people are willing to ignore thirty years of accumulated wisdom.
2007-07-23
Agile Test Driven Design Process Proposal
I am proposing the following software development pattern to our team next Monday. The idea is to create an environment where testing comes first, expresses business rules on a one-to-one and onto manner (borrowing a term from set theory). If a design element does not fulfill an acceptance test it is not developed. And, all development starts at test and ends in code.
- Business expresses a need.
- Business Analyst determines a use case.
- Software Engineer and Tester collaborate to create an acceptance test using business terms that will map down to classes or class structure. They use fitness to do this. Driving down from fitness tests Unit tests should provide 100% coverage. Code that is not covered should either get covered by a new acceptance test or get deleted. All tests of unimplemented code should fail on unimplemented method calls or null classes... in fact some initial tests will fail to compile since the classes simply don't exist. All tests that fail should represent one functional deliverable.
- Software Engineer partitions work between development teams. Teams fill out classes so tests pass. Weekly reports show the teams' progress. Each test maps onto each business need... as business needs get filled the number of passed tests increases. The ratio of passed to failed tests indicates the percentage of completeness of the project. Projects can go backwards... this is not good but it is possible.
- Once a number of passed acceptance tests reaches 100% the project is done. The version is branched and marked as a release and the software is shipped. Then the process starts over.
Subscribe to:
Posts (Atom)