Author: cvjepsen

Claus Jepsen is a technology expert who has been fascinated by the micro-computer revolution ever since he received a Tandy TRS model 1 at the age of 14. Since then, Claus has spent the last few decades developing and architecting software solutions, most recently at Unit4, where he is the CTO leading the ERP vendor’s focus on enabling the post-modern enterprise. At Unit4, Claus is building cloud-based, super-scalable solutions and bringing innovative technologies such as AI, chatbots, and predictive analytics to ERP. Claus is a strong believer that having access to vast amounts of data allows us to construct better, non-invasive and pervasive solutions to improve our experiences, relieve us from tedious chores, and allow us to focus on what we as individuals really love doing.

Choosing the right tools

Over the course of the last couple of years, I’ve been working on a lot of different projects where we initially had to make some technology decisions on what development ecosystem to use. By development ecosystem I refer to the sum of programming language, IDE and API (libraries) needed. In most of the discussions it was typically a debate based on the individuals personal preferences and what they’ve used to work with, rather than a non-biased discussion based on what problem we’re trying to solve.

Personally I don’t think the best approach to select any specific implementation technology is to let it be based on personal preferences, albeit I do concur, that sometimes that will get you there faster. There’s a lot of factors that needs to be taken into consideration prior to selecting specific technologies. One of the more important things to take into consideration is the preferences of your customer base. E.g. trying to shove a Java based solution down the throat of a .NET fixated customer base or vice versa – isn’t the most sensible thing to do, or at least not the smartest. It may be easier to chose technology based on the preferences of your customer base. From a selling perspective, by doing so, you remove one obstacle in the sales or adoption cycle, whatever commercial model you’re using.

The next problem in the personal-bias-decision-process (PBDP) is that the decision process becomes based on the individual decisions makers personal bias and technology comfort zone. So rather than evaluating tools and technology in the context of the task, I’ve encountered and witnessed a fair amount, or more precise, I’ve predominately seen people doing it the other way around. They evaluate in the context of their comfort zone when it comes to technology and tools.

Personally I find this approach somewhat disturbing, as there’s a risk you end up utilizing the wrong tools for the wrong tasks – like a carpenter trying to use a chainsaw to create a replica of a renaissance chair. But what really throws me off, is that we as software engineers are obligated to propose the best tooling for the task to facilitate speed to market, customer adoption and fast feature turnaround.

We as engineers should always be looking for new and better ways to develop software, researching new technologies, tools and languages to keep track of what’s going on in our field, to be able to recommend the appropriate tools and technology for a given task. We should see an opportunity to use new tools as a way to broaden our experience rather than being hampered by our comfort zone.

#programming #tools

The Future of Software Development

It’s becoming more and more clear that monolithic applications are going the way of the Dodo. With the general adoption of smart-phones, tablets computers and social network portals users starts having an expectation that information is available anytime anywhere. Users simply don’t want to deal with booting up a desktop or laptop, login into an application, go to the right place to get the information. Its time consuming and inflexible. Users want seamless integration of essential data and information into their preferred social media sites and mobile devices.

What does this mean to the ISV that produces traditional applications? Well, if these ISV’s don’t start reconsidering their development strategy they risk facing the same fate as the Dodo. Actually, already now companies without a clear social media and mobile strategy are considered dated by the younger generation of users. New tech savvy users milling out from the universities and colleges look and evaluate companies on what strategy they have, and if a company allows them to work on cool stuff or at least there’s the potential to work on cool stuff. Hence, it becomes a huge challenge for ISV’s to recruit new young talent, especially the better students will prefer companies with a strategy that embraces mobile computing at the core.

And this is only the development side of it. Think about it, in the near future the next generation of users will also become part of the decision making process at the customers of the ISV’s. Making it a huge challenge for software vendors without sufficient presence in the mobile application market, to sell their solutions. There’s a huge risk, and in some situations, this is already the reality where a missing mobile strategy or adequate integration into social media sites disqualify a vendor in the initial phases of the buying process of new software systems. Personally I believe this will become an even bigger problem in the near future.

What’s interesting is that most ISV’s have the opportunity to actually provide interesting applications to their customer base, as they got years of data and experience in collecting data. They have a solid foundation for extending their offerings to include mobile and other interesting lightweight applications that can access the data and present it into different portals. Portals of the choice of the users.

ISV’s should focus their development efforts more on how to expand the usage to the casual users instead of the power users. Power users will continue to use traditional clients on their desktop or laptop, as they need high speed processing of huge amount of data. However, the casual user of the future doesn’t want to deal with these types of clients. They want immediate access to data on their preferred device.

Note that it’s not just about providing data and information but also about having lightweight applications for handling processes. Users will more and more be looking for applications that essentially do the work for them, and users only need to validate that the proposed action is actually the right action. Like flying a plane, the pilots really don’t do much anymore, they monitor that the software actually does it right, and they only intervene if a unique situation arises that requires manual intervention. That’s how all software involving processes should work in the future.

For us as developers this means that we also need to embrace the technologies and start extending our skill-sets to include mobile computing as well as portal computing (like web parts). Just as the ISV’s we can’t keep relying on our existing knowledge on building n-tier or more traditional client/server solutions. We need to start thinking in total distributed computing, multiply number and diverse data sources. We need to change as well; otherwise, we risk the same fate as the ISV’s – that our skills risks being inadequate for doing software development in the future.

#programming #light #apps

Essence of being a successful Development Manager?

The above question was sent to me the other day from a former colleague and friend. He was preparing a presentation for heads of product management and product development, and not being an engineering manager himself he asked for input on the subject of “Essence of of being a successful Development Manager”

I usually refer to a development manager as an engineering manager, as developing software is much more than simply developing the software itself. When you develop/design software today, you need to take all kind of operational aspects into account (http://bit.ly/fW0OvT).

Technical

Anyway, so what’s required to be a successful engineering manager. Though question. And maybe not. One thing I’ve realized after working in software engineering for more than 20+ years (wow getting old), and have had a number of different managers, is that the single most important and an absolutely unquestionable qualification for any engineering manager is that they have a background in software engineering. That they actually have written code, tried to find a subtle bug in a multi-threaded application, that they’ve been through the process of reading thousands of lines of code to locate a memory leak (not using profilers). Have dealt with double-pointers (Macintosh handlers), cried at night because a data structure wouldn’t align at word-boundary – all that nitty-gritty stuff that makes us all sweat. I don’t purposely disqualify people that haven’t developed in any low-level programming languages like C and Assembler; however, I strongly believe that even if you’re of the automatic GC generation it still worth your while to understand and gain experience with fundamental aspects of the computer, like how memory operates.

Why is this so important, that an engineering manager actually knows how to write software? For same reasons that a lead of a bridge construction team is a bridge construction engineer, how else can he make critical decisions? Actually how can anyone be trusted to make decisions about any professional field, unless they got the t-shirt? How can any non-software engineer provide any assistance, help or guidance to the team unless he or she knows what it’s all about? I don’t know, and based on personal experience, they can’t!

There’s more to having software engineers running development teams than just being able to facilitate the process of developing the software. It’s also about understanding where in the process the team is, how far we are, and more important (sometimes) how much are we’re off course. Only people with engineering background can read another engineer, can understand where they are, and truly appreciate the work being done. And BTW engineers don’t really trust other professions, that’s just a fact. So lot’s of good reasons to why the single most important qualification of any engineering manager is that the manager in fact him- or herself is an engineer.

So a good engineering manager knows his stuff, knows how to write code, know how to design architecture, knows how to make a reasonable data model and knows how to execute. He can ask the right questions and provide the right technical answers and guidelines to his team, and he’s capable of writing code himself. Actually, any first level engineering manager should spend 25% of their time writing code. Way way better for the project than spending 25% of your time making MS Project plans, that doesn’t tell you anything anyway. Being in the code on a daily basis will tell you precisely where the project is and where it’s heading. If you’re too remote from the code you lose oversight! The project starts slipping, you’ll have delays and the team suffers, the company suffers, customers suffers and the engineering manager suffers – because he’s not a “real” engineering manager.

Able to say a resounding NO

This is actually very important qualification as well. We as engineers don’t like to say the “NO – it cannot be done”. Why is this? Personally I find it very hard to say NO. I feel that if I can’t do it, I somehow failed. It’s like a challenge, and engineers/nerds/geeks loves challenges, hence anything/everything is possible. And it probably is; however, not on a schedule.

So what most typically happens is that we say something like: “Well, it’s probably possible if we add additional resources and delay the deadline”. Nothing wrong with that, right? We don’t really say NO, and we take on the challenge. Wrong, it’s dead wrong. Reason being that the receiving party of your kind-of-NO isn’t an engineer, probably someone in the business, and here’s what they pick-up from your kind-of-NO statement: “Well, it’s ..noise.. possible ..more noise…”. See these people only pick up what the want to hear, everything else gets lost in the translation from engineering-lease to sales-lease.

If you’ve come to the conclusion that it’s impossible within the given framework (resources and time) then, to my knowledge, there’s only one approach that works – and that is to spell it out loud and clearly by starting your answer with the NO, and whatever comes after shouldn’t in any form or shape take the power out of the NO. The receiving party will most likely eye-ball you for a while, and then start the actual negotiation on how to accomplish it. But I tell, you’ll never get to that part if you don’t start out saying NO.

Actually, NO is probably the single most important weapon you have as an engineering manager when there’s a risk of feature creep.

Understands Requirements

The third, IMHO, important qualification is the ability to understand what the business is asking for, what’re the requirements, being able to speak with marketing, sales and product management to gather the necessary input needed to be able to understand what’s expected to be developed. Take that knowledge and turn around and turn it into something engineers understand and can build product based on.

This one, actually ties nicely in with the first qualification, as it requires deep technical understanding to discuss functional requirement with the field, and at the same time being able to envision how the product or a feature eventually could end up being coded. Also, allow the engineering manager to get a sense for what’s possible and in what time frame, without always have to disturb the development team asking for help.

#programming #software #management

Wizards in software are mostly uninspiring solutions to bad design

Here’s a thought maybe even a provoking one, as everyone seems to have reached at the conclusion that wizards in software are good. The general and agreed upon argument goes; that a wizard shields the underlying complexity of the software. That’s fine. However, the question quickly becomes for whom or why do you need to shield this complexity. For the user, mostly the casual user, as the assumption in software design for business applications seems to be that the non-casual user knows how to operate complex screens or at least have read the manual.

But why would a casual user need to use the same software as a power user? Or at least why and where do a power and casual user share the same area and functionality of a certain application? Wouldn’t it make more sense to build different screens targeting the primary user – being either casual or power user? Rather than trying to cram everything into one screen? And then after cramming everything into one screen for the power user, develop wizards to help the casual user?

I can think of one specific area where wizards do make sense mostly concerning installation, configuration and setup of applications. But that’s not really shielding functionality, that’s more semi-intelligent template generation.

It should trigger a warning if you’ve either designing an application and you’re thinking: “maybe we should implement a wizard to make it easier”. Warning, you’re heading down the path of providing an uninspiring solution to a bad design. Don’t go there. Stop and rethink your design and redesign so the application targets the primary audience and provide the level of functionality needed for that audience. Strip away unnecessary functionality, and stuff it somewhere else, and let the power user go seek it out if needed.

#programming #wizards

Methodologies, Better Software and Requirements

Methodologies

Methodologies are like patterns, best practices, recipes or how-to’s. They describe how to get from A to B. But none of them claims that it’ll lead to better software, whatever better software means. Actually, that’s not totally true – some of the newer methodologies got some interesting claims on the subject of providing quality wise better software.

When discussing better software most people thinks about the quality of the software, seldom does people consider whether or not the software does what it’s supposed to do. Probably more correct to say, that people don’t factor the functionality in as part of quality. Can be observed when discussing functionality and/or quality with users, they don’t qualify a missing feature as a quality issue, but as an enhancement – and so do we as software engineers.

Okay, so 2 different objectives when developing software: 1) develop the right product and 2) in the right quality. Right product means that the product does what the user expects it to do, contains the right features. Right quality means that it does the former, without trying to ruin your life in the process – by – say – continuously crashing, or by any other means makes it unnecessary complicated to get your task done – hit the [ANY KEY] (some users actually got confused and tried to locate this key – no kidding!)

Question becomes, can a methodology help you to build the right product in the right quality? Personally, I don’t think so. However, a methodology – actually any methodology – can be a good starting point for building appropriate structure into a new project. Existing methodologies can be a source of inspiration on how you could do it. It’s much like a food recipe, if you follow it 100 %, you get something that’s not quite like on the picture and it doesn’t really taste as good as it looks (on the picture in the cook book that is).

That’s all good, but how do we then built the right product, in the right quality and at the right time? The answer to this perpetual question, and it is really perpetual as it’s been tried answered in tons of articles over the last 30+ years, isn’t 42. Probably more like 42+ something.

The Requirements

This may seem bleeding obvious, and it really is bleeding obvious – but apparently it’s very hard to get right, otherwise, we wouldn’t have late projects, wrong applications or defunct products. The key to the 3 R’s is the 4th R, being the Requirements. Having the requirements sorted out allow you to built what’s expected, to provide more accurate estimates (not just guestimates, or wise ass guesses) and also allows you to construct the test cases needed to validate the software against the requirements. Pretty obvious – huh? Well, apparently not!

Waterfall

If requirements are so important, why not gather them all up front before even starting to code? Not a bad idea! And in essence that’s what the Waterfall methodology is all about. Phased development plan, with well defined processes and stages for moving from one phase to another. Widely adopted and used methodology until the late eighties. For the waterfall methodology to be successful you need to be dead sure you got all your requirements right in the initial phase of the project, if not – there’s a high probability you’ll be hosed when delivering, and users will go: “Dude, I still can’t find the <ANY KEY>” or worse (maybe) “Dude! This is what I asked for, but didn’t expect” (more on this particularly scenario later).

Lots of empirical research indicated that waterfall works fine for projects that’s either extremely expensive or, if done wrong, kills the end user. Either way, if you don’t get the stuff right you’ll either be prosecuted and go to jail or lose your business. Huge motivator for getting it right – right?

Lots of other empirical research showed that for software projects, the whole idea of understanding the problem domain upfront seemed impossible. Mostly due to the shorter life cycle of software products compared with their more expensive hardware ones. Also, the investment model is different for software products, as the majority of the costs are salary. For e.g. chip manufacturing there’s a huge initial investment prior to producing, which is building the manufacturing plant.

Post Waterfall

Gathering requirements is an extremely difficult task, mostly because most users when asked what they want go: “Dude, show me what you can do….” or “something like who knows, that can – you know – when you hit the – whatever key…” Sigh! Very hard.

It turns out that users really can’t relate to the majority of the means used to communicate the end result. However, what users can relate to is the end result – the product, but problem being that it’s hard to change the final result. Somebody then came up with the idea of iterative processes, which essentially breaks down the development cycle into mini cycles, that each have all the phases known from the waterfall methodology: requirement gathering, analyses, design, implementation and testing. But added an evaluation phase, where the users evaluate the newly developed functionality.

Over time more and more iterative methodologies have emerged, but they all originate from the idea of splitting the phases into smaller cycles and including the users to evaluate the result on an ongoing basis, until the product is ready.

Better Software

If better software is defined as the sum of RP + RT + RQ where RS is right product, RT is right time and RQ is right quality. And we agree that the requirements actually are a key driver for obtaining RP + RT + RQ, then I believe that newer methodologies (or at least all methodologies deriving from iterative ones) will provide better software.

This being said, then personally, I believe there’s a small issue with not knowing the requirements initially as it’ll be very hard to get an initial estimate to cover RT. There simply need to be an initial phase prior the iterative process called high-level requirement gathering. The product of this phase is essentially a rough blueprint/proposal that top level explains the purpose of the system.

This leads to: for RP + RT + RQ = True, requires R. Meaning that to deliver right product, at the right time in the right quality you need to understand the Requirements.
#requirements #programming #software #engineering