Posts

Off Topic: Sources of Technical Depth

Image
Software projects which are in the maintenance phase of their life cycle have to deal with Technical Depth soon or late. Sometimes this can be completely ignored by the development team and project managers. Early warning of a non managed technical depth is causing a full stop in the new feature development. In worst case it can cause a reboot in the software project which means efforts to maintain project stability is bigger than redevelopment of the product. Classically technical depth is something hidden in the source code of the software. Therefore naturally it is something invisible for the product managers without any software development skills. In this case it is software development teams responsibility to make it visible for other steak holders. This type of depth is grouped in the left side of the source diagram. Internal Sources of Technical Depth Classical technical depth sources can be enumerated as follows: Legacy Code Any piece of code written in t...

Off Topic: Naming the Software Design Bad Practices

During maintaining a code base for software, developers have to deal with what we mostly call "legacy code" . Beside its original meaning, legacy code mostly refers something that you do not want to touch or change because it is a mess. Mess in the code can be caused by a number of things. First few reasons I can name are: Lack of time to develop software Most probably some unrealistic deadline is the underlying problem. It can also caused by finding out a design failure as a bug in your customer installation. There is no time to fix it properly but it must be fixed. Lack of personal experience Developer is lazy or did not experienced the consequences of developing unreadable code yet. Software source code is not a place to show how complex you can think. The hack, which is showing how complex you can think will cause unreadable code. This is a trouble for your future yourself. Lack of community knowledge In this case software we are dealing is really legacy cod...

Language Architecture for flexibility

Model Driven Development in practice

Model Driven Development is an approach. It creates a long term profit by capturing the business knowledge into model artifacts. As more time invested on artifacts, software created based on them captures the domain better and software product's quality increases. Another important point here is that, this increase is independent from any key player domain expert. Because your organizations knowledge is not in the brain of any domain expert but in the model artifact they are creating together. In comparison this is a huge difference to classical development relying on a particular technology. Classical development points source code as source of domain knowledge. Now software developing organization has a possibility to create technology independent business value. Model Driven Development is not just for reducing the development time but also capturing the domain knowledge in a technology independent way. In practice many developers came across with the term "Model D...