Skip to main content

Posts

Showing posts from May, 2013

Freed from tools

When the developer gains more experiences, he/she should tried to develop functionality with less support from tools. This means the scale of functionality gets smaller, and the developer has to use OS API or driver calls. IT products in the market tend to include more functionality and pretend to be invincible, and moving development skills toward system development seems opposite to market demands. But when the developer knows more about the platform and hardware he/she is using, he/she is less likely to be fooled by evolving developing tools. He/she will say less 'I don't know', but more 'I can bypass it' or 'I will find other solutions'. Developing tools are similar to fantastic woodworking tools which help carpenters to create beautiful lines, curves and smooth surface. But without  woodworking tools, an excellent carpenter can still create masterpiece with a rusty knife.

Manager, project leader and professional

Being a manager of a IT department, there is no difference from other non-IT departments. The responsibility is deploying resource properly to meet enterprise objectives. IT profession is not really important, but communication and negotiation skills are critical. If IT manager is also familiar to IT related fields, the knowledge helps his/her plans meet trends of the future, and demands to IT professional more reasonable. The major task to IT project leaders is also communication. This position requires higher IT knowledge so he could reasonable debate for technical possibility and schedule, and help users to clarify valid structure and workflow which helps professionals understand real demand clearly. The most important skill for IT professional is technology. They are the only type of people make promises come true. Junior  IT professionals helps to create and design models. Senior professionals help revise the structure and keep enterprise's virtual property, including data

Taking over experimental project

When a enterprise approves the contribution of a experimental project, the better strategy to take it over is allowing the senior developers to reconstruct the core functionality of the project. Developers for experimental project usually know user requests better than senior developers, and the senior developers know enterprise systems better and are more experienced on building more reliable structures. After revising the core structure and unifying functionality with other existing systems, the project would be returned back to original developers and could be extended for further requests. Senior developers review the projects regularly and adjust or revise the structure if necessary. The collaboration of original developers and senior developers ensures the project be built according to user requests, the enterprise owns the core technology and enterprise systems share the same functionality.

Technical training

When the enterprise buy existing products,  some of the developing company provides technical training that helps the enterprise customize their own product.  In business's perspective, this model indicates that the developing company sells semi-manufactured goods, and transfers customization expense to the buyer. (In retouched terms, the developing company builds reliable tools and allows the buyers to modify by themselves.) At very beginning, there are lots of work to do to apply new IT products on the enterprise; and then the modification demands decreases or finally goes ceased.Stability might be the reason of stopping; or the aging of the tool. Should the enterprise take those trained specialists as long term workforce? Probably not. They are the expense saved by the developing company and transferred to the enterprises. Like buying firmware, applying software should take deprecation into consider. And trained specialists should be included. Will the data in this tool d

Experiment

'Applying technology', enterprises should take it as investment, instead of expense. This means 'taking risk'. New IT ideas should be applied on small group first, in order to prove the validity and effectiveness.And then expanding its functionality toward full scale and taking user habits into consider. Finally, it is time to search for substitute products in IT market. During the experiment period, enterprises could hire less experienced developers to implement expected functionality. Senior IT professionals help resolve technical boundaries. When the experiment is taken as successful and the enterprise decides to keep this model, there are two options to build it into formal and reliable structure. One is the senior developer takes over the responsibility of core structure improvement, and less skillful developers continue on customize the model to be more user friendly. If the project is decided to be outsourced, the project manager have a practical model to n

Speed

When non-IT enterprise wants to apply new technology, the most important thing is speed. Speed is very critical to IT industry. Soundness and benefit should not be the first thought, although the first one to create doesn't guarantee to be the most successful. The product always needs polish. But failed to be the initiate almost doom to fail. Exclusivity in IT market is obvious. There might be no exclusivity risk to non-IT company when applying new technology, and it seems delay helps decision makers to observe the value and evolvement of the product. But IT product changes all the time, and 'new' technology is aging. To non-IT company, the target to evaluate should be the effect of applying, but quite often they take the prosperity of this technology into budget consideration. After long term evaluation, the aim could never fulfill because the technology is out-of-date. Non-IT company often forgets one thing: technology is the mediator to the expected effect, and is 

IT quality for enterprise

Usually non-IT enterprises are IT product users. It is not really possible for non-IT companies to develop all software on their own. It is also rarely possible that the developing companies hands over their source code to buyers. The restriction on both sides not necessarily decides IT companies control non-IT companies's business information. The role a senior software developer plays in non-IT enterprises is to guarantee business information and enterprise workflow will not be affected by the changes of tools. The following examples express this concept in more practical ways. If the tool changes its requirement from MSSQL to MySQL, the senior developer should make the switch happen.  If the enterprise need to control the priority of user account, and the tool only provides library or receiver to the external, the senior developer need to implement the library and link it with existing account service.  If the developing company is going to shutdown its service, and the e

Need not developers?

If enterprises are divided into IT companies and the others, the relation between both is supportive and exclusive. In order to maintain the massive business structure, non-IT companies need the support from IT products. IT products is used for inner workflow. Non-IT companies need inner stability, so they can expand their core business. But how IT companies keep competitive is creativity. IT companies are aware of the importance of stability to users, they gradually switch their service from products into continuously support; but they still need to create their own break-through. Or when any better product comes out and their users switch over, their will be out of business. Keeping changing is the destiny of IT companies. Stable support is almost a wishful thinking. When supportive relationship breaks, non-IT companies suffer most. IT companies lose business, but non-IT companies lose workflow. Why a non-IT enterprise needs software developers? It needs to protect its life

Development and management

At the beginning, there is very  dim line between system professional and project professional. Technical professional is easily drawn into manage professional. When the senior developer is not able to modify codes, nor able to keep important functionality while slicing garbage out, this person is no longer a technical professional. But this situation is only known by oneself. As mentioned before, functionality is too invisible, so that outsiders take it as disposable. Therefore the world keen to push a developer toward project manager. Society is built by human. Human interaction usually has higher priority over pure technology. It is not a good sign that a developer doesn't know how to interact with layman. But spending too much time on communication and losing the ability of development is choice.