If you thought your job as an application development person is difficult, try being a consultant. I love my job as a consultant because I am able to affect change, that is, when people want it. The most dreaded phrase a consultant can hear is “that’s the way it is”. Those words have no rebuttal, no further review. It’s the organization’s way of saying “talk to the hand”! My job is to find gaps in code or process and bring them up to the client. Often times the client has fallen into way of doing things that are counter productive, or more likely, have not changed since the process was in place. A case in point, I was having a discussion with an architect about code review. I noticed that they had the Legacy style user, date, and change comments at the top of their classes. I made a review comment that they weren’t necessary, because Subversion tracks the changes for them. It was due to their work process that comments would be lost by Subversion on multiple merges. I mentioned that several high profile companies use Subversion and don’t seem to have a problem. The architect said that research was performed and it doesn’t, and if I have a better solution, I should do my own research before making a comment. I told him that software does indeed improve, and that if research has been done, it should be reviewed periodically to see if the issue had been fixed. I did research the issue, and Subversion did have bug but was fixed, and my client could use comments in their merged code. The key here is that the staff complains that changes don’t get done, but when they are in a position to make it better, they don’t do it. If anyone investigates a new technology or work process it should be DOCUMENTED AND REVIEWED! I don’t know if it will be investigated because it seems like a trivial issue, but the main problem is that the application development people complain that nothing changes. It’s our Culture. Culture is people, and all people, especially application development people can change culture. If there are deprecated methods and TODOs in production code, bring them up in your code review. I don’t accept “that’s the way it is” as a reason. You can’t change a decision for business reasons easily, but you can fix how things get done. If I don’t like the way that it is, I make it better.
See Part One here. These deadly sins are not limited to IT Consulting in Cincinnati, but everywhere. I wish that someone would have shared the list below with me earlier in my career. It might have saved me a few grey hairs and sleepless nights. I have to admit, I have been guilty of a couple of these in the past, but that’s why it’s called experience.
5. Blame it on Rio. And I am not talking about the movie, I am talking about pushing the mistake/error onto something else like, the Operating System, another consultant or worse, one of the client’s employees. While the problem could very well be any of those things, your job as a professional consultant is to find solutions and to set an example in leadership and even diplomacy. While you may see glaring errors or mistakes and perhaps your way would have been the better way to do something it is best to keep the criticism and commentary to yourself. (See #3 in Part One)
6. Bubble gum and baling wire. Many times consultants are brought in to fix something. The last thing you want to do is to take a shortcut that you aren't sure will last. Band-Aids are fine if you know you are coming back to make a more permanent fix. But eventually, those shortcuts will fail and will need further attention and the time to failure is an unknown. It could be the minute you drive away or months later. This is not the type of chance you want to take. It frustrates the client, and it makes you look bad. You also don’t want to make the client totally dependent on you. A client told me once that Peter (not the real name) is very talented; the problem is he is the only one that knows how it works and can manage it.
7. Showing up, Gotta Go. (AKA I gotta hangnail). Once you’re on a gig, most clients want to see you on some sort of regular basis and some might have a “core hours” expectation. It’s important for both the client and the consultant to know what each should expect. I once heard a client make a comment about another consultant that went something like this: “Larry(not the real name) runs out of here all the time and uses sickleave for a hang nail!”
Here is another list that has some similar ideas here. I’m sure there are others. So go forth and sin no more!
You have probably heard your parents or grand-parents talk about when they were younger and how they had to walk to school, up hill both ways. When they shared this story with you it was to prepare you for times when things weren’t so easy and to provide you with their knowledge and advice from their hard earned experience. I wish that someone would have shared the list below with me earlier in my career. It might have saved me a few grey hairs and sleepless nights. I have to admit, I have been guilty of a couple of these in the past, but that’s why it’s called experience.
1. Bill for time not worked. This will be the quickest way to end up out of a consulting gig. Make sure you bill the client only for the time you actually work. This can be tricky if your clients are friends. When you go to a job like this, you know there will be a period of time spent socializing, especially when you first arrive. Don't bill for this time. Start the billing period when you start working. Sometimes clients will have celebrations during the day. If you don’t want to appear anti-social, by not going, just don’t bill. If there are any questions, ask the account manager to find out. If you are the account manager, ask your client manager at one of your one to one meetings if it’s ok to bill. Some client’s have a culture where that is part of the expectation.
2. Negotiate rates and make deals with the client. If you work for a consulting firm, you know there are channels for clients to go though to make requests.. Most firms have some sort of account manager to handle those issues. Direct the client to the account manager. I had one consultant that actually went so far as to look in the client’s AP system to see how much we were getting paid and then wanted to negotiate a higher rate with the client. This particular action did not end well for the consultant and he has not been able to be considered for other assignments in this client even when his skill set was ideal. Never, ever work out a side deal or moonlight with a client this can comprise your integrity and jeopardize the trust between you, the consulting company and inevitably the client.
3. Act like a prima donna. Yes, you’re good, that’s why you have been hired. I actually heard a consultant tell the client that their employees were stupid. Hello? You are there to serve those employees. You don’t know what kind of constraints they have had to work with. Hind sight is always 20-20. Its always far better to politely make suggestions. You may find out your brilliant idea was considered previously and there was a very valid reason for it not being implemented. It’s much better to NOT have egg on your face or your foot in your mouth.
4. Miscommunicate or undercommunicate when engaged at a client I believe that the client should know what is going on with their project. Many times I have had to be the bearer of bad news. I also like weekly status reports to let the client know what I have worked on and what I’m planning on doing. If at all possible I like to let them know a percent complete. Years ago, I heard another consultant tell the client he was “unit testing”. The client assumed that meant he had all the functionality done and was testing. The reality was he had about 10% of the functionality done and was testing just that one small piece. When the truth came out, it was not pretty.
Tomorrow I will finish off the last 3 sins.
To be continued……
I have been writing a lot about phones recently. What application development person wouldn’t be excited about the new smart phones? I will talk about that later, but first, the news! My colleague Aaron Whitenberger has been interviewed about his role as a Certified Business Analysis here at STAR BASE. If you didn’t know there was such a thing, you should read it now. I wrote my take about Google VS Viacom. Google spent 100 million dollars to defend their right, and it didn’t even go to trial. Vicacom is appealing, of course. The price of freedom is very steep.
Now on to my phone questions! A Java application development peer my client site refuses to get a Android phone because of “market fragmentation”. “I like that iPhone is walled off, but it’s on ATT”. He loves his blackberry, so maybe he doesn’t need it. This post from Slashdot seems to support his case. My questions to you are why did you get a smart phone? Did you consider the operating system when you got your phone? Which would you rather choose, a fragmented but open system where you can get any type of app but could have bloatware, or an operating system ruled by a “benevolent dictator” which strictly controls your hardware and software, but you are free of bloat issues? I choose Android because of its openness. I do have the technical skills to root my phone to remove bloatware if I need to. Some people can’t or don’t. I think Apple went down this road before, and I think you will see Android be the market share winner. Let’s see if Google can do better than Microsoft in maintaining some control of the platform, but still give 3rd parties the tools to innovate.
Today I look at the Business Case from a different perspective, that of Project Management. I have been involved in organizations that did the Enterprise Analysis activities that identified a business need and built the business case for a solution. The business case was brought before, and received the blessing, of the IT Governance body and a new project was born. It was then turned over to a Project Services team whose first task was to create a Project Charter.I found it amazing that the similarities, in format and content, between the Business Case document and the Project Charter document were far greater than the differences. Some sections were reordered and some content was moved from one section to another, but essentially it would be easy to swap the names on the documents and most people wouldn’t even notice. Other than the intended purpose and audiences of the documents, they were essentially the same document. This naturally leads to the question: Do You Need Both Documents, or is it a great waste of time?
Yes, the Project Charter defined a few details in greater detail than the Business Case, but also realize it was written at least a week later, when more factors were known. Also, such content as risks and mitigation plans were then transposed, and further defined, into the project’s design documents. So why can’t the Business Case be used as the Project Charter?
In most cases, I would submit that the Business Case should be used as the Project Charter. Remember the Business Case has received the blessings of the IT Governance body and should therefore direct the scope of the project. Going back to the IT Governance body for approval of a Project Charter mostly restating the contents of an already approved Business Case would definitely be overkill and put undo burden upon the IT Governance body.
One case where Project Charter(s) are necessary after the approval of a Business Case, is when that Business Case is to be split into multiple projects to bring about the Business Case solution. In this scenario you would want a Project Charter for each project to define what part of the Business Case scope that particular project was initiated to handle.
In rare, very complex, business problems with complex business solutions you may find need for both a Business Case document and Project Charter document(s). In most cases, even in large companies, using the Business Case to define the scope and reach of a project is sufficient to get the job done.
For those of you not following geek things, there is a lawsuit going on between Youtube (owned by Google), and Viacom (CBS, Daily Show, Colbert Report). Viacom is angry that some of their content was posted on Youtube. Apparently, there was 63,000 separate items on Youtube that were copyrighted by Viacom. Viacom has been supported with a “Friend of the Court” brief by NBC, BMI, and ASCAP (Basically the RIAA). Google has similar briefs by EBay, Facebook, Amazon, and Yahoo. How does this court case affect me as an application development person? Well, it could determine your web application development. There are many interesting issues here: fair use, piracy, site owner responsibility. The key issue here is for the very soul of the Internet. As you probably know, the Internet was created to share information amongst researchers around the globe. This communications device allows us to share voice, text, audio, and video. This makes it easy to share ideas, even if those ideas weren’t ours. A part of that communication is the same kind “water cooler” talk that everybody has done for years. “Did you see what that talk show guy said last night”? The only difference is now you can post it. This song expresses how I feel, and I have added some pictures to show how it has affected my life.
The media outlets want the site owners to control the content on their site. They claim that Youtube is a content provider, and thus are “stealing” their content for gain. This would be analogous to suing the U.S. mail for getting a threatening letter. We have fair use, so any signal sent through the airwaves is free for anyone take and use. This meant that anyone who broadcasted, the content could be consumed by anyone. The content providers made money by placing advertisements in the content. Since that time, content providers have been using congress to side step these boundaries by changing the length of copyright, putting "digital" rights on formerly analog content, and pushing for laws that allow content to be controlled by the provider. The large media companies ignored the Internet because there wasn’t any correlation to their business. When companies like Google started to compete for the same advertising dollars, the large media outlets saw the Internet as a threat to their business model, and are now looking to destroy it.
No one is trying to deny content providers money. It was agreed long ago that your work was yours, but eventually it would be owned by the public. That changed when media companies are entirely built upon their own content (just look Mickey Mouse at Disney). Do people take content that doesn’t belong to them? Yes. Are people just posting items broadcasted to make their point, or to inform? Yes. We have to decide as a society whether the Internet is place to allow copyrighted material as a form of communication. NBC found it distasteful that their shows were on Youtube. That’s why they created Hulu.
What do you want the Internet to be, a free (as in liberty) communication device, or a pay-per-view broadcast medium?
I am finding out things at my current client that everyone, including application development people knows; having a process is only half the battle. I have been to organizations where business workflow processes were not in place, and the productivity gains were huge when implemented. But over time, those processes stop getting followed. There are many reasons for this; the IT culture rejects the change, the processes don’t get reviewed in a timely basis and become a burden, and the players forget their role.
My client has a decent development workflow in place. Analyst get requirements from the business units, architects turn the business requirements into technical requirements, and application development people execute the requirements. Managers should manage the process, making sure that the resources are available when needed. I always wondered why top technical guys get passed over for management in favor of PHB (Pointy Haired Bosses), and now I know. It’s that PHBs know their role. Managers are managing the PROCESS, not the solution. Often, technically savvy managers want to work the issue. Software development is a very fluid process, and what works now, may not work three years from now. If you are manager for more than six months, you probably don’t know the correct solution. Regardless, your role is to make sure application development staff are available for the solution designed by the architects. Managers have a right to review the design during the design phase, but once finalized, let the architects and application development people do their jobs.
The same is true for consultants. Yes, they are using older technology, and yes it’s a pain to use, and yes it needs to be updated. Your job is to help resolve those issues within the framework of their organization. Unless you are brought in as a CIO consultant, the choice is probably not yours to make. It may be that the business has urgent needs that supersede modernization. They may not have the technical people to maintain the new code. The organization could be planning to replace the system with a prepackaged application like SAP. Or it could be that the technical staff knows their role, and is waiting patiently for their opportunity to upgrade.
I am now in my second stint as a performance architect. There are many tools to measure performance. Usually there is some criteria like time or memory that is failing. I think most application development people know that the secret to good performance is good code. The problem is that good code is impossible to measure. There isn’t any metric you can show your boss that shows refactoring this class will make the code run faster, or at least will not remove that class from the performance list. Besides we have these new features that need to be added. So how do I make code perform at a high level?
Write unit tests. Make sure that the tests cover all of your method calls. Make sure that your test captures error situations, not just the "happy path". Write your test cases BEFORE you write your code so you can "code to the test". Of course, you need good use cases from your architect and business analyst to write the unit tests.
Comment your code. Make sure your method names describe the function it is performing. Most IDEs add the parameters and returns for you; all you have to do is describe the reason for the method. These are easy things to do. They are boring yes, but when it comes to adding that new feature, or changing a method call, it saves a lot of time when you can run a test to prove that your changes work.
Refactoring. All application development people should learn refactoring. The Java language has changed tremendously in the last 15 years, and your code hasn’t. I think that the Date object has been revamped twice since the 1.x days. New features like annotations and generics may not change the performance of the code, but it sure does affect the readability of the code. Readable, easy to understand code is also easy to maintain and update. It makes a six month project become a three month project. The business always has more projects, so they will be happy. Fewer errors happen, so your boss is happy. You get to solve more interesting problems so you are happy. When you are happy, both you and your code performs better.
My client has great code promotion rules. All code that changes gets system tested or it doesn’t get promoted. Code doesn’t change unless it has a bug tracking ticket. You say Matt, that’s great! Why is this a problem? The problem resides in the fact that everyone in IT is stretched to the limit, and deadlines are tight. Application development people are getting the code working with little refactoring, architects struggling to get the analysis piece out and little time for code review, and not enough testers. This situation makes it difficult for performance. As part of the performance team, I can review all of the code, and make some changes, but the problem is that if the code is not a part of the release, it will be impossible to get promoted due to time/resource constraints.
For example, a process was taking a long time to complete because of improper error handling, but the call is not necessary. The proper fix is to remove the call, but the fix going in only resolves the exception. Why? The low priority of the code, coupled with the testing constraints and lack of testers makes these changes common. Some application development people may say, "Well, the code is fixed". True the performance issue is resolved, but there is an unneeded call. If the attitude from application development people is "I would fix it, but it’s too much trouble to test", unneeded code can add up quickly. Extra code is in all projects, but if changes like this or, removing a variable passed to a method, or even changing code to remove unused variables don’t get fixed, the "extras" add up. Not one of these changes significantly affects performance, but all of them will. The solution is to work with management and your application development people to limit "extra" code. This can be done by reviewing and fixing code in your maintenance or enhancement project. Have a "refactoring time" built in to the project plan. The time put in up front will bring great dividends both in performance and future coding effort.
I have a new client in Cincinnati. New clients are always interesting because you never know what issues and opportunities you will find. My client seems to have their act together. My application development friends will appreciate their setup; Maven 2 projects with built-in JUnit tests, a code coverage dashboard that show code complexity, code coverage, and Find Bugs reports. Things seem great, them why do they need a performance engineer?
The reason is common; who defines the duties of ITsets the rules. IT and the business need to be aligned to work on the common goals and increase productivity. If IT is too dominant, there is too much focus on technology and the business doesn’t get the tools they need to be productive. If the business unit is dominant, only projects that have a tangible return get done. In this case the business is more dominant, so projects like refactoring code, or cleaning up errors found by software like Find Bugs has a much lower priority. They do happen only if performance is an issue to the business. The performance team is set up like a clean up crew that comes in after the fact, to make things work better. There are coding style forms and best practices, but is up to the each developer to follow them. Since the focus is getting the project done on time, the developers are concerned on getting code that works,not what works best. The performance team is used to fix the worst performance offenders.To be fair, I have been at clients where IT treats the business units as a nuisance. The best tools are there, but little support for the business.
What’s the solution? IT needs select a technology that best suits the solving of business problems. The business should prioritize their issues, but work with IT to plan for fix releases. IT must utilize the tools that they have and encourage the usage of them. If you have the tools, use them!
After playing with JPA, I realized that I really don't want to directly hit the database from the client, because that would mean opening up the database port to potential attackers. JPA is really great, but either you hit the database locally, you hit the database directly from a remote location, or you access the database through a connection pool. JNDI is the best way to access a server resource, but it needs to be in a server container. I could not find a way to call JPA using a JNDI context from the client. All database servers have some mechanism to accept multiple connections. But besides the obvious security issue, I already have an application server and connection pool. I should let the connection pool do the work, and figure out plan B.
I reviewed all of my options. I am lucky because I can use the latest and greatest since this is all new. I am using Java 1.6, so I can use EE5 or EE6. Most application development people know that EJB has had a history of being complex, and at times, unwieldy. I could call JPA via servlet, but I was concerned about performance. I decided to use RESTful web services to push data to my JavaFX application. Using REST in JavaFX is quite easy, because the 1.2 specification has a HTTP request object. That means I can write all of my access and utility objects in JavaFX, instead of accessing a class library externally. The big drawback I have thus far is that all of the related objects are another link, and another call to a REST resource. For example, if you look up a specific Customer Record using REST, you will get the details in XML or JSON. To get the collection of Orders related to the Customer, the XML returns a link. You must make another call to get another XML/JSON to parse the related information. The parsing process would not be to big of a deal, except that everything is done asynchronously. I have a Table A object where one of the fields would be a collection of Table B objects. The Table B object contains a collection of Table C objects. In JPA, all of the related collection objects are there and ready for me. Since REST is asynchronous, It makes it very difficult to set up a Table A row object, because Table B is a separate call which will start and finish without Table A's call knowing anything about it. For my database application development people, the key is to de-normalize your relationships. Since this is a big departure to my original schema, I decided to create a whole new database in case I wanted to go back to JPA. After some trial and error, I have a way to asynchronously access and display REST resources in a JavaFX application. I now have to work on writing that data.
Of course, a one-page document is not what we experience in our IT Business Solutions projects today. Instead, we have what Chris Gurney wrote for BA Times as the “Big Freakin’ Requirements Document”. Chris outlines the various reasons that our requirements document has to be so freakin’ long:
- To Communicate to all audiences
- To Validate that Needs are Met
- To Ensure Everything’s within in Scope
- To Manage Changes to Requirements
- To Meet Regulatory and Corporate Obligations
- To Define Requirements Collaboratively
It has become common place in over the years to try to accommodate everyone with one document. So language is included for executive staff. Then we translate the requirements to a more detailed level for developers and testers. We turn on “Track Changes” feature to retain the history of changes to the document; which then leads to descendent versions of the document.
What Chris is trying to point out in the article is that a Word document is no longer sufficient for collaborative development of requirements for our IT business solutions projects. What you can expect to see is many vendors rush to provide software solutions to these shortcoming
s. Currently, there are some solutions out there to address these issues. I will not promote any current software solutions here, but you can expect to see more solutions from new vendors in this area. You will also see great improvements in features in the solutions that are already on the market. When business organizations migrate in groves to these solutions and away from Microsoft Word as the standard for “document” development then you will see this market grow rapidly. Large organizations with large IT staffs and geographically dispersed enterprise application development teams should be first to make the move. I think you will see Business Analysts within those organizations leading the charge, but with all “organizational shift” changes, convincing those that hold the purse strings of the value and need for new tools will be their greatest challenge.The BA performs an important role in the application development process and is tasked with the duty of ensuring that the IT business solution meets the needs of the business. The BA develops and maintains the business and functional requirements that the IT business solution must contain in order to be deemed successful.
So we know the role and duties of the BA during a business application development project, so what “skills, knowledge and personal characteristics” does a person need to have to perform these duties. As the duties of the BA entail eliciting requirements from stakeholders and working with an application development team, you can imagine that communication is at the heart of the competencies of a BA. Good written and oral communication is necessary in order to be able to perform these duties. Good communication is not only departing information, but taking in information, or listening. This is often the skill that is over looked when we talk about skills or create a competency model.
Notice that when discussing competencies, that we not only are talking about “skills”, like Decision Making, Creative Thinking, Learning and Problem Solving; but we are also considering “knowledge” and “personal characteristics”. As the BA has to work with both the business and information technology staff, they need knowledge of the organization, industry and technology. What kind of personal characteristics would you want in a person that serves such an important role? I am sure ethics and trustworthiness would make the top that list.
So if you’re a BA looking to advance your career, there are some competencies to work on. If you’re an organization or manager looking to hire a BA, look not only at their skills and past performance, but develop some probing questions that will give you a look into their “underlying competencies”.
Once a project is approved by the governance body it is turned over to the Project Management Office (PMO) to guide the project to completion. The PMO will be staffed with project managers (PMs) and business analysts (BAs) that will guide the project the rest of the way through the project life cycle. You may be asking why you would need BAs as part of the PMO, or project leadership team; after all the PM is responsible to see the project is completed on-time, on-budget and on-schedule. Yes, but the BA would be responsible to see that the project is completed and the IT business solution meets the business requirements. A business application development project will need functional and technical specifications that the BA should help develop.
The third role of the BA, I alluded to in my first post on this subject, is that of the Test or Quality Assurance Analyst. One role of the BA is to support the system, quality assurance and/or user acceptance testing phase of the project life cycle.
So the answer to the question ‘where does the BA fit …?” is in many positions within the organization. It depends on which BA role you wish to discuss, and whether the organization is large enough to have a BPO and/or PMO.
Any thoughts on the subject?
This is the question that many organizations are still trying to answer today. Many organizations are just realizing the benefits of the BA role. One thing to realize, is those of us in the BA arena today are in the forefront of an infantile and growing profession. The International Institute of Business Analysis (IIBA)®, the professions governing body, was formed in 2004; incorporated in 2006. There are 827 certified professionals (CBAP)® in the world. Compared to the Project Management Institute (PMI)®, which was incorporated in 1969, offer five certification programs and has nearly 300,000 certified professionals. You may say that your company has had BAs for the last 5 or 10 years. Then I say your company is one of the forward-thinking organizations that has recognized the benefits that the BA role provides in developing IT business solutions.
Now I believe this discussion will go on for years; but as this is my blog, here I get to put my two cents in. First, let’s define the role of the BA in which we discuss. Many organizations have a quality assurance team, department or processes within the IT application development team. As these people support system or user acceptance testing procedures, these people are Business Analyst. For this discussion, I refer to the Business Analyst that works on the front end of the project life cycle. Who develops the Enterprise Architecture, gathers business requirements for business process improvements and makes the business case for IT business solutions projects to make those improvements.
As the role of the BA is to develop requirements and make the business case for IT application development projects, this is an IT function; therefore the BA is an IT position and should report to the IT management as opposed to the Business management. Although the duties that the BA performs may put him/her in front of external customers of the company, their goal is not to perform the business of the company but to recommend IT business solution projects to improve business processes within organization; this is an IT function.
If your organization is large enough to use terms such as Business Process Organization (BPO) and Project Management Office (PMO); then you should find the BA at the heart of the BPO. The purpose of the BPO is to analyze and recommend improvements to business processes. So now you say that in most organizations the BPO is a business team; I would reply that it should be a combination business and IT team. The improvement to business processes may require a business solution, such as upgrade or replace business machinery or training; or an IT solution, such as application enhancement, system training or system upgrade. Therefore, the BPO should be made up of business positions and IT positions working together to determine the best solution to business issues.
One thing that I would change in many organizations is that I believe the BA should sit more in the vicinity of the business unit(s) that they support as opposed to sit in the IT Department. BAs will be much more effective when they fully understand the business processes in place, issues that business workers face and the daily going-ons within the business unit(s). Also, easy approachability to the BA for the business gains buy-in to the duties and recommendations of the BA.
So there is my opinion on the subject, what is yours?
I don't often get on my soapbox, but I feel it's time for this. Stop whining! This refers specifically to application development, but I guess it can be applied to most everything. The point I am talking about is application frameworks.
I am using JavaFX, which is relatively new. The problem it is trying to solve is to remove the cruft from desktop application development (Swing), add 2d animations, and be able to run on a variety of devices and platforms. For me the holy grail of Java development would be to create an application that runs on mobile, desktop, and browser, all using the same code! JavaFX does this nicely. Some application development people won't even look at it because features like menus are not there yet. Are there some things missing? Yes, but there is a difference between “where's function X?” and “Epic fail! I can't do anything because function X is missing!”.
All languages, especially new ones have holes in them. You must learn to work around things, that's why I call myself a hacker. Would I want to have something work out of the box? Of course I would, but I also understand that knowledge comes with getting your hands dirty. Just because I can't drag and drop a control doesn't mean it doesn't work. I think the rule of thumb for me is, if the work takes more code than the application I am working on, then's it's broken. I think the whining is more apparent in the younger guys, because of the great things we can do in our IDEs. Not to sound like a greybeard (but I will anyway) is that I started coding Java in NOTEPAD! The same is true with HTML and XML. I love that code completion and other useful features have become standard now, but I bring this point up for a reason. I know how to fix it when breaks, because I know how it's put together.
Sure code is tough, but if you think writing an application is tough, you should see what it takes to write an API. The application development “magic” doesn't write itself. If something doesn't work right, investigate it, instead of complaining. You may have the key fix to make it great. I know you will learn something during your research. You can't drag that control, so you will wait until it's so easy, even a caveman can do it. If you do, you may be replaced by a cheaper caveman.
I am part of the LinkedIn community and a member of several groups in LinkedIn. One of the groups I am a member of is the IBM i Professionals group. I get a weekly summary of activity and sometimes there are comments on the posts that people have made. Usually there are no more than 3-5 comments. What caught my attention is a LinkedIn post that had 23 comments. The original post referenced this blog post: http://blog.angustheitchap.com/?p=159 In this post, the author talks about the iSeries application development community needing to pull together to DO something about the lack of support for the platform. He asks the question: What have YOU done for the IBM i platform this week?
As a former iSeries application developer, I thought it was a good question, perhaps about 10 years too late, but a good question none the less. Let me state for the record that the iSeries is a great platform and it is without a doubt the best box for business that IBM has.
The problem is that it is a victim of its own success. There is no other platform where an application written in the 1980’s could still run un-touched even though the underlying hardware has changed numerous times. To me the core issue is this: IBM is no longer in the hardware business; meaning they don’t derive that much revenue from hardware anymore. The majority of IBM’s revenue comes from services. The iSeries does not need or generate the services revenue that other platforms do. So in my opinion, it’s an economic issue and no amount of doing or community is going to change that.
I recently read an article about the state of the IBM “i” and the amount of complaining by IBM application development and business partner folk. I know several RPG application development folk, and it sounds familiar. That made me think about my Java Application development and career. Are there things to complain about, and uncertainty about the future? Yes, but there are 2 reasons why the Java community is in a better place; the business model and the community. Before the IBMers call for a holy war, I said COMMUNITY! I am not talking about the strengths or weaknesses of the hardware or software. The business model for IBM is that they make the hardware and software, and partner for the sales and service. I think that is a viable model until IBM competes in the sales and services with their partners. If a lead is brought in by a small partner, they are awarded by giving the business to someone bigger. This sets up a confrontational relationship between IBM, the big partners, and the little partners. IBM can also decide whether or not you are worthy to be a partner. Why does this affect the software application development team? Because most consulting firm are selling SERVICES not HARDWARE. If they are not seeing business because of political fighting, they don't have to sell it. There are viable options on other platforms, where interference does not happen. IBM never fostered a community, they created a hierarchy with themselves as the head.
Certainly Sun has done some things that made myself and others unhappy. Besides, complaining, we actively pushed to remove barriers in our path. We do have an open source Java. Is there a IBM community that can work with RPG to make it work for them? I also think its about scale and timing. It's not like IBM software developers have their own AS/400 at their home. It's easy for me to create and use nearly any kind of application at my home in Cincinnati, and pretty cheaply. It makes it fun to tell non-technical people about my application development. Nobody but accountants want to hear about accounting programs. Java, and newer languages have grown up with the Internet. I have friends from all over the globe that have similar interests. If I have a problem, I can go online to a forum, friend, or web page to find what I need. I can read and write blogs to voice my opinion (like now). These things are not ingrained in the Legacy community, and in fact, have been actively campaigned against. It is my belief that any software, hardware, or service will die when there is no vocal community to support it.
As a consultant and application development person, I have to learn new things all the time. Take for example, my work with JavaFX. The language does have some familiar aspects, but there is a lot new there too. How do you go about learning something new? I have come up with some guidelines that I use in learning new things (in this case a language):
- Read as much about it as you can first. No one wants to wade through tomes of technical information, but that is where you learn. I try to get a feel for what problem the new thing is trying to solve first.
- Understand the core elements. Whether it's a programming language, a car, or a philosophical construct, knowing how it works is the first step. I know it's time to go to the next step when I have some ideas on how to use the item, and I start formulating a project.
- Examine and breakdown examples, if you can. You would be surprised at how many application development people think they're “smart enough” to figure out how things work just by following a few examples. I don't know about you, but I don't figure out a complex things just from a few simple “Hello World” examples. That being said, seeing how things works is the quickest to way get a basic understanding. Couple that with knowledge you acquired by reading the manual, and you get the “why” of how it's put together.
- Create your own knowledge base. I like to Google more than most people, but things do need to get done. I will create a separate folder to contain links to examples, other application development team members' blogs, white papers and other documentation. If you can, create a “how-to” WIKI. Having a centrally located repository makes it simple to answer questions.
- Create a test project. I do this especially for languages. I create a test project where I can test specific “how do I?” questions. It keeps you from removing code, adding unnecessary functions, and commenting and uncommenting code in your main project. Figure it out in its own project first, then transfer the code and knowledge to your main project. It is always good to revisit it after a period inactivity.
- Write or teach what you learned. As application development people, we tend to get blinders on when doing something. Having a different set eyes, or different questions being asked makes you examine what you actually know.
So there's my “Secret Sauce” for learning. You still have to come up with ideas on how to utilize you knowledge though.
Powered by Compendium Blogware