Maybe I like Static (and Strong) Typing because I grew up on Pascal, Modula-2 and ADA and like them.
Maybe it's because I took courses in compilers and studied type checking a lot.
Maybe it's because I really like the principles behind "Design By Contract".
Maybe it's because I like to find as many bugs at compile-time rather than run-time.
Or maybe it's because a "real" Object-Oriented language *HAS* to have types - by definition - therefore I'd like to check them as early as possible (compile-time).
The two groups of people I see liking languages that remove type-checking (at compile time) are
i) Uber-developers and uber-geeks: To them types just get in the way and frankly they write code so well that runtime "ClassCastException" occurrences are rare. They practically have type-checking at code "write-time", forget compile time :-) These are the folks who love Smalltalk and Ruby.
ii) The lazy developers. They see this current trend towards less type checking and think - "Yeah if I didn't have to worry about types my life would be easier".
For both groups the reasons are the same - making their lives easier - but the end product is different. For the uber-developers - they'll produce more code in less time, with quality just as good. For the other group - the end-product is worse - but hey THEIR lives are easier.
For those of us living in a world with teams populated with a broad spectrum of skills and motivations, I don't think languages like Ruby are going to make the mainstream of core application development.
I have no experience with either Smalltalk or Ruby (flame on!) but this all smells like a "Silver Bullet" sales pitch to me. But most people agree Ruby is no silver bullet.
See also some thoughtful arguments here and here.
Frankly, my interest was piqued when I saw the buzz about Ruby on-line, but the minute I heard "run-time type-checking", I went back to reading and thinking about Java! :-)
Now I'm not saying that "type-checking-at-compile-time" languages are always better than ones that would rather do it at run-time - I'm just saying the productivity of using Ruby / Smalltalk isn't guaranteed for the average developer or team. Just because the top decile of programmers like Ruby since it makes them more efficient doesn't mean it's a great fit for the rest of us who are "mere mortals" :-)
Similarly I don't think Java is the ideal language for all developers- some know and love Cobol, some C++; personally I fell in love with Java in 1998 and she's been very good to me ever since.
Side-note: FYI I must say that I really *DO* like both Perl and Javascript - both of which use dynamic typing, but then again I don't find myself writing thousands of lines of either - usually it 60-100 lines for some web / scripting functionality and I'm done.
For more on Strong / Dynamic typing see Wikipedia here.
A great quote they have is:
"In general, smaller or nimbler projects seem to better fit freer typing, while formal, larger projects that rely on divisions of labor (programmer, analyst, tester, etc.) appear to work better under heavy typing"
What do you think? Am I being a curmudgeon? Am I just getting too conservative in my old age? :-) Is there more to Ruby/Smalltalk than run-time type checking? Hopefully for those betting their careers on it - there is!
10/23/06
My Favorite Java Developer interview questions
Over the past 5 years I have screened and interviewed well over 50 people specifically for the role of Senior Java developer. Over that time I've honed my skill at asking the "technical interview" questions and leaving the fuzzier "soft skill" interview questions to others.
I do this mostly as I don't get enough time to interview someone - 1 hour is not nearly enough time to get to know a person's technical and soft skills. Also my focus tends to be on the technical questions since these questions allow for a good "Apples-to-Apples" comparison which leaves less room for mistakes.
Over these years I've created a 16-page spreadsheet of questions including basic Java, JDBC, JMS, EJB, Struts, SQL, HTML/Javascript, XML, Open Source etc.
So here are my favorite questions to ask - I have plenty more, but these ones I've found really useful - often for surprising and unexpected reasons. Sometimes the answers aren't as important as the attitude taken in responding.
The "obvious" side - Technical Q&A
Q 1: When does the JVM do Garbage Collection?
This is kind of a trick question as the answer is really "it depends".
REALLY WHAT I'M ASKING: Do you really understand the language you use almost every hour of every day? Do you know what's important and what's not?
NOTE: The non-verbal response to this is almost as important - it catches people by surprise quite a bit - but for two different reasons. One response style is for those who don't know the answer. The other is for people who know the answer but are wondering why I'm asking.
Q 2: What's the difference between an interface and an abstract class?
REALLY WHAT I'M ASKING: How good are your oral explanatory skills? This is a somewhat complex topic under interview pressure.
NOTE: Amazing how many times this trips up so-called Java experts.
Q3: Name the different types of JDBC drivers?
REALLY WHAT I'M ASKING: Do you understand the tools you use everyday especially when it comes to performance
NOTE: Those who've really been involved in, or care about, performance tuning really understand their JDBC driver inside-and-out and will know a Type 1 from a Type 4.
Q4: How do I find out how many rows there are in a ResultSet?
REALLY WHAT I'M ASKING: Everyone's done this or should have, but what's the best way?
Frankly sometimes there are no short-cuts.
NOTE: Often really good Java developers are hoping I'll have a short-cut / high-performance answer to this. Unfortunately there is none (that I know of). However the "interest" they display is a good sign because it means they care about doing things better / faster.
Q5: Does Java use pass-by-value or pass-by-reference semantics?
REALLY WHAT I'M ASKING: Again, do you really understand the language you use almost every hour of every day?
NOTE: Amazing how many people get this wrong - even people who claim to have passed SCJP or even those working at Sun for years!
Q6: What does "NULL" mean in SQL?
REALLY WHAT I'M ASKING: How is data (or the lack thereof) represented? Do you really understand relational databases?
NOTE: It's amazing how many people very familiar with databases and/or are Comp Sci graduates who don't really know this.
The not-so-obvious side
What happens when you don't know the answer? Do you bluff or just admit it? Are you interested to learn and grow? Do you get angry and say "Why would anyone want to know what?". I've seen all kinds of interesting responses here.
I'm also looking for elements of developer-to-developer 'rapport' - interviewer and interviewee probably faced the same issues at different times in different jobs and that shared experience can help build some initial camaraderie.
Also important are the questions the interviewee asks
- What's your Source-code Control system & your IDE / Tool-set
- What are the Team dynamics (individual silos vs. more "group-oriented" work)
- What's the Release schedule look like?
- Hours worked each week?
- Company's financial state and outlook?
All these are good signs.
What I don't ask
It may surprise some folks but unlike some technical interviewers I don't ask the quasi-legendary puzzle questions. One of the reasons for that is that I find I don't do that well on those questions myself without lots of practice. But more importantly I don't find the exercise indicates much about a developer's skills per se. They're all too reminiscent of the SATs and GRE exams which don't really indicate other key aspects of a person's personality e.g. persistence, motivation, inquisitive nature etc.
Probably the biggest point of all . . . .
Most of what a developer does everyday is not abstract problem solving (I can hear a collective "WHAT!?!?!?") - but think about it - you really spend a lot of time figuring out how to implement the solution to an abstract problem? There are always people around who can help you find the (abstract) solution but few people who will implement it for you!
For example - let's take a requirements for a high-performance message-based system - which listens to stock price changes and updates a database. I might already know the solution will need multiple threads, a thread pool, a JMS provider etc. but . . .
Should I write my own pool or is there a good package I can re-use (JDK 5.0 has some awesome utilities for this)? Also . . .
That's a lot of questions and the answers to these questions are rarely abstract - that is they are not algorithms independent of the implementation. The solutions depend very much on whether you are using C, C++, Java or C# and hitting Oracle, Sybase or MS Sql Server, using MQSeries, Tibco or Sonic MQ? These are nitty-gritty implementation issues which depend more on your experience and willingness to investigate than on abstract problem solving. Even the JDBC and JMS APIs don't obviate the need for understanding the underlying database / messaging platforms.
Above-all, I think the most under-rated (and under-interviewed) attribute of a developer is persistence rather than problem-solving. Will you stay plugging away at a problem, trying different angles, working with different people until you can solve it? Will you write a good set of unit tests before declaring victory? Will you trawl through Google to find an answer when your JDBC driver doesn't behave as expected?
So for me, often the Java/J2EE questions I ask (e.g. nitty gritty details of JDBC drivers) are really about finding out how deep / far you have gone to solve common issues (e.g. error handling, resource cleanup, performance tweaking etc.).
Final Note
I've been quite disappointed lately about how some people shamelessly pad their resume. Now I'm not talking about cases where a person says s/he has used JDBC and doesn't know it inside-and-out. I'm talking about people who, for example,
i) Claim they are "expert" in MQSeries but don't know the difference between a Channel and a Queue!
ii) People who claim 5 years of JDBC but then can't tell me the different types of Statement objects!
I'm talking blatant exaggeration.
Finally then there are the needles in the haystack. The people who just have the "gift" - they're gonna kick ass and probably teach you as much as you can teach them.
When you find that person, all that effort is worth it.
BTW I'm sure interviewees have similar bad stories about bad, disrespectful or dishonest interviewers - I know I have - and I would love to hear them or other good / favorite interview questions!
Compare and Contrast
Just recently I read Joel Spolsky's updated Guerrilla Guide to Interviewing (version 3.0)
and although I respect Joel quite a bit I was quite surprised that there were a few specific details I disagree with him on.
For example he says "If even two of the six interviewers thinks that a person is not worth hiring, don't hire them . . . I would probably allow any senior person to reject a candidate but would not reject someone just because one junior person didn't like them."
Frankly I disagree here - if you hire this person and one of your developers gave the person a "No Hire" you may have gained one employee but "lost" another. I've had managers hire developers over my "No Hire" recommendation and I found it very frustrating - especially so when the person turned into an unmitigated disaster.
Perhaps Joel would think of me as a "Quiz Show Interviewer" - the things I'm after might seem like trivia but I feel they are very important - understanding how to release resources, how JDBC works, how to use threads etc.
In particular I 100% disagree with the idea that "software teams want to hire people with aptitude, not a particular skill set.". Huh? Frankly I have a particular job that requires a certain skill set and really don't have much time to teach a person that skill set. True, they definitely need an aptitude to learn - but people with strong skill sets have strong skill sets for the most part BECAUSE they have the aptitude to learn. I'm not jumping from Java to C# or Ruby any time soon so I need people with good/great Java skills!
It takes years to learn good exception handling, resource releasing etc. in Java and I don't have time for someone to learn that (as a Senior Developer) on my or the company's dime.
I agree with him, though, that you should look for people who show passion, can explain things well and exhibit leadership potential.
In the end we're both after the same thing we just have different ideas (personal conceits) about how to get there. I'm still learning how best to interview and after writing this and reading Joel's article I definitely have some things to think about.
I do this mostly as I don't get enough time to interview someone - 1 hour is not nearly enough time to get to know a person's technical and soft skills. Also my focus tends to be on the technical questions since these questions allow for a good "Apples-to-Apples" comparison which leaves less room for mistakes.
Over these years I've created a 16-page spreadsheet of questions including basic Java, JDBC, JMS, EJB, Struts, SQL, HTML/Javascript, XML, Open Source etc.
So here are my favorite questions to ask - I have plenty more, but these ones I've found really useful - often for surprising and unexpected reasons. Sometimes the answers aren't as important as the attitude taken in responding.
The "obvious" side - Technical Q&A
Q 1: When does the JVM do Garbage Collection?
This is kind of a trick question as the answer is really "it depends".
REALLY WHAT I'M ASKING: Do you really understand the language you use almost every hour of every day? Do you know what's important and what's not?
NOTE: The non-verbal response to this is almost as important - it catches people by surprise quite a bit - but for two different reasons. One response style is for those who don't know the answer. The other is for people who know the answer but are wondering why I'm asking.
Q 2: What's the difference between an interface and an abstract class?
REALLY WHAT I'M ASKING: How good are your oral explanatory skills? This is a somewhat complex topic under interview pressure.
NOTE: Amazing how many times this trips up so-called Java experts.
Q3: Name the different types of JDBC drivers?
REALLY WHAT I'M ASKING: Do you understand the tools you use everyday especially when it comes to performance
NOTE: Those who've really been involved in, or care about, performance tuning really understand their JDBC driver inside-and-out and will know a Type 1 from a Type 4.
Q4: How do I find out how many rows there are in a ResultSet?
REALLY WHAT I'M ASKING: Everyone's done this or should have, but what's the best way?
Frankly sometimes there are no short-cuts.
NOTE: Often really good Java developers are hoping I'll have a short-cut / high-performance answer to this. Unfortunately there is none (that I know of). However the "interest" they display is a good sign because it means they care about doing things better / faster.
Q5: Does Java use pass-by-value or pass-by-reference semantics?
REALLY WHAT I'M ASKING: Again, do you really understand the language you use almost every hour of every day?
NOTE: Amazing how many people get this wrong - even people who claim to have passed SCJP or even those working at Sun for years!
Q6: What does "NULL" mean in SQL?
REALLY WHAT I'M ASKING: How is data (or the lack thereof) represented? Do you really understand relational databases?
NOTE: It's amazing how many people very familiar with databases and/or are Comp Sci graduates who don't really know this.
The not-so-obvious side
What happens when you don't know the answer? Do you bluff or just admit it? Are you interested to learn and grow? Do you get angry and say "Why would anyone want to know what?". I've seen all kinds of interesting responses here.
I'm also looking for elements of developer-to-developer 'rapport' - interviewer and interviewee probably faced the same issues at different times in different jobs and that shared experience can help build some initial camaraderie.
Also important are the questions the interviewee asks
- What's your Source-code Control system & your IDE / Tool-set
- What are the Team dynamics (individual silos vs. more "group-oriented" work)
- What's the Release schedule look like?
- Hours worked each week?
- Company's financial state and outlook?
All these are good signs.
What I don't ask
It may surprise some folks but unlike some technical interviewers I don't ask the quasi-legendary puzzle questions. One of the reasons for that is that I find I don't do that well on those questions myself without lots of practice. But more importantly I don't find the exercise indicates much about a developer's skills per se. They're all too reminiscent of the SATs and GRE exams which don't really indicate other key aspects of a person's personality e.g. persistence, motivation, inquisitive nature etc.
Probably the biggest point of all . . . .
Most of what a developer does everyday is not abstract problem solving (I can hear a collective "WHAT!?!?!?") - but think about it - you really spend a lot of time figuring out how to implement the solution to an abstract problem? There are always people around who can help you find the (abstract) solution but few people who will implement it for you!
For example - let's take a requirements for a high-performance message-based system - which listens to stock price changes and updates a database. I might already know the solution will need multiple threads, a thread pool, a JMS provider etc. but . . .
Should I write my own pool or is there a good package I can re-use (JDK 5.0 has some awesome utilities for this)? Also . . .
- Should the pool grow to meet demand (probably)? By how much?
- What if the pool can't grow enough to meet demand?
- Do I need a "reaper" thread?
- What's the best way to stop a thread when it's been idle too long? What is "too long"?
- How do I ensure as little locking of common resources as possible but allow for shared caches?
- How should a thread handle an exception? Checked or Unchecked?
- Should each thread have it's own dedicated queue?
- Should they be listening to a global topic instead?
- How do I prevent deadlocking on the database?
- Does my JDBC driver support connection and statement pooling?
- How do I unit test each Thread?
- How do I test for possible race conditions?
- At what point are there simply too many threads and it hurts performance.
- What if JMS crashes? Should messages be persistent? How do you ensure each message is processed only once?
That's a lot of questions and the answers to these questions are rarely abstract - that is they are not algorithms independent of the implementation. The solutions depend very much on whether you are using C, C++, Java or C# and hitting Oracle, Sybase or MS Sql Server, using MQSeries, Tibco or Sonic MQ? These are nitty-gritty implementation issues which depend more on your experience and willingness to investigate than on abstract problem solving. Even the JDBC and JMS APIs don't obviate the need for understanding the underlying database / messaging platforms.
Above-all, I think the most under-rated (and under-interviewed) attribute of a developer is persistence rather than problem-solving. Will you stay plugging away at a problem, trying different angles, working with different people until you can solve it? Will you write a good set of unit tests before declaring victory? Will you trawl through Google to find an answer when your JDBC driver doesn't behave as expected?
So for me, often the Java/J2EE questions I ask (e.g. nitty gritty details of JDBC drivers) are really about finding out how deep / far you have gone to solve common issues (e.g. error handling, resource cleanup, performance tweaking etc.).
Final Note
I've been quite disappointed lately about how some people shamelessly pad their resume. Now I'm not talking about cases where a person says s/he has used JDBC and doesn't know it inside-and-out. I'm talking about people who, for example,
i) Claim they are "expert" in MQSeries but don't know the difference between a Channel and a Queue!
ii) People who claim 5 years of JDBC but then can't tell me the different types of Statement objects!
I'm talking blatant exaggeration.
Finally then there are the needles in the haystack. The people who just have the "gift" - they're gonna kick ass and probably teach you as much as you can teach them.
When you find that person, all that effort is worth it.
BTW I'm sure interviewees have similar bad stories about bad, disrespectful or dishonest interviewers - I know I have - and I would love to hear them or other good / favorite interview questions!
Compare and Contrast
Just recently I read Joel Spolsky's updated Guerrilla Guide to Interviewing (version 3.0)
and although I respect Joel quite a bit I was quite surprised that there were a few specific details I disagree with him on.
For example he says "If even two of the six interviewers thinks that a person is not worth hiring, don't hire them . . . I would probably allow any senior person to reject a candidate but would not reject someone just because one junior person didn't like them."
Frankly I disagree here - if you hire this person and one of your developers gave the person a "No Hire" you may have gained one employee but "lost" another. I've had managers hire developers over my "No Hire" recommendation and I found it very frustrating - especially so when the person turned into an unmitigated disaster.
Perhaps Joel would think of me as a "Quiz Show Interviewer" - the things I'm after might seem like trivia but I feel they are very important - understanding how to release resources, how JDBC works, how to use threads etc.
In particular I 100% disagree with the idea that "software teams want to hire people with aptitude, not a particular skill set.". Huh? Frankly I have a particular job that requires a certain skill set and really don't have much time to teach a person that skill set. True, they definitely need an aptitude to learn - but people with strong skill sets have strong skill sets for the most part BECAUSE they have the aptitude to learn. I'm not jumping from Java to C# or Ruby any time soon so I need people with good/great Java skills!
It takes years to learn good exception handling, resource releasing etc. in Java and I don't have time for someone to learn that (as a Senior Developer) on my or the company's dime.
I agree with him, though, that you should look for people who show passion, can explain things well and exhibit leadership potential.
In the end we're both after the same thing we just have different ideas (personal conceits) about how to get there. I'm still learning how best to interview and after writing this and reading Joel's article I definitely have some things to think about.
10/5/06
Why I *LOVE* being a Software Architect
I was reading a few DeveloperWorks articles the other day - interviews of architects on the next big things and trends in Software and it suddenly hit me - I really do love being a Software Architect - at least by the terms I define "Software Architect"
(see my other blog entries)
There's huge variety in the tasks I do each day
- There's meetings with people - developers, managers, business people, analysts, project managers and testers - each with a different language, different concerns and different needs
- There's always lots of learning to be done, if you want to stay current anyway. I learn through three core sources
1. Reading articles, books, blogs etc.
2. Learning by doing - software development is part craft and part engineering - to hone your craft you need to practice especially to a (realistic) deadline when there's $$$ on the line.
3. Learning from others - whether it's about a design, a unit test, a component or how a bond or mutual fund works you can learn so much from other's feedback, thoughts and ideas
If you're an Architect you should be spending 10-20% of your time just learning. Take J2EE for example - the JDK is always in flux, Java 5 provides, among other things, annotations, generics and new threading utilities - WOW. There's new JSRs, new trends, new open source packages, new Eclipse downloads. You can get overwhelmed easily in the firehose of information out there.
- Best of all there's the nice warm fuzzy feeling you get from "making a difference" - helping to shepherd someone's ideas and business goals in to reality. Mostly, for Architects, that comes from Problem Solving - these can be technical problems, but you'll also face project problems (such as scheduling issues, requirements scope creep), staffing concerns (hiring the best and brightest and then - hardest of all - keeping them) and then simply issues related to writing good solid code.
On the technical problem solving side, a lot of creativity can come in to play which is really great. But since you earn money to get the job done, that creativity must be harnessed and focused on the problem at hand - no-one's paying you to create a new language, or the next big thing per se. You want to leverage your experience and the experience of others (e.g. design patterns) to create a "good enough" solution. In my experience most requirements change about 35-50% by project-end. The "perfect solution" is a misnomer as what's "perfect" at the start of development won't be "perfect" by the end - so your architecture has to be flexible - that takes creativity and experience. To merge the known industry best practices, with the environment you've got and the project itself involves another level of creativity and inventiveness.
Then there's also the more visceral side- I love my job because I'm good at it (or else my employers think so!) and that creates pride and self-confidence and that's reinforcing to one's behavior. There's also the compensation - for whatever reason, supply-and-demand etc. we're paid a lot of money - more money than I'd ever thought I'd earn and that's reinforcing too.
Sometimes I forget just how lucky I am to work in a field I enjoy so much, am quite good at and
can get well compensated for it too. There's always so much to learn, code that can be improved, bugs that can be found, new things you can learn from other people - you're never done with the journey. But sometimes we all should just take a step back and see how far we've come and be thankful (myself included).
How about you? As developer / architect / manager etc. what do you like/love or dislike about your job in this world of software?
10/4/06
The most important IT Architecture Issues today
Each generation faces a different set of problems - in the 1930s it was the depression, in the 1940s World War II, 1950s was the Cold War and the 1960s had Hippies, the 80s had bands with big hair :-)
OK I'm joking a bit, but the point is, as time rolls on the problems change - at least on a surface level.
In IT, where timespans are much shorter, the hot topics now seem to change yearly - 2003 it was XP, 2004 it was SOA, 2005 was ESB and now in 2006 it's Web 2.0 (actually it's probably moved on already!)
For architects (hopefully you aren't swayed too often by the latest hot topics) the issues are a little more involved. So here's my take, in the 3rd Quarter of 2006, of the top issues facing Software Architects in increasing order of important
#8 Align IT and the Business - "Huh?" You ask? You think this isn't that important? Shouldn't it be number 1. Actually, to an extent, I do; I think it's so important that if you aren't already doing it and being concerned about it you're really not doing a good job being an architect. I'm really talking about issues for architects who are already doing a good job at this, because if you're not . . . . . well . . . good luck!
#7 Classics - Scope Creep & Buy vs. Build
The classic problems are always around - watching out for scope/requirements creep, should I buy or build? The issues here are eternal and the risk is not that they are unknown but that they can get taken for granted.
#6 Vertical Specialization
It's really getting to the stage that the most successful IT architects are the one's who know their business domain like a freshly-minted MBA - I mean inside and out - 10+ years experience in the domain etc. It's getting to the stage where IT and the business are so intertwined as to be almost indistinguishable - not just "enablers" but the business itself! That's how it should be, and to get there you, as the architect, have to know the industry and be able to anticipate and extrapolate - where are we going next?
#5 Open Source & Legal Issues
If you're not using open source it's like not using your company's retirement plan when there's a company matching contribution - you're throwing away free money. There are so many great open source packages out there you'd be mad not to use them, however if you do, make sure you've got about 75 lawyers in a back-room pouring over the licenses so you don't get into *BIG* trouble.
#4 Create new stuff while maintaining legacy things
Businesses these days are like Sharks - if they stop moving they die! However the older the business the longer and larger the investment in legacy systems that are needed to keep the "lights on" - many big companies have 80% of their IT budget just in keeping the lights on. How do you sell SOA, ESB, JBI etc. - things that will make the business more nimble and performant when just keeping the database from crashing everyday takes a 24x7 operation? Not an easy sell (and that's why consulting companies make big $$$)
#3 Flexibility
That's the name of the game - adaptation - those who adapt survive, those who don't - well can you say GM and Ford? How can you re-use what you have, and add to it in new and innovative ways and get it out the door quickly (oh and do it cheaper too!)?
#2 Time-to-Market
Your team can do it and you can architect it right but can you do it fast(er)? What requirements are critical? Which ones can wait? Do we need EJBs or can we bypass that? Do we need WebSphere or will Tomcat suffice? Do we really need Ajax now?
#1 Execution
But the number 1 issue - and it has been since the dawn of IT - is "execution" - getting the job done and done right. It's hard to fight for enough time to analyze the requirements, it's hard to get enough design time and balance it against a deliverable date. It's hard to write unit tests and create a good, solid, repeatable regression test. It's hard to ship with bugs and hard to know when you're done fixing them and it's time to release. It's hard to stay on top of all the technologies - Java, J2EE, .Net, SOA, ESB, etc. It's hard, but if you don't you're toast.
Think of how many people do it and do it well - not many!
But that's what is needed to get the job done right. Execution, my friends, is issue #1 and will remain so for the foreseeable future.
OK I'm joking a bit, but the point is, as time rolls on the problems change - at least on a surface level.
In IT, where timespans are much shorter, the hot topics now seem to change yearly - 2003 it was XP, 2004 it was SOA, 2005 was ESB and now in 2006 it's Web 2.0 (actually it's probably moved on already!)
For architects (hopefully you aren't swayed too often by the latest hot topics) the issues are a little more involved. So here's my take, in the 3rd Quarter of 2006, of the top issues facing Software Architects in increasing order of important
#8 Align IT and the Business - "Huh?" You ask? You think this isn't that important? Shouldn't it be number 1. Actually, to an extent, I do; I think it's so important that if you aren't already doing it and being concerned about it you're really not doing a good job being an architect. I'm really talking about issues for architects who are already doing a good job at this, because if you're not . . . . . well . . . good luck!
#7 Classics - Scope Creep & Buy vs. Build
The classic problems are always around - watching out for scope/requirements creep, should I buy or build? The issues here are eternal and the risk is not that they are unknown but that they can get taken for granted.
#6 Vertical Specialization
It's really getting to the stage that the most successful IT architects are the one's who know their business domain like a freshly-minted MBA - I mean inside and out - 10+ years experience in the domain etc. It's getting to the stage where IT and the business are so intertwined as to be almost indistinguishable - not just "enablers" but the business itself! That's how it should be, and to get there you, as the architect, have to know the industry and be able to anticipate and extrapolate - where are we going next?
#5 Open Source & Legal Issues
If you're not using open source it's like not using your company's retirement plan when there's a company matching contribution - you're throwing away free money. There are so many great open source packages out there you'd be mad not to use them, however if you do, make sure you've got about 75 lawyers in a back-room pouring over the licenses so you don't get into *BIG* trouble.
#4 Create new stuff while maintaining legacy things
Businesses these days are like Sharks - if they stop moving they die! However the older the business the longer and larger the investment in legacy systems that are needed to keep the "lights on" - many big companies have 80% of their IT budget just in keeping the lights on. How do you sell SOA, ESB, JBI etc. - things that will make the business more nimble and performant when just keeping the database from crashing everyday takes a 24x7 operation? Not an easy sell (and that's why consulting companies make big $$$)
#3 Flexibility
That's the name of the game - adaptation - those who adapt survive, those who don't - well can you say GM and Ford? How can you re-use what you have, and add to it in new and innovative ways and get it out the door quickly (oh and do it cheaper too!)?
#2 Time-to-Market
Your team can do it and you can architect it right but can you do it fast(er)? What requirements are critical? Which ones can wait? Do we need EJBs or can we bypass that? Do we need WebSphere or will Tomcat suffice? Do we really need Ajax now?
#1 Execution
But the number 1 issue - and it has been since the dawn of IT - is "execution" - getting the job done and done right. It's hard to fight for enough time to analyze the requirements, it's hard to get enough design time and balance it against a deliverable date. It's hard to write unit tests and create a good, solid, repeatable regression test. It's hard to ship with bugs and hard to know when you're done fixing them and it's time to release. It's hard to stay on top of all the technologies - Java, J2EE, .Net, SOA, ESB, etc. It's hard, but if you don't you're toast.
Think of how many people do it and do it well - not many!
But that's what is needed to get the job done right. Execution, my friends, is issue #1 and will remain so for the foreseeable future.
Subscribe to:
Posts (Atom)